A successful build process

José Carvalho

At mantro we are always looking for ways to improve our development workflow and we feel that the build process is a key factor for productivity. In our latest projects we used Jenkins, and we want to share our experience!

By trying out new ways to automate steps like testing or deployment, which are key to have a productive project, we were able to focus on the development of new features instead of having to manually run these steps.

Thankfully there are tools like Jenkins that allow us to configure the build process to our needs. Jenkins is great. Here at mantro we use it for most of our projects. It’s free, open source, customizable, has a wealth of ready to use plugins and works on all operating systems. What more can we ask for? Version 2.0 was just released, which brings new built-in features for most of the common use cases and a much needed UX upgrade.

We have recently successfully used it in a major project and it was extremely useful. It helped us to automate the whole Continuous Integration and Continuous Deployment setup.

There were two features in particular that are worth mentioning, that worked particularly well together:

– Build per branch
– Github build status integration


Build per Branch

We started with our main job which, for this example, we called it master-job.

The main responsibilities of this job was:

– Poll GitHub for every new commit
– Run tests
– Notify build status

This job was directly dependent on the master branch.


Since we use git, we create new feature branches for every new feature that needs to be implemented. This basically means, that we could potentially have 1 or more feature branches for every feature the developers are working on. Let’s imagine that all of the feature branches branch out from master.
The main idea of Build per Branch is to detect new feature branches and effectively clone the master-job for each of the new branches. This means that the same job constraints that the main branch runs against are also be applied to all new branches.


By automating this concept, we were able to always be notified of the feature branches build status and ensure that they were all thoroughly tested and reviewed, before being merged back to master. This allowed us to drawn this very simplified concept.


In order to achieve this, we took advantage of the Jenkins Build Per Branch Plugin, which is very simple to install and configure.

This plugin will periodically check for new branches and clone the main job for every new branch. It also cleans up existing cloned jobs, when it detects that a branch was deleted.

By using the plugin naming conventions, we were able to configure this feature for all new feature, release and hot fix branches.


Github build status integration

By using the Build Per Branch feature together with Github’s Pull Requests, we were able to take this workflow to a whole different level. Since we never commit directly to master and, instead, use branches and Pull Requests to merged them back, the Build Per Branch feature was able to provide us with the necessary knowledge, of a branch build status, we needed to decide if a Pull Request should be accepted or rejected.

The Jenkins Github Plugin was configured to report the build status result of each commit to Github. This was displayed on every Pull Request, with a direct link to the related build job, were we could check for more details on why the build failed.

By automating the whole Build and Test process, we were able to take that weight out of the development team shoulders, increasing productivity and also allowing for a better Code Review process.



These were two of the concepts we used in our Jenkins workflow that, together with Slack and Email notifications, automated deployments and much more, allowed us to increase our level of productivity and efficiency.

By having a constant research mindset, the will to try new concepts, we are always able to improve on our previous efforts and apply all the acquired knowledge to new projects.