Patterns for Continuous Integration and DVCS

Question

We currently use Subversion and TeamCity, we're going to move to using Mercurial (specifically Kiln as we're FogBugz users).

Obviously this will result in changes - hopefully improvements - in our development patterns (all two of us!) but the one issue I'm stuggling with is how to structure things so that we still enjoy the benefits of continuous integration/our CI server (that there are and will remain benefits is a given, discussion of which is outside the scope of this question).

With SVN we are committing to a limited number of central repositories - effectively one per project (more or less one Visual Studio Solution) so its easy to trigger a build and to get the reassurance that all the files have been commited and that there are no stray dependencies etc, etc. But if we're going to take proper advantge of mercurial we're going to want to have more repository instances - where I'd expect changes to generally flow towards a definitive "live" repo. The problem I'm struggling with is that the live repo seems to me to be too "late" to trigger my CI builds OTOH one CI build per project per developer is probably excessive (and causes other issues). I think that live is too late because - given that we can/should have more repos (clones of) - live should be deployable whereas we want to be building/running tests (unit at commit, integration at scheduled intervals) on development commits.

I'm fishing a bit but that's because one of the things that a central subversion repo gives one (me, with our setup!) is a lot of clarity about what to build when.

---

n.b. I'm not asking about the mechanics of using mercurial with continuous integration - I have that working a treat for a personal project, its patterns and structures and working practice/workflow that I'm trying to get my head round.

Answer 1

First, having multiple builds per project in TeamCity is really the way to go. The nature of the platform makes it really easy -- the copy button is there for a reason.

In any case, when we were on SVN, we typically ran 2 builds for each project -- one pointed at the main development line (in our case the trunk) and one pointed at our release branch. We carried this build setup over to HG while following a branching model similar to this one . Only real challenge has been finding a new funk schwea about build numbers now that we could no longer use current SVN revision number.

We try and encourage folks to push relatively often, especially when there is lots of work going on at once and we wanted faster feedback cycles. Just because it is a DCVS doesn't mean you have to only push once a day or something.

Answer 2

We've been using Kiln for about a year now and have tried several different things. Where we've ended up is to used named branches (as opposed to branch clones) with the following branching strategy:

• default tracks "completed" development
• feature branches track work that's currently in progress
• release branches track points where we released from default

So, work starts by creating a feature branch from the current tip of default. When the feature branch is done*, the branch is closed and merged back into default.

At some point, we decide that we're ready to release, so we create a new release branch from the current tip in default. This allows us to make changes to the code that's currently in production by committing to the release branch while still allowing active development on the feature branches and default.

As for continuous integration, we do two things:

• An "always on" integration that monitors the status of default
• New integrations for each release branch

The default branch job lets us know that our main source tree is always stable -- the release branch jobs let us know that those branches are stable and provide us with the build output we need to push a release into production.

_{*Our definition of "done" is that the feature is up-to-date with merges from default and has been approved in code review.}

Answer 3

If you move to a DVCS, like Hg, you're not only getting the "distributed part", you're also getting the full power of good branching and merging.

Considering that now you'll have a good issue tracker and a good SCM... why not creating a branch for each task?

The "branch per task" pattern is not new (check Berczuk's book) but it is definitely something to try.

I explained it in detail here, and the pros and cons of CI vs "controlled" here.