How to reduce configuration duplication across services using Gradle plugins Featured

It's Monday and you're back at work. It's time to add another microservice to your steadily growing group of backend services. What fun! It's a greenfield project, so you get to avoid all the legacy code. But wait! This also means you have to reimplement all the configurations for your microservice. You think fondly of Maven, where you can use parent POMs to store common configurations and Maven archetypes to generate project templates. But then you remember that someone moved everything to Gradle many moons ago and now you have to use it in favor of Maven… Nothing like that is available in Gradle. Suddenly, you're overflowing with frustration. You see your boss walking towards your desk. Your hand reaches for the stapler, the first heavy, blunt object in your reach...

If this is you, fear not! I may have a solution. In this presentation, we'll look at how we use custom Gradle plugins at Outfit7 to encapsulate common configurations across our microservices to reduce configuration duplication and make it easier for anyone in the team to set up a service that fits with our guidelines. And all without having to spend hours browsing the web to find documentation on the obscure plugins we use. Instead, they just spend hours browsing our internal Confluence pages. Achievement unlocked!