The new CI world, Wrapping it up with Git

Nowadays many agile teams work with Git and Feature Branches. A developer works with on a feature and at the end he merges the new feature’s code into the project. However, this concept goes against the principles of CI. Let’s take a closer look at this practice and find out if the concepts of version control system and CI are somehow compatible.

Welcome to part 6 – Man we are on a writing flow! – of our blog posts series. After all the coding done in the last parts, let’s take a more laid back look at CI and Git.

The Feature branch

The basic idea of a feature branch is that when you start working on a feature (or UserStory, if you prefer that term, based on Agile) you make a new branch of the repository and start working on it. Any changes on the project’s code will be done in this branch. The main advantage of feature branching is that each developer can work on their own feature and be isolated from changes going on elsewhere.

Although developers can develop their features in isolation, at some point their work does have to be integrated. Everything is just fine, if the developers have been working on completely separate parts of the code base with no interaction, in which case the merge will or should go smoothly. But they may be working on code parts that do interact with each other. The problem is the complexity of merging shared source code and dealing with conflicts as developers edited the same files. Martin Flower discusses this, and exposes a big problem e.g. a function rename creates a semantic conflict when merging feature branches. This makes developers fearful to factoring, which makes Feature Branching a bad idea, because once a team is afraid to refactor their code in order to keep it healthy, they are on downward spiral with no pretty end. (http://martinfowler.com/bliki/FeatureBranch.html)

Another thing to notice is, that feature branching is a different approach to CI. One of the principles of CI is that everyone commits to the main repository every day. So unless feature branches only last less than a day, running a feature branch is a different animal to CI. The teams is probably using a CI server when merging a feature branch and after every merge code will be tested for integration. That’s continuous building and an awesome thing to have, but there’s no real integration so it’s not CI. (http://martinfowler.com/bliki/FeatureBranch.html)

The mainline

Based on agile and CI, communication is one of the key factors in software development. One of CI’s most important features is that it facilitates human communication. When using CI and Git, developers should merge their changes often and don’t wait for a big merge to happen at the end of the development of a feature. By doing this, CI is effective at removing the problem of big merges, but it’s also a vital communication mechanism. And all of this can be  accomplished through a mainline. This means to mark one branch on the repository as the mainline. If everyone pulls and pushes to the main branch every day, then you have a CI mainline. Indeed with a disciplined team, it is a good idea to use Git on a CI project.

With CI, the mainline must always be healthy, so in theory (and often in practice) you can safely release after any commit. Having a half built feature or a feature you’d rather not release yet won’t damage the other functionality of the software, but may require some masking if you don’t want it to be visible in the user-interface. This can be as simple as not including a menu item in the UI to trigger the feature. With CI the mainline acts as a communication point. An up-to-date mainline also makes it easy for someone to be sure they are integrating with everyone, they don’t have to poke around to find out who is doing what – so less chance of some changes being hidden until a late integration.

Although many people associate Git with feature branching, it can be used with CI. All you need to do is mark one branch on the repository as the mainline. And the team should control that everyone pulls and pushes to it every day. An important condition is have a disciplined team, that takes the task of keeping the mainline clean, up-to-date, makes sure that new features are hidden in the user-interface until fully implemented.

Conclusion

Moving to Continuous Deployment will change your development dramatically. It will make you more productive and lead to a more stable and better product. There are steps like what tools to use and get a good idea of how they interact with each other. Once set up, you can then reap the benefits of deploying new versions several times a day. The main goal should always be to create a process to build a better product for your users, and at the same time make the life of the developers easier.

From a technical perspective, CI helps teams work more efficiently. These teams can be cross-functional, creating hardware and software that works together. They can be geographically distributed, because the constant integration work will ensure that you don’t get deviating designs. People can work on a large team, because the different components of a complex system will more assuredly work together. It solves many of the early pitfalls that these nontraditional agile teams might have experienced without CI. Combining CI with test-driven development puts more people under the agile umbrella, because it allows agile methods to work more efficiently.

From a business perspective, CI offers better business results by allowing teams to have their cake and eat it too. That is, they can bring products to market faster, by finding issues when they are young and small, not waiting until they are large and more difficult to fix. They can also respond better to requirements that are introduced while the product is being developed. This creates a better product for the customer, which is the real promise of agility.