1. Software Configuration Management
“The art of progress is to preserve order amid change and to preserve change amid order.”
--Alfred North Whitehead
“I don't care if it works on your machine! We are not shipping your machine!”
-- Vidiu Platon

2. What is Software Configuration Management (SCM)?
Software configuration management is the discipline concerned with identifying the important components of software systems and then taking steps to preserve the integrity of these components throughout the software life cycle.
SCM is much more than just source code control (SVN, CVS, git, etc.).
“CM is the art of identifying, organizing, and controlling modifications to the software being built by a programming team.”
Of all the major topic areas in software engineering, SCM is probably the most misunderstood. One explanation is you can get a lot of experience writing software without ever having to deal with SCM. Topics such as requirements, design, implementation and testing are experienced to some degree on any software project. It’s conceivable you could write a lot of software with little or no exposure to SCM. SCM is crucial for companies supporting multi-version products.
Hard to relate too . . .
0 CM? Maybe source code control with SVN or git. Imagine …
The processes of CM are to insure “integrity, accountability, visibility, reproducibility, project coordination and traceability, and formal control of system and project evolution.”

3. Problems Avoided by Effective Configuration Management (CM)
Your company lost the source code to a mission critical program. The CIO wasn’t amused when you quipped, “Hey, at least we didn’t lose the binary as well!”
Several developers are working on the same module. Changes made by one developer overwrite changes made by another.
There are multiple versions of a document out for review and no one is quite sure which is the most recent.
You need to back out source code changes associated with a new feature added last week but you can't remember all of the modules changed and don't have a copy of the system state prior to making the changes. Worse yet, some of the modules have had subsequent changes since you made your change. Help!
Your project is bogged down in what seems like an endless cycle of integration and testing. The root cause of the problem seems to be related to several small changes made at the last minute. Taken individually none of the changes are destabilizing, but no one considered the combined affects of making all of the changes at once.
A customer finds a bug which is reported and promptly fixed. The customer later upgrades to a newer release and rediscovers the same bug.
A customer finds a bug in an older version of your software. You can't fix the bug because you can't duplicate the version of the system which the customer is running. You offer the customer a free upgrade to the latest version, but that is unacceptable because the customer doesn’t have the time to install an upgrade.
SCM serves multiple objectives. Perhaps the best way to appreciate the scope of SCM is to consider the problems it is intended to solve.

4. Activities that involve Configuration Management
If you have only worked on small single-person projects, your exposure to SCM is probably minimal. In order to better understand the scope and purpose of configuration management, here are some example day-to-day activities that involve SCM.
Background
Classroom Today is the signature software product from the Acme Corporation. It is an online course management system used by hundreds of schools across the US and around the world. Version 3.0 is currently undergoing system test and is scheduled to be released August 1st. The latest production version is 2.3 but Acme is also offering security and bug fixes for versions 2.2, 2.1 and 2.0.
Commercial software vendors often have to support existing customers at the same time they are working on new product development. This raises a number of thorny issues that SCM solves.
When writing software for your own personal use, finding a defect in your code is no big deal. You fix it and select Project/Rebuild. A code change isn’t so simple with most commercial software development. Most companies doing commercial software development have multiple versions of their software products in production at one time. Find a defect in file foo.c and you might have several copies of foo.c to change and then build and test with the correct version of the system.

5. Day-to-day SCM Activities
A customer reports a problem with using Unicode in bulletin board posts. Unicode support was added in version 2.0 and there have been several unicode-related bug fixes since it was introduced. Patty, a programmer at Acme, is assigned to work on the issue. The first thing she does is use the SCM system to retrieve records on all fixes since version 2.0 related to problems with unicode characters. She reviews the records to get an idea what has been done in the past. After some investigation she realizes it is a problem in versions 2.0 and 2.1 only. She tracks down the defect to a specific source file. She checks out the version 2.0 version of this file, makes the fix and builds and regression tests a 2.0 version of the system. She checks out the 2.1 version of the same source file and repeats the change and builds and regression tests the 2.1 version of the system. She copies the updated binary components to the patch staging area for versions 2.0 and 2.1. It isn’t a critical error, so the fixes will go out with the next scheduled update for these two versions.
(Ability to track the status of change requests.) Harry at the help desk gets a call from a customer asking when a certain defect will be fixed. Harry users the SCM system to check the status of the fix. “It has been fixed and the patch will ship with the next update which is scheduled for May 29th.”
Mary in marketing fills out a change request to allow instructors to add comments to a student’s grade book item that are visible only to the course instructor.
Change control board meets and accepts 8 of the 12 change requests, including Mary’s request for instructor-only comments on grade book items.
Users report a problem with a fix that was made in the past. Analyst uses the SCM system to pull up information about the fix: nature of the problem and what was done to fix it.
During system integration it was discovered that an unapproved change was added. Investigation showed it was a new feature meant for the next version of the product but somehow got included in the current build instead. The change was backed out of the current version using the source code control system. (SCM ensures no changes are made without proper authorization.)
Auditing and verification mechanism is used to ensure what is being developed and delivered is exactly what was required and specified.
A defect was found in a certain version of a source code file. The SCM is used to identify which releases might be affected.
Management is curious to know if the quality is increasing, decreasing or staying the same between releases. They query the SCM for number of reported faults in version 3.2 compared to version 3.1.
Use the SCM system to find the last three changes and person making the changes. Might consult the person before making your own changes.

