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