Configuration Management

1. What is Software Configuration Management?

Software Configuration Management (SCM) is the discipline of controlling and tracking changes to a software system throughout its life. It manages the configuration items — all the artifacts that make up the software, from code to documents to build scripts — and every change made to them.

SCM answers the questions every team faces: what version of the code is in production? What changed between versions? Who changed it and why? Which versions are compatible with each other? Can we rebuild an old release exactly? Without SCM, software quietly drifts — nobody knows what is deployed, changes are lost or overwritten, and a release cannot be reproduced.

SCM is implemented through activities: configuration identification (naming and organizing the items), configuration control (governing changes), configuration status accounting (recording the state of everything), and configuration auditing (verifying the records match reality). In practice it is realized by version control systems (Git), build and release automation, and change management processes. SCM is the control layer that makes coordinated teamwork and reliable releases possible.

2. What are the activities of configuration management?

Configuration management has four classic activities. Configuration identification names and organizes the configuration items — every artifact that must be controlled (code, documents, data, build scripts) gets a unique identifier and a versioning scheme, and the structure of the items is defined.

Configuration control governs changes — every proposed change to a baselined item goes through evaluation, approval, and documentation before it is made. This is the change control process. Configuration status accounting records and reports the state of the configuration — what versions exist, what changes have been made, who made them, and where each item stands. It is the bookkeeping.

Configuration auditing verifies that the records match reality — that the documented configuration actually exists and that the delivered software matches the approved configuration. Audits catch the drift between what should be and what is. Together these four activities form a complete control loop: identify what must be controlled, control changes to it, record what is happening, and verify it is true.

3. What is configuration identification?

Configuration identification is the first activity of configuration management — deciding what must be controlled and giving each item a unique identity. It establishes the baseline of the project’s artifacts.

The work involves selecting the configuration items (CIs): every artifact that should be versioned and controlled — source code files, requirements documents, design documents, test cases, build scripts, configuration files, and data. Each item is given a unique identifier and a versioning scheme, and the structure of the system — which items belong together — is defined. The identification also defines how items relate: which versions of one item are compatible with which versions of another.

Configuration identification is the foundation because you cannot control what you have not named. It answers “what is this thing, which version is it, and where does it sit in the system?” Without identification, version control and change control have nothing to attach to. It also enables reproducibility — with each item identified and versioned, a specific configuration of the system can be exactly reconstructed.

4. What is configuration control?

Configuration control is the activity of governing changes to configuration items — ensuring that no change happens by accident, uncoordinated, or undocumented. It is the process that decides what changes, when, and by whom.

The control mechanism is the formal change process. A change request is submitted describing the proposed change and its rationale. The change is evaluated for impact — what items are affected, what it costs, what it does to schedule and quality. Then it is approved or rejected by the appropriate authority — often a Change Control Board for significant changes. Approved changes are implemented, reviewed, and their results recorded. The version control system captures the new version, and the change is traced.

Configuration control matters because uncontrolled change is how software decays. Without it, two people change the same file unknowingly, changes are made and lost, and the deployed product diverges from what was approved. Control provides the discipline that makes the other activities meaningful — identification names the items, control governs what happens to them, status accounting records it, and auditing verifies it.

5. What is configuration status accounting?

Configuration status accounting is the bookkeeping activity of configuration management — recording and reporting the current status of every configuration item and every change. It answers “what is the state of the configuration right now?”

It records: what versions of each item exist, which configuration has been approved and baselined, what change requests are open, approved, or implemented, what the disposition of each change was, and who made what change when. The records are maintained continuously and made visible through reports — status reports, change request logs, and version histories.

Status accounting provides the management visibility that control needs. It shows whether the system is in a known, approved state or drifting. It supports audits (the records are the audit evidence) and troubleshooting (which version is in production, what changed in it). Its value depends on accuracy — the records must be updated faithfully, because the whole point is that the reported state matches the real state. Without status accounting, configuration management is blind.

6. What is configuration auditing?

Configuration auditing is the verification activity of configuration management — checking that the documented configuration actually matches reality. It is the quality check on the configuration records.

There are two kinds of audits. A functional configuration audit verifies that the software performs as specified — that the configured product actually works as the documentation claims. A physical configuration audit verifies that the delivered software — the code, documents, and data in the release — matches the approved, baselined configuration exactly: the right versions, the right items, nothing missing, nothing extra.

Audits catch the drift that accumulates in every project — a change made but not recorded, a release assembled from the wrong versions, a document updated but not the code it describes. They are especially important before release and in regulated environments. The audit is what makes configuration management trustworthy: the records say what the configuration should be, and the audit confirms that is what it is. Audits are also where the cost of sloppy bookkeeping surfaces — an un-auditable configuration is an uncontrolled one.

7. What is a configuration item?

