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.
 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.
Johanna Rothman consults, speaks, and writes on managing high- technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. Her most recent book is "Manage it! Your Guide to Modern, Pragmatic Management."
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed