Are DVCS like Git inappropriate for teams using continuous integration?

Question

My team's development processes are based on continuous integration. The only branches we create are maintenance branches when we release, but otherwise developers are expected to commit regularly (daily if not more often) to trunk, so that everyone's work is always integrated, continually tested, and all that good stuff.

My understanding of DVCS is that it is great for branching. I worked some years ago in a team where this would have been very useful, as every bit of development was done on a branch, and only merged when complete and tested. But this was a different philosophy from continuous integration.

But it seems to me that for a team that uses continous integration, the groovy features of DVCS tools like Git would not be particularly relevant, and might even hinder the continuous integration process if merging changes requires extra steps that may be forgotten.

I'm sure there are other benefits of a DVCS (e.g. committing is very fast because it is local, presumably merging with the main branch could happen in the background while the developer carries on working).

But for this question, I'm interested in how teams which use DVCS and continous integration reconcile the two seemingly conflicting philosophies. I'm mainly interested in hearing from people who are actually doing this.

Answer 1

Since all DVCSs can be used with a workflow that uses a centralized repository, there is no problem. Policy dictates that the developer must push their changes to the central repository in exactly the same way that policy dictates commits to a non-distributed VCS. The additional tools that allow the developer to edit patch sets are not a hindrance in any way, and in fact make it much easier to generate a maintainable code base.

Answer 2

Continuous Integration tools such as Hudson have support for DVCS, so I suspect this is possible to reconcile continuous integration with distributed version control.

First, I think with DVCS using workflows such as topic branch workflow CI might be less necessary. Second, you can set up (single, central) continuous integration repository to which you push when you are ready, and hooks do CI.

---

Added 07-08-2009:

See for example Continuous Integration Spring Cleaning post on GitHub Blog.

Answer 3

Actually DVCS made continuous integration much easier.

With cenral VCS every developer has the rights to commit directly in trunk and therefore he could commit buggy code. And CI will detect it after the fact. So it's possible to have broken trunk even with CI.

On the other hand the basic operations in DVCS world is branching and merging. And because merging is explicit and separate process vs. commit to the trunk, one always can do check of the result of merge before it lands to trunk. I don't have experience with Git, but developers of Bazaar VCS have used this technique successfully for at least 3.5 years with the help of PQM tool.

Basically PQM workflow looks as following: developer publishing his branch so it can be merged, then he send special e-mail to PQM bot with merge instructions. When PQM received merge request it made separate integration branch (copy of trunk), then merge developer's branch and run tests on resulting code. If all tests are passed then integration branch pushed to trunk, otherwise developer will receive e-mail with log of failing tests.

Running all tests for Bazaar project takes time, but tests are executed on demand on separate server and developer won't blocked by merge and can continue to work on other tasks.

As result of PQM-based merge workflow the bzr trunk is never broken (at least as long as there is enough acceptance and regression tests).

Answer 4

Using a DVCS like Git doesn't prevent you from committing to a central repository regularly. However, it does mean that you can make intermediate commits locally and only push the changes to the central repository once you are done.

This way you have the benefits from source control even when you are halfway implementing a feature, without breaking the build for the other developers.

Answer 5

I don't know how to comment directly to bialix's response above, but it should be noted that it's very possible to do the exact same thing in non distributed SCM systems. I've worked at companies that did just that with CVS. It's all scaffolding around the SCM itself- perhaps there are characteristics of a DVCS that make it easier (none come to mind).

Answer 6

Two ideas that I've found help to explains this:

• DVCS separate commits from merges.
• CI runs against a repository that you choose.

So the heart of the matter is how the merges are made into the repositories that you want run a CI tool against. You can choose to have just one repository when you start.

Answer 7

I don't see why a team using Git or any other DVCS wouldn't use Continuous Integration. We have a few customers running Continuous Integration for Git using Parabuild, and it works for them just fine.