SCM Process and Activities

Originally from UCM Central

---

Effective Configuration Management can be defined as stabilising the evolution of software products and process at key points in the life cycle. The focus of CM includes:

• Identification of Artifacts
• Version Control
• Development Streaming (Branching)
• Baselining
• Build Management
• Packaging
• Deployment
• Change Request Management
• Issue Tracking

Below we describe each of these briefly.

---

Identification of Artifacts

Early identification and change control of artefacts and work products is integral to the project. The configuration manager needs to fully identify and control changes to all the elements that are required to recreate and maintain the software product.

---

Version Control

The primary goal of version control is to identify and manage project elements as they change over time. The Configuration Manager should establish a version control library to maintain all lifecycle entities. This library will ensure that changes (deltas) are controlled at their lowest atomic level eg documents, source files, scripts and kits etc.

---

Development Streaming (Branching)

To provide some level of stability and allow fluidity of parallel development (streaming) it is quite normal for project development to be split into branches (development groups).

The CM manager has to identify what branches will be required and ensure they are appropriately set up (eg security etc).

Note: Typically branches include

• Developer Branches
• Release Branches
• Emergency fix Branches (i.e. mirror production)

---

Baselining

Baselining provides the division with a concise picture of the project artifacts and relationships at a particular instance in time. It provides an official foundation on which subsequent work can be based, and to which only authorized changes can be made.

Through baselining (i.e. labelling, tagging) all constituent project components are aligned, uniquely identifiable and reproducible at both the atomic level (eg file) and at the higher kit levels.

Reasons for baselining include:

• A baseline supports ease of role back
• A baseline improves CM managers ability to create change reports etc
• A baseline supports creation of new parallel branches (e.g. dev branches)
• A baseline supports troubleshooting and element comparison
• A baseline provides a stable bill of material for the build system

---

Build Management

The fundamental objective of the build management process is to deliver a disciplined and automated build process.

Activities to consider:

• Create automated build scripts (i.e. fetching from repository)
• Enforce baselining before all formal builds (support bill of materials/traceability)
• Set up stable build machines

---

Packaging

Typically the packaging process (see next section) will by synonymous [or tightly coupled] with the build process i.e. the build process will do packaging automatically after the build is complete.

Primary objectives of packaging are:

• Manageable (i.e. often a single zipped up file or exe)
• Reusable (i.e. Try and avoid need for rebuild)
• Secure (i.e. Packages should be free from malicious or accidental modification)

---

Deployment

The configuration manager will typically be involved in the deployment process. Primary considerations include:

• Ensuring deployment automated (reducing possibility for manual errors).
• Promoting best practice concepts concept like promotion based releases (opposed to environmental rebuilds).
• Ensuring releases are authorised and appropriate windows selected for deployment.
• Providing streamlined rollback mechanism in case of problem.

---

Change Request Management

Change Request management can be described as management of change/enhancement requests.

Typically the Configuration Manger should set up a repository to manage these requests and support activities like status tracking, assignment etc.

---

Issue Tracking

Issue tracking is the formal tacking of problems/defects on your systems or environments.

Typically the Configuration Manger should set up a repository to track these problems as they occur, and track there status to eventual closure.

Note: Due to the similarities with production and test defect tracking, it is not unusual to have a single tool to manage all.

-- PatrickEgan? - 17 Dec 2002