In my previous blog post I wrote about Continuous Delivery from our perspective here at Landis+Gyr. Now is a good time to revisit this topic so I can tell you more about continuous delivery tools: what we use to secure quality in our deliveries and why we have selected these particular tools. In this post, I focus on a technology-independent, powerful, widely used and supported and cost-effective tool set. That’s right, I’m talking about GIT, Gerrit and Jenkins. Those are our primary tools in our Continuous Delivery process.
Find the common thread
Let’s go back a couple of years. It all started with code review – or actually a lack of code review. We had commit builds, but reliability was not at an acceptable level: it was not guaranteed that the build would only contain changes related to one developer change. We also had nightly builds, but they were failing more than usual and fixing them took a lot of time and effort. Content traceability, well, it had its own challenges. That’s when we started to think about what code review tools we should use to really make the process work. We were using Subversion and Jenkins. We started to think about how to really improve the build process. What do we want from the process? What best fits our way of working? This allowed us to also understand our core problem areas and the direction we want to go in. That famous common thread was found!
We also asked ourselves: how can we make users follow an agreed process so that they don’t need to think about it too much? The answer was to select the right tool which guides and forces user to follow the agreed process. We needed a tool where we can set a quality gate, which users must follow, e.g. the commit message structure and content must contain important information for better traceability, like issue management ID and subject for the commit message. The tool should also be able to notify users if they are not following the process.
Work together like a charm – GIT, Gerrit and Jenkins
One of the required main features was that every change made by the user must go through the code review tool. Earlier, commit build reliability and follow-up were quite poor because it was not obligatory to fix defects. Code review should support also the commit verification quality gate: it should notify the user as before, but also prevent the commit change to repository if the commit verification fails. This single quality gate was the most important improvement in the whole process. In our case, the commit verification quality gate itself prevents most of the bad code slips in the system. So, we have quality gate one for commit message verification and quality gate two for commit verification – quality gate is, of course, code review. All of these three phases need to be passed before the user can get the submit button enabled and commit the change to repository. Do the previous functionalities sound familiar? Oh yes, I’m talking of course about Gerrit.
Selecting Gerrit made us also change the source code repository to GIT, which is totally different compared to Subversion. Not only does it have a bit of a different concept compared to other source code management tools, but now developers have to push changes to review instead of directly to target branch. There it was, no one is allowed to push changes directly to target branches, but all changes go through Gerrit and its different quality gates. GIT also offers many good improvements, for example, much faster checkout and fetch times, which plays a big role when all builds are done from a clean workspace.
All of this is managed by Jenkins. GIT, Gerrit and Jenkins work together like a charm. Gerrit notifies Jenkins when the developers push new changes to review. Jenkins triggers defined commit verification jobs and sends results to Gerrit. Jenkins is the engine in our process. It is flexible, easy to use and generic. We use Python to glue our tools together and to implement features needed in our process. Jenkins is tightly integrated with JIRA and TFS via REST API. The same applies to test automation tools like the Robot framework, Selenium and SoapUI. But then again, test automation tools and their selection criteria are a different story.
