When to Use Staged Integration

Normally, I’m huge fan of continuous integration. Continuous integration is when everyone integrates his or her code every day, preferably as each little tiny piece is built and tested (or in the case of test-driven development, tested and built). The developer checks his or her code in, does a local build, checks the build, and then promotes the code to the mainline, as soon as he or she knows the code isn’t going to break anything else.

I’ve been a fan of continuous integration since 1990, when I was the program manager of a large software system. We had seven sub-projects, each with 8-12 people (developers and testers) work on the feature set for each project. I asked each project manager to use continuous integration during the project, so I would be able to see progress more easily and better predict the end of the project.

I had mixed results. Three of the teams did use continuous integration with themselves. Each of those three teams integrated all their code every day. Those three teams were relatively independent, so it was almost as good as continuous integration over the entire project.

But four teams did not use continuous integration. One team waited until they had finished a feature, and then integrated that, so they were integrating at least once a week, sometimes more often. That’s a form of staged integration.

But three teams refused to consider either continuous or staged integration, and insisted on big-bang integration-where all the integration happens at the end of the project.

The problem with big-bang integration is that you can’t tell if the project is making progress until after you see if everything is integrated. If you run into trouble, there’s no way to know how long it will take you get out of trouble.

You know the end of the story. The three teams who had continuously integrated met all their milestones and were not stressed at the end of the project. The team with staged integration had a little stress at the beginning of final system test, but that soon eased.

The teams who insisted on big-bang integration found the end of the project so stressful, they all wanted a vacation afterwards. All of the decisions they’d avoided making because they didn’t know about the decisions (because they’d avoided continuous integration), were no longer hiding. They had more defects-that were harder to find. They had a less-coherent design for their area-because they made all the decisions at the end of the project instead of during the project when they could have managed the decisions.

So, I’m a huge fan of continuous integration. But it doesn’t work all the time. In that case, you want to consider a form of staged integration. The kind of staged integration I use is this: the project team works on a branch. Everyone integrates every day on the branch. Everyone brings down any changes from the mainline. But you don’t promote to the mainline until you’re ready to replace the system you’re developing.

This works in these cases:

  • When your system has to stay running: Say you’re replacing some infrastructure in a system. You need that system to remain running-you can cut over to the new system at some point-but your users are actively using the system every day.
  • When you are experimenting with a new way to do things. Maybe you’re trying a new performance or search algorithm. You’ve got an API or some other design by contract commitment to the rest of the system. But you don’t want to slow down the rest of development.
  • When you’re integrating with hardware. To be honest, you won’t know what the hardware can really do until you have prototype hardware. Even then, you might not know everything about the hardware, but you’ll have a better idea. You can use continuous integration within features (or if necessary, architectural layers) of the software, but you can’t really integrate the hardware with the software until you have some hardware.

Staged integration with continuous integration on a branch is a first cousin to continuous integration. Staged integration without continuous integration is a poor second cousin. And big-bang integration? Fugeddaboutit.

Use continuous integration wherever possible. But don’t forget you have many successful options when managing the sources.

© 2007 Johanna Rothman. This article originally appeared in CM Journal.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply