Question

OUR CURRENT BUILD PROCESS

We’re a small team of developers (2 to 4 people depending on project) who currently use Phing to deploy code to a staging environment, before going live. We keep our code in a SVN repo, where the trunk holds current active development and, at certain times, we do make branches that we test and then (if successful), tag and export to the staging env. If everything goes well there too, we finally deploy’em in production servers.
Actions are highly automated, but always triggered by human intervention.

---

THE DOUBT

We’d now like to introduce Continuous Integration (with Hudson) in the process; unfortunately we have a few doubts about activity syncing, since we’re afraid that CI could somewhat interfere with our build process and cause certain problems.

Considering that an automated CI cycle has a certain frequency of automatically executed actions, we see 2 possible cases for “integration”, each with its own problems:

1. Case A: each CI cycle produces a new
   branch with its own name; we do use
   such a name to manually (through
   phing as it happens now) export the
   code from the SVN to the staging
   env. The problem I see here is that
   (unless specific countermeasures are
   taken – IE deletion) the number of branches we
   have can easily grow out of control (let’s
   suppose we commit often, so that we
   have a fresh new build/branch every
   N minutes).

2. Case B: each CI cycle creates a new
   branch named ‘current’, which is then tagged with a
   unique name only when we manually
   decide to export it to staging; the
   current branch, at any case is then
   deleted, as soon as the next CI
   cycle starts up. The problem we see
   here is that a new cycle could kick
   in while someone is
   tagging/exporting the ‘current’
   branch to staging thus creating an
   inconsistent build (but maybe here
   I’m just too pessimist, since I
   confess I don’t know whether SVN
   offers some built-in protection
   against this).

---

With all this being said, I was wondering if anyone with similar experiences could be so kind to give us some hints on the subject, since none of the approaches depicted above looks completely satisfing to us.

Is there something important we just completely left off in the overall picture?
Thanks for your attention & (in advance) for your help!

Answer 1

In both options you start with “each CI cycle produces a new branch”. Don’t do that. You want to keep your number of branches to the minimum and always under control (manually created) to avoid that your project becomes a mess. The decision of whether the development in the mainline is ready and you can produce a release candidate (branch from the trunk) is not trivial.

CI cycles are triggered by changes in the code to ensure that the integration of those changes doesn’t break the application. Therefore, you’d rather set up a project in Hudson for each active stream of development, this is, one for the mainline, one for the branch that represents the production version (for bug-fixing) and eventually one for the RC.

Martin Fowler’s article about Continuous Integration is an excellent guide to the whys and hows of CI implementation.