Is using dvcs making harder to use continuous integration in corporate environments?

Question

There are unarguably lots of advantages in using dvcs and it can be used like centralized vcs, but is having local commits and being able to very easily fork the project for some smaller group making it harder to support continuous integration? It helps in development that everybody has access to the most recent changes, which are tested by the CI server so possibility of incompatible changes can be minimized.

Answer 1

You can centralize a DVCS. The difference between DVCS and centralized ones is that with a DVCS, you don't have to centralize it.

You could have a central repository where everyone can push changes, and everyone can pull the latest code from. You can write a commit hook on the server so that every time someone pushes code, it runs a test to make sure it passes the tests. It's just like centralized version control, only better, because I can create a local branch and make several local commits before I'm ready to push to the central server.

Have you ever been making a big change that breaks a lot of things, and wanted to make several commits, but not share them until you're done and everything is fixed again? That's what DVCS makes easy.

Answer 2

It does make it harder to perform CI as the source control system is encouraging you NOT to integrate continuously. However, there is absolutely nothing that prevents you from doing that regular integration into the central repository. The team just needs to remain disciplined about that.

Where smaller teams fork the project and do their own thing for a while, you should do continuous integration builds against that fork as well and potentially set up a regular integration between the two forks.

This would be similar to the stream based multi-stage continuous integration strategies that Accurev pushes:
http://www.accurev.com/multistage-continuous-integration.html