Build management/ Continuous Integration best practices

Question

How does your team handle Builds?
We use Cruise Control, but (due to lack of knowledge) we are facing some problems - Code freeze in SVN - Build management
Specifically, how do you make available a particular release when code is constantly being checked in?

Generally, can you discuss what best practices you use in release management?

Answer 1

I'm positively astonished that this isn't a duplicate, but I can't find another one.

Okay, here's the deal. They are two separate, but related questions.

For build management, the essential point is that you should have an automatic, repeatable build that rebuilds the entire collection of software from scratch, and goes all the way to your deliverable configuration. in other words, you should build effectively a release candidate every time. Many projects don't really do this, but I've seen it burn people (read "been burned by it") too many times.

Continuous integration says that this build process should be repeated every time there is a significant change event to the code (like a check in) if at all possible. I've done several projects in which this turned into a build every night because the code was large enough that it took several hours to build, but the ideal is to set up your build process so that some automatic mechanism --- like an ant script or make file --- only rebuilds the pieces affected by a change.

You handle the issue of providing a specific release by in some fashion preserving the exact configuration of all affected artifacts for each build, so you can apply your repeatable build process to the exact configuration you had. (That's why it's called "configuration management.") The usual version control tools, like git or subversion, provide ways to identify and name configurations so they can be recovered; in svn, for example, you might construct a tag for a particular build. You simply need to keep a little bit of metadata around so you know which configuration you used.

You might want to read one of the "Pragmatic Version Control" books, and of course the stuff on CI and Cruise Control on Martin Fowler's site is essential.

Answer 2

Look at continuous integration: best pratices, from Martin Fowler.

Well, I have managed to find a related thread, I participated in, a year ago. You might find it useful, as well. And here is how we do it.

[Edited]

We are using Cruise Control as integration tool. We just deal with the trunk, which is the main Subversion repository in our case. We seldom pull out a new branch for doing new story cards, when there is a chance of complex conflicts. Normally, we pull out a branch for a version release and create the build from that and deliver that to our test team. Meanwhile we continue the work in trunk and wait for the feedback from test team. Once all tested we create a tag from the branch, which is immutable logically in our case. So, we can release any version any time to any client in case. In case of bugs in the release we don't create tag, we fix the things there in the branch. After getting everything fixed and approved by test team, we merge the changes back to trunk and create a new tag from the branch specific to that release.

So, the idea is our branches and tags are not really participating in continuous integration, directly. Merging branch code back to the trunk automatically make that code becomes the part CI (Continuous Integration). We normally do just bugfixes, for the specific release, in branches, so it doesn't really participate into CI process, I believe. To the contrary, if we start doing new story cards, for some reasons, in a branch, then we don't keep that branch apart too long. We try to merge it back to trunk as soon as possible.

Precisely,

• We create branches manually, when we plan a next release
• We create a branch for the release and fix bugs in that branch in case
• After getting everything good, we make a tag from that branch, which is logically immutable
• At last we merge the branch back to trunk if has some fixes/modifications

Answer 3

Release Management goes well beyond continuous integration.

In your case, you should use Cruise Control to automatically make a tag, which allows developers to go on coding while your incremental build can take place.

If your build is incremental, that means you can trigger it every x minutes (and not for every commit, because if they are too frequent, and if your build is too long, it may not have time to finish before the next build tries to take place). The 'x' should be tailored to be longer that a compilation/unit test cycle.

A continuous integration should include automatic launch of unit tests as well.

Beyond that, a full release management process will involve:

• a series of deployment on homologation servers
• a full cycle of homologation / UAT (User Acceptance Test)
• non-regression tests
• performance / stress tests
• pre-production (and parallel run tests)

before finally releasing into production.

Again "release management" is much more complex than just "continuous integration" ;)