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.
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
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.
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.
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.