Software Engineers Handbook/Supporting Processes/Configuration Management

Here is the Wikipedia description of configuration management.

Assessing the size of the development team and the scope of the development are two things that need to be identified very early in the project. The larger the team, the more important it is to develop a configuration management strategy that keeps the developers moving without stepping on each others' toes (having a tool that supports a local developer sandbox, integration, and release areas automatically as opposed to "making them by hand", like we've always done). The more complicated the development, the more complicated the configuration management strategy. Specifically, is support of multiple releases of the same product necessary? If so, a heavier weight configuration management strategy (one that supports branching) is more desirable.

Being able to automatically re-create software from the baseline repository is a must, independent of size of project or team. It provides product predictability expected of manufacturing processes.

Some popular tools to support configuration management include:

• Makefile and make: Originally these were designed to allow a programmer to tweak one source file and then type "make" to regenerate all the executables, without having to remember the exact name of each and every source file or the exact compile-time options for each one. Today, many programmers also include regression tests in the Makefile.
• distributed version control systems. A programmer uses a VCS to pull the latest version (tip) from the repository into a sandbox (also called a working directory), test it out, make some changes, and then commit any improvements back into the repository.
• ...

References

• make
• 828-1990 IEEE Standard for Software Configuration Management Plans ISBN 0-7381-0394-2
• 1042-1987 IEEE Guide to Software Configuration Management ISBN 0-7381-2378-1