Continuous Integration – Does Branching Break CI?

branchingcontinuous integrationdvcsgitmercurial

I think this article, A Successful Git Branching Model, is very well known among experienced DVCS users.

I use hg mostly, but I would argue this discussion is fine for any DVCS.

Our current workflow is each developer clones the master repo. We write code on our own local repo, runs tests, and if all goes well pushes to the master.

So we want to setup CI servers like Jenkins and improve our workflow with the future provisioning system (chef, puppet, ansible, etc).

Real part

Well, the model presents above works nice but branches can break CI. The feature branch should sync with the origin (according to the article, it would be development branch) to make CI and merging smooth, right?

Say Alice and Bob are working on two features. But Alice is done the next day. Bob's feature takes a week. By the time Bob is done, his changes are out of dated (maybe Alice refactored/rename some classes).

One solution is each morning developers must pull master/origin to check if there's any changes. If Alice commited, Bob should pull and merge into his workspace so his feature branch is up-to-date.

  1. Is this a good way?
  2. Should these branches exist in the master repo (not local clone?) Meaning should every developer has commit privilege to the master repo on GitHub/Bitbucket so they can create a new branch? Or this is done locally?
  3. Lastly, the model presents by the article should break CI if branches are not sync with the origin/master. Since we want to do nightly build, should developers pull and merge before they leave work, and have CI runs on each feature branch as well?

Best Answer

First of all, the use of feature branches (to isolate the work done on a feature) and CI (to find integration problems as soon as they are committed) are slightly at odds.

In my opinion, running CI on feature branches is a waste of time. As feature branches come and go frequently, the CI tooling would have to be reconfigured over and over again. And that for a branch that most likely only gets updates from one or two sources that coordinate their check-ins to avoid the problems a CI system is meant to detect.
Thus, there is also no point in having the feature branches on the master repository server.

As for questions 1 and 3: It is the developer's responsibility to ensure the build on the main development branch does not break when they merge their feature-branch into it. How they do that is their problem, but two possible ways are:

  • Pull changes made to the main development branch into the feature branch on a regular basis (e.g. daily)
  • When the feature is done, merge the main development branch into the feature branch and push the merge result onto the main development branch.

In either case, the obvious integration issues (e.g. renamed classes/files) are found and fixed first on the feature branch. The more subtle issues are most likely only found when the nightly build runs and should be fixed there and then.

Related Topic