Configuration Management for Projects
Software configuration management is intended to control the
configuration of a software product or system throughout the life cycle of the
product and that includes the project that builds it. Software development organizations
that have been certified as CMM or CMMI Level 2 or above will have a robust
Software Configuration Management process in place; all you need to do is to
determine the activities, tasks, milestones, and deliverables your project must
plan to be compliant. Project managers who don’t have the advantage of an
established Software Configuration Management process will have to implement
one as part of their project. The advantage of doing so is twofold: you
maintain control of the applications, networks, and manuals that are compiled
for the system and you establish a re-usable process that can maintain control
of the system throughout its lifecycle. The process you leave behind can also
be used by other projects. Not implementing some sort of configuration
management process will lead to problems when you try to produce builds and
patch the software. Typical of this type of problem is the software bug that
was fixed by an earlier build recurring in a subsequent build, or the 1 hour
build that takes days.
There are 2 ways to approach the issue of configuration
management where there is no existing process. You can either make the
definition and implementation of a process part of the scope of the project, or
you can implement just enough to satisfy the needs of the project and leave the
implementation of a proper process for another project. I suppose a third
option might be for the implementation of a CMMI Level 2 program to coincide
with your project but very seldom will the project and program schedules permit
this. The purpose of this article is to provide some tips and tricks that will give
your project insurance against sloppy configuration practices without
overburdening it with unnecessary overhead.
Your first step should be to evaluate the software
environment your project is inheriting. I’m assuming here that your project
isn’t the first software development project your organization has ever
undertaken. If it is, you’ll need to make the establishment of a software
configuration management process a part of the implementation of the software
The backbone of a software development shop is the source
library. The source library is also the tool that must support any
configuration management processes you wish to implement. The source library
should support baselining with the ability to store and track different
branches (e.g. development branch), and to merge a fix across multiple
branches. It should also support running scripts such as the build script used
to compile a configuration of your software application. Analyze the source
library tool in your organization to determine its fitness for use to support
your project. Most of the tools in common use such as CVS, RCS, PRCS, and etc.
have these features and more. Unless your project has unique requirements these
tools should satisfy your requirements. Your Release Management process will
identify any special needs your project has in this area; more about the
Release Management process later.
Your next requirement will be a librarian who is responsible
for controlling the checking in of code, software builds, and releases.
Checking the code out is never the issue; code that is in the source library is
controlled by the library tool. It is only after the code is checked out that
the fun begins. The librarian should maintain the standards set for checking
code back into the library and have your support for their enforcement. There
are lots of tools out there called "librarian software”. Don’t confuse the two.
Librarian software may be a great asset to your software librarian but will not
perform the functions you will call on your librarian for. Let me give you an
example. Let’s say you’ve chosen an iterative methodology for your project.
You’ll need to perform at least one build per iteration (more if you perform
any "emergency” builds) and each of these builds is an opportunity to introduce
new bugs into the release. Satisfying the need to perform builds by assigning
build duties to one of the development team who doesn’t have experience as a
librarian is going to lead to delays and frustrations as builds fail, deadlines
are missed, and the team searches for someone to blame for this mess. The
person who will be held responsible by your project sponsors is you and you
could have avoided this by identifying an experienced software librarian to
control the source, perform the builds, and be responsible for the releases.
Establish a set of criteria that code must meet before it
can be checked into the library. At a minimum code must compile error free
before being checked in. Compiler warnings should be analyzed to determine
which warnings are acceptable and which must be eliminated to avoid problems
with the release. Other criteria that you may wish to establish can include: design
reviews, code walk-throughs, and system testing. You may also want to establish
standards for commenting the code and identifying bug fixes or approved changes
in the header as part of the criteria for check in. These standards can be
enforced during a code walk-through. Don’t forget to include documentation as
part of the configurable product. Business Requirements Documents, Functional
Specifications, and especially User Manuals are all part of the product you are
building and should all be under the same control as the source code. A change
to the design of a software feature should trigger a change in the Functional
Specification, Detail Design Document, test cases, database Data Dictionary, and
User Manual and each artifact should be identified with the unique identifier
of the change.
Here’s a tip to help the librarian with build issues.
Choosing a good continuous integration tool such as Hudson can eliminate an awful lot of anxiety
at release time. Continuous integration packages can be configured to perform
builds at scheduled intervals, whenever someone checks code into the library,
manually, or any combination of these. The theory behind these tools is that
the librarian won’t be wrestling with code that can’t be integrated with the
application at release time; the developer responsible for new code will have
to trouble shoot integration issues in order to check their code in.
The criteria for checking code into the source library should
be part of a documented Release Management process. The Release Management
process should be the road-map that takes the team from an empty library to a
working software system. Include the steps to take to ready the library for the
build, steps to prepare the various environments for deployment of the release,
steps to take for emergency releases, criteria for emergency releases, and
roles and responsibilities. Gate Review meetings which precede releases should
include the criteria specified in the release process as gating criteria. One
process may or may not cover cut-over activities when the system is released to
the production environment. If it does, special criteria for release to
production should be noted and the rollback strategy defined. The release
process should identify all the tasks necessary for building the software
system, preparation of the environments the system will be installed in, and
the installation of any data required for testing.
Establish code freezes as a part of your release process.
The code freeze will require developers to complete coding, compiling and
testing in advance of the final build and release of the software. The freeze
means that code which misses the deadline for check-in must wait until the next
build for inclusion, or the build must be delayed. Enforcement of the freeze
will be up to the librarian but any corrective actions will be your
responsibility. Penalties for missing a build/release will be an added
incentive to programmers not to miss deadlines. A decision to proceed with a
build and release without part of the software will require a re-cast of the
project plan to include the missing software.
Set the criteria for an emergency release in your release
process. Emergency releases may be required even when you use the waterfall
method of software development. An emergency release will require the librarian
to perform unplanned work to include the emergency fix into the library,
perform the necessary merges, perform the emergency build, and release the
emergency build to the various environments. This unplanned work may impact on
other librarian work especially if the librarian performs programmer duties in
addition to their librarian duties. Emergency builds should always be
negotiated with you and you should determine whether the build under
consideration would put the project behind schedule.
Check out your organization’s knowledge base for any
artifacts that can be re-used such as Release Processes, Cutover Plans, etc.
and then make the necessary modifications to meet your project’s requirements.
Adapting an existing Release Process may be as simple as changing a few names
or dates, or it may be so extensive that it makes sense to ignore it and start
from scratch. The idea here is to eliminate as much work as possible while
still meeting the project’s needs. Making all these plans doesn’t mean that
you’ll have a rock solid Software Configuration Management (SCM) process, but it
will mean that you have provided your project with all the pieces critical for
a successful build and implementation of the software system. Your Release
Process will be a valuable artifact for your organization should it decide to
implement an organizational SCM process which meets CMM or CMMI requirements,
or for future projects.