Git And Continuous Integration

Here is my take on the whole distributed versus centralized approach.

At first you would think that people integrate more often in a centralized revision control system. This may be true for simple changes. It fails when you consider larger blocks of code, or bugs that have taken weeks to debug and solve. In these cases developers have been working in isolation on a particular problem and have been completely disconnected. Since their large chunk of code or bug fix is not completely finished yet they end up developing out of tree so that they "don't break the build", as you say. Eventually they commit.

I personally prefer to make small commits that capture my progress even though it may not be perfect. This way if a particular chunk of code does not work out, I can revert it back to something I did an hour ago.

The bonus with a distributed system (where each time a developer checks out they get a branch) over a centralized system, is that are permitted to make "micro commits" without breaking the build.

Greetings...

Just using a distributed SCM does not stop you from having a central "source of truth" repository that your CI runs off. We use Mercurial for the development of Cruise and have a central repository that Cruise runs off and developers keep in sync with.

Chris

First, nothing prevents each developer to have CI enabled on his/her repository, as pre-commit hook. But I think better solution would be to have some "build" repository with CI, which would refuse push if it fails continuous integration tests...

I see it as a matter of the commit and integration steps being separate with a distributed version control system. The commits will happen as before, but the integration will now occur separately, just as with plain old branches. The integration step may be manual, but for CI to be useful integration will have to be automated, perhaps with a manually set "not yet ready for integration" flag somewhere. The same tests for integration will still apply - did it build, do the tests pass.

Clint,

You might want to check our Parabuild. It provides Continuous Integration for Git. You can set it up to cover a private repository and a remote repository to that you are going to push changes to.

Hi, We started recently to experiment with distributed version control and immediately we found that CI cannot be done in the traditional way. You cannot have a centralized CI and use distributed version control, it doesn't make sense. We are changing our mindset and we use now what we call multi-level CI or staged CI. It is simple, each developer has his own repository. Each team has an integration repository, and the whole project has a dev repository and a stable repository. So we have different CIs processes arranged in a hierarchical way. When a developer thinks it has worthy changes, it push changes to the team integration repository. It could need to merge and perhaps resolve conflicts. When all branches merged without conflict then it triggers CI on a team level. If team level CI is ok, then the team level changes are pushed to the project dev and a project level CI is made, and so on. We can specify different levels of build for each CI level. For example at team level we run unit tests, and integration test but mocking infraestructure. At project level we deploy at an integration enviroment and run full test suite in a real env. This way of doing things makes sense since we could have several teams in different cities working in different aspects of the same project. If you have one single collocated team, you need only to use one level CI. We have yet little experience since we are experimenting, but it is working good by now. Need to enhance tools perhaps. One good thing is that the changes arrive at global project level less frequently and we can run a more exhaustive test suite. And these changes has been tested at team level so they usually are less buggy.