Gradle & GIT : How to map your branch to a deployment profile

Today I would like to show you how easy you can create conventions on your branching model and map these conventions to deployment / environment profiles.

Where we come from

Usually a project needs to have different settings for different environments (production, testing, staging, etc. pp.). Maven provides for this a nice plugin, but Gradle lacks of this kind of plugin. But, to be honest, introducing something that fills this gap is quite easy. For an example see source code below

As you see, it checks if the property ‘env’ is set, if so it uses this value otherwise developer as environment. After this setup it reads a config file in groovy style with the config slurper.

It works fine, so what’s the issue?

Even if the default is ok (test environment) it annoys me that have to type every time something like -Penv=production . It happens often, that I forgot to explicitly set the branch to production or staging (our CI-Server remembers this for me, but I need to build the bugfix branches for example on my local machine). Starting from this point I discussed with a colleague of mine the usage of some conventions on our branch layout  (mostly inspired by; we just added explicite bugfix branches on top of the release branch). We came up with the observation that we could map all branches to different environments

Branch to environment and profile mapping

Branch to Environment / Profile mapping

The dashed lines are alternative deployment environments whereas the filled lines are the default deployment environments from our perspective. As you see, we make a really simple and understandable mapping convention. After producing this mapping I started to investigate how complex it will be to check what’s my current branch in GIT is. This can be done fairly easy with

 Side note: Getting information of your parent branch isn’t that easy and reliable in GIT (see here )

In gradle I introduced a closure for fetching the branch name and doing some simple assumptions about the related profile / environment

Last but not least I used the ConfigSlurper for reading the matching properties from a groovy config file and push them into a variable in the ext space.

This can now used in the processResources task of the Java plugin, to replace placeholders

That’s all. It works very well and reduces the typed chars and frees my mind for the really important things.

I’ll prepare a simple example project and share it via git hub.

Update: Project at github (

At least some spoilers

  1. At my employment we started implementing a profiler plugin for gradle, that will include this with a little bit more sugar and some additional conventions. We will share this plugin via oss-sonatype / github. Stay tuned!
  2. My colleague created a nice extension for the zShell, I’ll ask him if we can share this here. If so I’ll put his script here during the next days.
17 Kudos

Leave a Reply

Your email address will not be published. Required fields are marked *