[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Build Processes
From: |
Teala Spitzbarth |
Subject: |
RE: Build Processes |
Date: |
Wed, 15 Aug 2001 21:27:51 -0700 |
Hi Bill,
Yes these are the kind of questions that are close to my heart too.
I found that Fogel's book, while very good, didn't outline much
about 'release' strategies with CVS, and in any case Open Source
strategies can have different priorities than commercial software
companies. I've set up a basic release strategy at my current company -
though I know the real test of it is going to happen when we formally
FCS
and then have multiple lines of maintenance/patch development along with
the next revision development.
Hope the 'essay' is useful!
Cheers,
Teala
------------------------------------------------------------------------
----------
We use a 'build level' approach to development.
The basic process we are using is as follows:
- Nightly builds involve using cvs rtag to tag the module with a
descriptive
bl_projectDate_time tag:
bl5_project14Aug01_0000
- The Build team has control of CVS tag name space and
branching.
- Part of the reason we always do formal builds pulled from a
tag is that we
use the $Name$ keyword in ident commands to allow for
identification of key
binaries.
*Gotcha*: using $Name$ means that cvs will experience 'merge
conflicts' on
doing updates in any working copies pulled from a tag - so if
your build tree
was pulled from bl5_project14Aug01_0000 - and then you run a
build - get a failure
and try to go do a "cvs up -A" in your build tree to get
freshly delta's fixes,
you will get merge conflicts on all files that have the $Name
keyword. Requires
manual clean up.
- When one of those nightly builds (or requested build during
the day) is deemed to
pass acceptance criteria and enters QA, it is retagged with a
formal build level
tag, i.e.
PROJECT_BL5
- There is a short period during the integration cycle trying to
clear QA acceptance
criteria, where we 'close the tree' on an honor basis to new
development, (i.e.
until we know we have reached a point that is sane enough to
create a fixes branch).
- A quick diff -r is done against a pull of the official
PROJECT_BL tag against
the build tree that produced the CD release to QA, to ensure
the correct files got
the final tag.
- Archival of the old build level happens, which includes
removing any old unneeded
'nightly' tags - to keep the cvs 'log' output more manageable.
- At this point, the main trunk moves on for next build level
development
- If fixes are required for QA to complete their testing of say,
PROJECT_BL5,
then I start a PROJECT_BL5-fixes branch rooted off the
PROJECT_BL5 tag
- Within our company, developers are required to double-delta
changes
on the fixes branch to the main trunk as well. For simplistic
changes
they have been able to use the cvs up -jPROJECT-BL5-fixes
command, or
the cvs up -j"one day ago" -jPROJECT-BL5-fixes command, to
do merges off the fixes
branch. But some developers have had problems with the merges
loosing changes.
We don't do wholesale merges of the whole module off of a
fixes branch back onto
the main trunk. This hasn't been a major issue here, as often
developers don't
want the exact same fix in a maintenance branch going into the
top of tree code.
- Fixes branch builds are likewise rtagged before the source
pull to do the build, a
minor number is rev'd to indicate how many fixes 'rebuilds'
have been done.... i.e.
PROJECT-BL5-2
- All the above tagging is automated in nightly build scripts
that do everything from the
rtag, pull the src, kick off builds & unit test passes across
multiple OS platforms,
run packaging on binary outputs, create the CD's and post
results.
- Occasionally I hand tag a few files and update them using -F
flag to a given PROJECT-BL tag
when there is a small local rebuild to correct a minor
problem. In general I try
to have any kind of delivered release roll out of a full
automated build.
- Top of tree (i.e. ongoing development) builds are run at night
via a cronjob. It is the
fixes branch builds, and the 'integration cycle' builds just
before a cut goes to
QA that involve coordination between developers and myself
(build engineer). This
usually involves developers stomping into my office exclaiming
"we need another build" :-)
Alternatively, it involves me stomping into their office
exclaiming, 'Is that fix done yet we need to start the build!"
:-))
Or it might come from our program manger after a change
control meeting....
Unlike James Youngman's environment, I do not examine actual
delta's. I am more of an
automation, release process and packaging engineer than an
engineer code reviewing changes.
I think this is entirely a cultural/job definition issue
within your working
environment.
- I anticipate that when we FCS - our maintenance releases will
be handled like our
current BL-fixes branches. I don't know yet if our subsequent
projects will be
new modules in the CVS tree, stay on the main trunk, or move
to a new repository.
Side tools that support the release process
- We use cvsweb to make the tree available for graphical
diff'ing
- We use perl scripts to provide web pages that display all CVS
changes that
have gone into any particular day's build - this parses cvs
log output
to display a chart with the file name (linked back into the
cvsweb tree),
revisions delta'd, and the commit comments (which for us have
a Bugzilla Bug ID)
There are scripts to provide some level of linking between CVS
and Bugzilla,
which QA and I intend to install soon.
- *Gotcha* There are bugs in 'cvs log' that have resulted in
incorrect log output
for changes between tags on branches in our tree (especially
files that have been
removed from the tree show up as having changed on the
branch). I have had some
good emails with David Taylor about this and gotten some
workarounds - so I can at least
display similar change logs between tags on our fixes branch
builds.
- When we are in change control and fixes need to be approved
for either main trunk or
branch commits - we count on the 'honor system'.
BugID's from the comment logs in the daily top of tree builds,
or branch fix builds
are confirmed against the approved list by Build team or QA.
- We don't use the edit/unedit capacity here. Some developers
use watches to keep an eye on critical shared files.
- Occasionally, if there really is a need to lock an individual
file we use
cvs admin -Ll <ver> filename.c
- I have once locked the whole tree with cvslock, when the src
tree was to be frozen,
in a display of authority :-)
Some Things that developers tend to forget/not use correctly:
- When they go back and forth between trees that have sticky
tags, i.e. a tree pulled
on a given tag (to reproduce a problem) or a branch (to work
on a fix), they claim update doesn't work, they can't find top of
tree files they know have been checked in. Or they can't commit a
change. Answer: cvs up -A (or if you are in a branch you have to do cvs
up -r"Branch")!
- They do a cvs log in a branch working copy and see head
information at the top and think they aren't in a correct
branch copy. Answer: cvs status will show the sticky tag for the
branch more clearly
- Some developers get excited about cvs up -A and code it into
local utilities, then they
go work on branch working copy, run their magic update command
and voila their changes show
up in top of tree instead!
Things not to try:
- Don't try and raise the revision across the whole module as
part of a release process
It is confusing - new files won't automatically go in at the
higher version.
Stick to tags.
- Don't run scripts that execute lots of cvs commands one after
the other - inetd locks
up the port.