6. The Ultimate CM Problem
Developing software for the space shuttle has been described as "the ultimate configuration management problem." [Spector 84]
Space Shuttle flight requires a new version or release of the main flight control software. The high reliability and safety requirements for Space Shuttle software necessitates long development times for each release. It takes several months to prepare one release. Several flights a year are planned, so at any one time there are multiple releases at various stages of development. The figure below shows the situation during March 1983 when there were 4 releases under development. The image shows 4 releases all "branched" or derived from the main code base. Counting the main code base, engineers had to keep track of 5 different code bases at one time.
Engineers also have to maintain the associated requirements, test cases and other work products associated with each release. The similarities between releases is much greater than their differences so a change to one release has to be analyzed relative to all releases. Engineers use configuration management procedures to ensure changes are carefully planned and executed.

7. Standard Practice of Software Configuration Management
Configuration Identification
Configuration Control
Configuration Status Accounting
Configuration Auditing
The purpose of CM is to establish & maintain integrity of products throughout the software life cycle.
An important part of CM is requirements management.
Not every project needs the full range of configuration management functions but all projects regardless of size and formality can benefit from basic principles of configuration management. 

8. Configuration Identification
Configuration management starts with identifying the work products that will be subject to configuration management and then assigning each one a unique identifier. Items subject to formal configuration management are called configuration items (CI).
Example items that can benefit from CM: Requirements, design, project plans, source code, test plans, test cases, tools used to build product.
CI: – work products are uniquely identified.

9. Configuration Control
Configuration control ensures that changes made to configuration items are reviewed, approved and documented. Many organizations use configuration control boards (CCB) to review and authorize changes to configuration items.

10. Example change control procedure
General flow of a change control procedure
Change requests / problem reports are initiated, reviewed, approved & tracked to closure
authority for managing baselines exists
CC = The process and procedures to identify, document, review, and authorize any changes to the software under configuration management [5]

11. Code Lines
A codeline is a set of work products used for a specific purpose that are bound by the same configuration management policy.
During development and while an application is in production it's often necessary to maintain multiple code bases or codelines.
Figure y above illustrates a development project with one released version and another in development. The mainline codeline represents the primary code base from which other codelines are branched. It's a good practice to have a mainline codeline from which all releases and projects are branched. [Wingerd 98] The release codeline at the top of the figure represents a released version of the system. It must be maintained to provide bug fixes to customers that can't or don't want to upgrade to the latest version. The project codeline at the bottom of the figure represents the code base for the next version of the software. Having a separate project codeline for the next release allows changes not destine for immediate release (the project codeline) to be integrated into the mainline codeline.
Branching new codelines should be done sparingly. Maintaining separate codelines leads to complicated multiple maintenance of work products. Most changes on branched codelines also have to be merged back into the mainline codeline eventually.
There are different names for the different evolutionary stages of a product: version, release, update. Version represents a major change, release a smaller set of changes, and update an even smaller set of changes. For example, Windows is version 3, release 1, and update 5.

12. Configuration Status Accounting
Status accounting is the practice of keeping track of and reporting information on changes made to configuration items (i.e. who made the change, why it was made, when it was made, etc.). Status accounting improves project visibility and control.
Status and content of each build is recorded
All changes to baselines are done with a request for change
Changes to baselines are controlled according to a documented procedure
Products from the baseline are created and their release is controlled according to a documented procedure
status of CIs is recorded according to a documented procedure

13. Configuration Auditing
Configuration audits are used to assess compliance with configuration management procedures and to evaluate the degree to which configuration items reflect their requirements and specifications.
“Independent examinations of work products and activities to assess compliance with designated criteria”
Physical Configuration Audits (PCA)
Validate that the product physically can be build using the documentation
Functional Configuration Audits (FCA)
Validate that the product documentation is according to the plan(s)
describes a product that meets the requirements

14. Topics Source Code Control/Management Builds System Integration
Change Control and Defect Tracking
Release Management

15. Version Control Collaboration Models
The main function of a version control system is to allow collaborative editing and sharing of data.
There are two main strategies for enabling this:
Lock-Modify-Unlock (aka reserved checkout)
Copy-Modify-Merge (aka unreserved checkout or optimistic checkout)

16. Lock-Modify-Unlock

17. Copy-Modify-Merge

18. Baseline Depending on context, the term baseline may refer to:
A specification or product that has been formally reviewed and agreed upon, thereafter serves as the basis for further development, and can be changed only through formal change control procedures [3].
A document or a set of such documents formally designated and fixed at a specific time during the lifecycle of a configuration item [3]. (Similar to branch)

19. Misc.
The ease with which software can be changed is both an asset and a liability. It's an asset because, compared to hardware, software is relatively easy to change. This pliability makes it possible to respond quickly to change requests and defect repair. It's a liability because unrestrained changes make software development and maintenance more difficult. While it's relatively easy to change the behavior of a software system by making changes to source code and recompiling, it's much harder to foresee the consequences of the changes. Software is abstract so it's difficult to comprehend the dependencies between different parts of a software system. The problems with changing software are increased when there are multiple stakeholders, multiple versions of the system that have to be maintained, and the changes are performed by a team of programmers rather than a single individual. Software design mitigates the technical obstacles to changing software and CM mitigates the non-technical procedural problems with making changes to software.
CM preserves the integrity of work products.
Configuration management is a discipline for managing the evolution of software systems. Configuration management seeks to preserve software's "softness" or ability to change by managing the (non-technical) complexities associated with this ability to change.
Briefest non-technical analogy for understanding what configuration management is about: Configuration management is the technology that allows you to Put Humpty Dumpty back together again.
In other words, it allows you to know the state of the software system at any time and to reconstruct any release/version/update. It does this primarily by managing configuration items (requirements, designs, code) and changes to these CI's.
Software configuration management is the discipline concerned with identifying the important components of software systems and then taking steps to preserve the integrity of these components as the product evolves and the project moves forward.
The purpose of Software Configuration Management (SCM) is to establish & maintain integrity of products throughout the software life cycle.
SCM is more than just using a version control tool.