DVCS – Do Distributed Version Control Systems Discourage Continuous Integration?

branchingcontinuous integrationdvcsgitsvn

Say there is a team of ten agile developers. Every day they each pick a task from the board, commits several changes against it, until (by the end of the day) they have completed the task. All developers check in directly against trunk (Google-style, every commit is a release candidate, using feature toggles etc).

If they were using a centralized CVS like SVN, every time one of them commits, the build server will integrate and test their changes against the other nine developers' work. The build server will be pretty much running continuously all day.

But if they were using a DCVS like git, the developer may wait until they complete the task before pushing all their local commits together up to the central repository. Their changes will not be integrated until the end of the day.

In this scenario, the SVN team is continuously-integrating more frequently, and discovering integration problems much faster than the git team.

Does this mean DVCSs are less suitable for continuous teams than older centralized tools? How do you guys get around this deferred-push issue?

Best Answer

Disclaimer: I work for Atlassian

DVCS does not discourage Continuous Integration as long as the developer pushes remotely on a regular basis to their own branch and the CI server is setup so that it builds the known active branches.

Traditionally there are two problems with DVCS and CI:

  • Uncertainty of integration state - unless the developer has been merging regularly from master and running the build, you don't know what the state of the combined changes are. If the developer has to do this manually, chances are it won't be done often enough to pick up problems early enough.
  • Duplication and drift of build configuration - if the build configuration has to be copied from a 'master' build to create a branch build, the configuration for the branch can quickly become out of sync with the build it was copied from.

In Bamboo, we introduced the ability for the build server to detect new branches as they are created by developers and automatically setup builds for the branch based off the build configuration for master (so if you change masters build config, it also changes the branches config to reflect the change).

We also have a feature called Merge Strategies that can be used to either update the branch with changes from master before the branch build runs or automatically push the changes in a successful build branch to master, ensuring changes between branches are tested together as soon as possible.

Anyhow, if your interested in learning more, see my blog post "Making Feature Branches effective with Continuous Integration"

Related Topic