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

Actually DVCS made continuous integration much easier.

With central VCS, every developer has the rights to commit directly in trunk and therefore he can commit buggy code. 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 are branching and merging. Because merging is explicit and a separate process vs. commit to the trunk, one can always check the result of a merge before it lands on the 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 publishes his branch so it can be merged, then he sends a special e-mail to the PQM bot with merge instructions. When PQM receives a merge request, it makes a separate integration branch (copy of trunk), then merges the developer's branch and runs tests on the resulting code. If all tests are passed then the integration branch is pushed to trunk, otherwise the developer will receive an e-mail with the log of failing tests.

Running all tests for Bazaar project takes time, but tests are executed on demand on a separate server. Developers won't be blocked by merges 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 are enough acceptance and regression tests).

Answer 2

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 3

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 4

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.