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 development environment.

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.