Nice post. Have you ever read any of Damon Poole’s stuff at his Agile Development Thoughts blog? He’s CTO of Accurev and has some interesting thoughts on the subject of Agile, including his own Agile methodology, Hyper.

Srini

Nightly builds may be overkill, but only if you are building frequently. I’ve heard first-hand of teams that build (on an isolated, non-development box) only once a week, or even once a month. These delayed builds rarely succeed without major human intervention, turning what should be a simple process into hours or days of scrambling, wasting valuable development hours on integration.

Ideally a build would occur automatically whenever someone checks in code. If that’s not feasible (because the build takes too long), there are some options:

1. Make the build faster if you can. Optimize it like you would any other software issue — fix the biggest bottleneck, retest, repeat until it’s fast enough.

2. Reduce your build process to a minimal set of tasks to verify the code. If you’re working in a compiled language like C++ or Java, compile the code. If you’re doing any unit testing, automate the tests. Things that change less frequently, like install/deployment scripts, may not need to be exercised as frequently.

3. If you’ve optimized and reduced as much as you can and it’s still not fast enough to build at every checkin, build at frequent intervals throughout the day. Every 10 minutes, every hour, every 4 hours. The more frequently the better.

It’s also important to note that a broken build is not the end of the world (at least you know the system works!) but it should be fixed ASAP. No one should check out or check into a repository that can’t be built, and development more or less halts until the build is fixed. If you’re integrating and building continuously, most build issues are relatively easy and quick to fix (‘oh, I forgot to add this new file…’).

Great points Jeremy. The key phrase is ‘may be overkill’. Automating a nightly build in many SW environments shouldn’t be that difficult… But it’s only worthwhile if there is a purpose to it.

One good reason is if you have someone in QA working directly in the QA process. Agile dev teams should have a QA resource as part of the core team. If they audit the check in list and match them to the requirements, they can validate the check-ins via the nightly build.

I’ll agree with Jeremy. We just had a team that was very proud that they wrestled our build group into providing them a build once a week. This is horrifying to me… we run daily and want more.

In the general sense, if it’s really that hard to run every night, it’s probably hard for developers to run as frequently as they need to. It’s a pretty good indicator that you need to take a serious look at either your BRM practices and/or your project structure.

I hope no one thinks, and that the author was not implying, that waiting two days to check-in changes is sufficient. Even a short two day task should have several check-ins.

I don’t agree with ‘Keep production parameters such as URLs, user names, passords, etc. outside of version control.’ Everything, including binaries used and generated, scripts and configuration files must be under source control. How else are you going to be able to exactly recreate a release?

A branching strategy is imperative (if you expect to use branching at all). Branching done right is hard enough, branching done wrong is probably worse than no branching. You better be clear with your developers what branching is, when it should be used, and how to do it. Waiting until a developer decides they need it will just lead to confusion, inconsistency and a mess in the repository.

I highly recommend the book ‘Software Configuration Management Patterns: Effective Teamwork, Practical Integration’.