What is Software Configuration Management?
Software Configuration Management (SCM) means many things to many people. An excellent place to start is to define the goals of SCM. A good SCM process makes it possible for developers to work together on a project in an efficient manner, both as individuals and as members of a team. Based on different publications we can state that successful configuration management should enable the following:
· Configuration identification: Developers should be able to work together on a project, sharing common code. This allows a developer to fix a bug in the source code for release A while another developer is developing a new feature that is scheduled for release B.
· Configuration control: Ensures that proposed changes to configuration items are fully coordinated and documented. This can for example include the switch from .NET 1.1 to .NET 2.0.
· Status accounting audit: Recording and reporting the status of components and change requests and gathering vital statistics about components in the product. For example: How many files were affected by fixing a bug.
· Configuration Verification and Audit: Verify that a product’s requirements have been met and the product design that meets those requirements has been accurately documented before a product configuration is released. It’s important to remember that this state needs to be maintained through the entire project lifecycle.
· Build management: Manage the processes and tools that are used to create a repeatable and automatic build.
· Process management: Enforces consistent processes and promotes user accountability across the application life cycle, resulting in communication and productivity improvements enterprise-wide. You can really see this as getting the heads pointing in the same direction.
· Teamwork: Controlling the work and interactions between multiple developers on a product. For example, this addresses the question, "Were all the locally made changes of the programmers merged into the latest release of the product?"
SCM did not grow out of a managers wish to limit and control developers in their creativity. It is there to protect you from rogue behavior. The "active rogue" is easier to identify and control because it's out in the open and often verbal. The passive rogue is pretty much anyone on the team who will sacrifice quality when the heat starts to rise.
When crunch time comes, and it will come believe me, you need a process that keeps people from being tempted to put in quick fixes that ultimately degrades the quality of your application.
I hope that this post has given you an understanding of what SCM has to offer to yourself and your organization. In a following post I will elaborate on the theoretical and practical sides of the wonderful world of the software configuration manager.
04/25/2005 20:29:32 UTC