any issues with using git in a CI environment?

Question

I work in a shop that lives by its CI process. We have traditionally used SVN and are considering moving to git (want to leverage its ease of branching, stashing, etc). Thinking in terms that a distributed source control system, by its very nature, seems to put the need for a central repository as a secondary concern, does git create any challenges for a CI process? As long as the developer performs a "commit" then "push", does the concept of a central repo as I would have known it with SVN still exist, making CI builds just a different config (pull from git rather than svn)?

Any cultural issues (developers pushing to main repo less often and instead only committing locally perhaps)?

Would love to hear success/failure stories from a group that uses CI with git.

Answer 1

It doesn't add any more complexity that couldn't be considered opportunity. While you can use Git in a completely decoupled, decentralized fashion, many projects usually settle on one (or several) 'blessed' repositories, and these are the repositories that the CI server should be building.

You might have 'blessed' repositories for the main (as in the one you ship from) repository, as well as some for branches that eventually make their way to the end of the line. You can use your CI server to do what it does best, detect toxic revisions at any link in that chain.

So in many ways, it's better, because you catch stuff before it gets put into the central trunk and out in the wild to blow up gloriously. Still, the art really isn't the CI process, it's establishing a Git workflow that permits you to place CI builds at key places.

I use Hudson with both Git and Mercurial projects, sharing a similar workflow. Git is actually the easier of the two, as branches in Git are a bit easier to manage. Typically, we have a small team with one lead, the team lead gets requests to pull to a blessed branch repository. If CI checks look good there, the team lead sends a pull request to the project manager, who pulls in to a -next repository. If CI builds are fine there, it eventually goes into the single (combined) release repository. So you really can run tests at almost every step of the way, or less, depending on your need.