Continuous Integration

When discussing continuous integration (CI) one might find projects and teams stating they have CI because they employ CI-Tools such as Jenkins or Travis-CI. We believe CI is not something you have but rather something you do.

Before proceeding let’s have a look at Wikipedia to define CI as:

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day.

There is no mention of CI-Tools. If every developer on the team integrates his changes into be master branch on a daily basis then the team is doing CI. Feature branches that are kept open longer than a day are not acceptable. It goes without saying that the code in master should always build successfully and pass all tests since everyone depends on it.

You might be asking: “How are we going to implement a feature that takes weeks or months to implement if we can’t create feature branches?”. To solve the same issue in Relution we enjoy using Feature Toggles.

The server provides a list of features that are currently under construction. Our clients then use the list and decide which features the users should see. As a result, the customer never sees a feature that is currently being built, while the developers and the product managers see all features. As soon as the feature is finished we can remove it from the list to allow every user to see and use it. Take a gander at Feature Toggle Framework List for some inspiration on how to implement the feature toggles.

Having explained how the daily integration of branches can be achieved lets look at some of the benefits:

Although CI can be achieved without a CI-Tool, see Continuous Integration on a Dollar a Day for more, we at Relution use Jenkins to help us having the master branch in a state where the build is always successful and passes all tests. Before merging changes into master they have to be built by Jenkins, passing all their tests. Following this process the master should almost never be broken. If, for some unforeseen reason, it gets broken the primary focus of the team now shifts to getting it back to a working state. To make this work the team needs to understand the value of CI and be committed to it.

The practices above become easier the shorter the duration of a build is. If the build takes ten minutes it takes at least ten minutes to get the build from a broken state back to a working state. With a lengthy build the process becomes harder.

Imagine the build takes an hour. You create a merge request and Jenkins will need one hour to prove the result still builds. Another hour of build time is added after the requester has fixed issues which arose during the code review. As a result it took two hours of build time for a single integration, not counting the time spent on the code review and ensuing issues. Thus striving for a fast build is of paramount importance to make working with the CI process painless.

CI is not easy, or as Jez Humble, author of Continuous Delivery, remarks:

Continuous Integration is super hard, it’s not running Jenkins on your feature branches and then ignoring the build when it goes red.

Regardless, we at Relution accept the challenge, knowing the benefits of rigorous CI are worth it.