calperforce/chapter/ch07.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
Channelling the Flow of Change in Software Development Collaboration
Channelling the Flow of Change
in Software Development Collaboration
Laura Wingerd
Practical
Perforce This is the Title of the Book, eMatter Edition
Copyright © 2005 OReilly & Associates, Inc. All rights reserved.
176
Chapter 7
CHAPTER 7
How Software Evolves
Just as theres more to driving than knowing how to operate a car, theres more to
SCM than knowing how to use an SCM tool. Mastering SCM starts with understand-
ing how software evolves and recognizing how team collaboration, defect manage-
ment, parallel releases, and distributed development affect the software life cycle. For
just as road maps and rules of the road are the bigger part of driving, the software life
cycle is the bigger part of SCM.
In this chapter we take a step back from Perforce to look at the roadmap of the soft-
ware life cycle, the mainline model. Well identify the codelines that form the main-
line model and describe the rules of the road for change flowing between them. This
chapter sets the stage for the chapters that follow, each of which demonstrates using
Perforce to manage codelines of a particular type.
The Story of Ace Engineering
Consider the story of Ace Engineering, a fictitious software company. After a year of
intensive start-up development, the companyintroduced a new product, AcePack1.
0. Sales were successful, the customer base grew. Alas, so did the bug report data-
base. Within six months Ace had produced a point releaseessentiallythe same
product but with manybug fixes and small enhancementsas AcePack1.1. For a
while, the companysupported customers on either version, but at the end of the sec-
ond year it announced that AcePack 1.0 was being discontinued.
During this time Ace developers had started working on two new features, code-
named Saturn and Pluto. The plan had been to include both features in the
AcePack2.0 release. Midwaythrough the third year Pluto was done, but Saturn
turned out to be much more work than anticipated. (In fact, the companyended up
doubling the size of the Saturn development team, with half the team working on an
unforseen adjunct now code-named Saturn Plus.) AcePack2.0 was ultimately
released without the Saturn feature.
,ch07.6513 Page 176 Friday, November 18, 2005 2:41 PM This is the Title of the Book, eMatter Edition
Copyright © 2005 OReilly & Associates, Inc. All rights reserved.
177
|
Chapter 7: How Software Evolves
The 2.0 release did well, although it, too, had its share of problems. It was hard to
get customers to upgrade, and Ace ended up having to fix show-stopping bugs in
both available releases, 1.1 and 2.0. However, it was able to produce a verystable
release, AcePack2.1, about six months later. Shortlyafter that, support for AcePack1.
1 was discontinued.
Finallythe Saturn and Saturn Plus development projects were completed. The Sat-
urn feature will be in AcePack3.0. Meanwhile, customers have upgraded to AcePack
2.1, AcePack 2.0 has been retired, and Ace developers have started working on yet
another new feature, codenamed Rocket. (Figure 7-1.)
The Ace Engineering story illustrates typical problems of the software life cycle:
First, at anypoint in time there is likelyto be more than one supported product
version available to customers. Ace must be prepared to field customer calls,
diagnose problems, and fix critical bugs in all of their currentlysupported ver-
sions.
Second, not all development tasks have the same urgency. Some are expected to
yield results immediately while others are targeted for distantly future releases.
Third, software development is not entirelypredictable; some projects go
according to plan, others get mired in unforeseen difficulties.
What Ace Engineering makes is shrink-wrapped
*
software. Other kinds of soft-
wareweb-hosted, embedded, open sourceevolve differentlyand have life cycle
problems of their own. What all of them have in common is that their software life
cycle problems can be solved by parallel development. Ace, for example, solved its
Figure 7-1. Ace Engineerings first five years
* Shrink-wrapped software is software that is distributed in periodic releases. The provider decides when to
make new releases available; users decide when to upgrade. As a consequence, there can be several releases
in use at the same time and the provider may have to support many or all of them concurrently.
Year 1
Year 2
Year 3
Year 4
Year 5
feature development
stabilization and support
product release
Initial development
Pluto
Saturn
Saturn Plus
AcePack 1.0
AcePack 1.1
AcePack 2.0
AcePack 2.1
AcePack 3.0
Rocket
,ch07.6513 Page 177 Friday, November 18, 2005 2:41 PM This is the Title of the Book, eMatter Edition
Copyright © 2005 OReilly & Associates, Inc. All rights reserved.
The Mainline Model
|
178
problem of having to support customers on two releases byputting some developers
to work on the old release while others developers worked in parallel on the new
relese.
Software development is complicated enough; parallel software development can be
even more complicated. But it doesnt have to be. In the next section, well look at
how the mainline model can be used to keep the complexities of parallel develop-
ment in check.
The Mainline Model
A codeline is, for the most part, the same as a branch. But while the term branch can
mean anyset of files created bybranching, codeline is imbued with slightlymore sig-
nificance. Codelines have a purpose, a strategic role in the development of software.
Together, codelines form a model of software evolution.
In the Perforce view of software configuration management, one model, the mainline
model, is most effective. This chapter discusses codelines and software evolution in
the context of the mainline model. Its not a Perforce-specific discussion, bythe
waythe mainline model is a concept, not a Perforce feature. But it is the concept
on which much of the design of Perforce is based.
From Ideal World to Real World
In the ideal world, there are no bugs, no schedule crunches, no personnel changes,
no market shifts, and no technologyrevolutions. Software in the ideal world is sim-
plydeveloped and releasedthat is, new features are developed, and when theyre
ready, a new version of the software is released. Each release contains features that
work perfectly.
If there were such an ideal world, we probablywouldnt need an SCM system. Even
so, wed have a collection of files evolving together in a codeline. This codeline
embodies the evolution of our software; it is our mainline. In the ideal world it would
be the only codeline wed ever need. (See Figure 7-2.)
A sad fact of the real world is that the software we develop isnt perfect. Because of
that we subject software to a testing phase before release, during which bugs are
Figure 7-2. The mainline in the ideal world
mainline
development
development
Release 1
Release 2
,ch07.6513 Page 178 Friday, November 18, 2005 2:41 PM This is the Title of the Book, eMatter Edition
Copyright © 2005 OReilly & Associates, Inc. All rights reserved.
179
|
Chapter 7: How Software Evolves
invariablyfound. We could do all this in the mainline if development could halt for
the testing phase, and if all bugs could be found and fixed during testing. But all
bugs are not found during testing; manyare found after software is released. And we
cant hold off on new development during the testing phase because we have dead-
lines and market pressures to face. So we branch completed software from the main
codeline into a release codeline.
Branching release codelines allows us to do two different kinds of software develop-
ment at once. One kind is bug fixingeuphemisticallyknown as stabilizationand
the other is new feature development. In the release codeline, we stabilize a version
of our softwareboth before and after releasewhile in the mainline we get on with
developing new features. As we stabilize the release version we can make point-
releasesthat is, we can re-release the softwarewithout the risk of releasing
untested new development.
Another problem with the real world is that our customers expect us to fix bugs in
old versions of our software even as we are developing and stabilizing new versions.
To deal with this, we branch a new codeline for each release, leaving our old release
codelines intact for more bug-fixing. Now the typical shrink-wrapped software evo-
lution model begins to take shape. A mainline charts the course of the overall devel-
opment, while release codelines sprout as new versions are ready. When releases are
no longer supported, the codelines designated for them cease to evolve, but the
mainline persists. (Figure 7-3.)
In the ideal world, all development projects are completed on schedule. No matter
how manynew features are slated for the next release, developers in the ideal