A configuration item (CI) is any artifact that is placed under configuration management — an entity that must be identified, versioned, controlled, and tracked. It is the unit that configuration management manages.

Configuration items include everything the project produces and needs: source code files, requirements and design documents, test cases, build scripts, configuration files, data, libraries, and documentation. A CI can also be an aggregation — a subsystem or a complete release — that bundles many smaller items into one controllable unit.

The principle is that anything whose version and content matter — anything a change would affect, anything needed to reproduce or audit the product — should be a configuration item. Each CI has a unique identifier and version history. The art is choosing the granularity: too coarse and you cannot control changes; too fine and the overhead swamps the project. A well-defined set of CIs is what makes version control, change control, and reproducible builds possible.

8. What is a baseline?

A baseline is a formally approved, frozen version of a configuration item or a set of items — a snapshot in time that becomes the reference point for all future work. Once baselined, an item can only change through the formal change control process.

Baselines mark the major milestones of the project: the requirements baseline (the approved SRS), the design baseline (the approved design), the code baseline (a completed, tested version of the code), and the product or release baseline (the shipped configuration). Each baseline is the official state of the work at that point, agreed by the stakeholders.

The baseline’s purpose is stability and reference. Developers and testers work against a defined baseline rather than a moving target. If something goes wrong, the team can return to a baseline. And every later change is measured against it — a change to a baselined item is a formal event, not an edit. Baselines are what turn configuration management from bookkeeping into control: they are the frozen states that make changes visible and releases reproducible.

9. What is change control?

Change control is the process of managing changes to baselined configuration items in a controlled, coordinated, and documented way. It ensures that changes are evaluated, approved, and recorded rather than made ad hoc.

The process follows a defined flow: a change request describes the proposed change and its reason. The impact is analyzed — which configuration items are affected, what the cost is, what the schedule and quality impact is, what alternatives exist. A decision authority — for major changes, the Change Control Board — approves, rejects, or defers the change. Approved changes are assigned, implemented, reviewed, and their results recorded in the configuration status.

Change control is the discipline that prevents the two failure modes of software projects: uncontrolled change (scope creep, silent drift, broken integration) and no change at all (the project frozen against reality). It makes every change a visible, priced, agreed event. The distinction in interviews: change control governs how a change is processed; version control governs how the code itself is recorded. Both work together — the change process authorizes, version control captures.

10. What is version control?

Version control is the system that records and manages changes to files over time, giving every version of every file a history. It is the tool layer under configuration management — the mechanism that tracks who changed what, when, and why.

A version control system (Git, SVN) stores files in a repository, tracks each change as a commit with a message and author, and lets developers create branches to work independently and merge their work back. It provides: a complete history (any version can be recovered), collaboration (many developers working on one codebase without overwriting each other), branching and merging, and tags for marking releases.

Version control answers the practical daily questions: what changed in the last commit? Which version was released? How do I get back to the version from last week? It is the foundation of modern development — continuous integration, code review, and deployment all build on it. The distinction: version control manages files and history; configuration management is the broader discipline of controlling configuration items, changes, and baselines, of which version control is one mechanism.

11. What is a Change Control Board?

A Change Control Board (CCB) is a group of stakeholders that evaluates and decides on proposed changes to a project. It is the decision authority of the change control process — the body that approves, rejects, or defers changes to baselined items.

The board typically includes representatives from the areas a change touches: the project manager, lead developers, test lead, product owner or customer representative, and sometimes operations and legal. Its membership is chosen so that the full impact of a change — technical, schedule, cost, quality, and user impact — can be assessed.

The CCB reviews each change request against the impact analysis: what is the cost, what is the benefit, what does it do to the schedule and scope. It then decides — approve, reject, or defer — and the decision is documented. The CCB’s value is centralized, accountable decision-making. Without it, changes are decided ad hoc, inconsistently, or by whoever shouts loudest. The CCB also protects the project from scope creep by making every change a deliberate, reviewed decision rather than a silent addition.

12. What is the difference between configuration management and version control?

Version control is a tool and mechanism — it records and manages changes to files over time. Git tracks every version of every file, preserves history, supports branches and merges, and makes any past state recoverable. It is the foundation layer: the file-level versioning.

Configuration management is the broader discipline — the set of processes and activities that control the whole software configuration: identifying configuration items, governing changes through control processes, recording status, and auditing. Version control is one mechanism that SCM uses, but SCM also includes baselines, change control boards, status accounting, audits, and the management of non-code artifacts.

The practical distinction: version control answers “what versions of these files exist and what changed?” Configuration management answers “what is the approved state of the system, how do changes to it get decided, and can we reproduce exactly what we delivered?” Version control is a necessary component of configuration management, but configuration management is a process discipline that version control alone does not provide. All SCM includes version control; not all version control is SCM.