Configuration management is normally supported by CASE tools of varying degrees of sophistication, from simple systems designed to support version management to integrated environments that support all CM activities. THE ARGUMENT IS ARITHMETIC: the CM procedures of the previous topics — identification, version control, change control, auditing, status reporting — are all bookkeeping over a large number of items. A project with 2,000 source files, 40 releases and 15 developers has far too many states for manual tracking. The tools exist because the procedures are unenforceable without them. THREE LEVELS OF SUPPORT (Sommerville): OPEN WORKBENCHES tools for each activity, procured separately and integrated by the team. Flexible; the integration is your problem. INTEGRATED systems providing an integrated set WORKBENCHES of facilities for version and change management, and sometimes build support. Less flexible, but the integration works. PROCESS SUPPORT support the definition of processes SYSTEMS such as change management, then guide engineers through the defined process and require them to record their actions. WHAT MAKES A CM TOOL VALUABLE, rather than merely present: · it makes the CORRECT action the EASY action · it records history as a BY-PRODUCT of doing the work, not as a separate documentation task · it makes the current state of every item VISIBLE without anyone being asked · it enforces policy MECHANICALLY, so the standard costs nothing to follow — recall from the SQA topic that a standard enforced by a tool is followed and a standard in a document is argued about

1. VERSION CONTROL SYSTEMS — the foundation. CENTRALISED (CVCS): one authoritative server holds the history; clients hold a working copy. examples: SCCS, RCS, CVS, Subversion, Perforce ✔ simple mental model; central access control; easy to enforce "one true history" ✔ handles very large binary assets well, which is why game studios still use Perforce ✘ the server is a single point of failure; no history offline ✘ branching is expensive in older systems, which discouraged it — and discouraged branching means long-lived divergence DISTRIBUTED (DVCS): every clone holds the FULL history. examples: Git, Mercurial, Bazaar ✔ works offline; commits are local and therefore cheap ✔ branching and merging are cheap by design, which changes team behaviour — cheap branches make small short-lived changes practical ✔ every clone is a backup ✘ a steeper conceptual model ✘ poor with very large binary files (hence Git LFS) THE DESIGN INSIGHT: making an operation cheap changes what people do. When branching cost a day, teams worked on one line and integrated rarely; when it costs a second, they branch per change — which is exactly the small-batch practice the reviews and change-management topics both recommended. THE TOOL SHAPED THE PROCESS, not the other way round. 2. BUILD AND RELEASE AUTOMATION make, Ant, Maven, Gradle, MSBuild, Bazel Their CM role: the build definition IS a configuration item, and it specifies exactly which components at which versions compose the system. A build you can only perform on one person's machine is a CM failure regardless of what the repository contains. Modern build tools add DEPENDENCY RESOLUTION with LOCK FILES — recording the exact resolved version of every transitive dependency, so the same build inputs are used every time. That lock file is the answer to the reproducibility question from the planning topic. 3. CONTINUOUS INTEGRATION SERVERS Jenkins, GitLab CI, GitHub Actions, TeamCity, CircleCI Their CM role: they make the build reproducible on neutral hardware, and they attach evidence — test results, coverage, static analysis — to a specific revision. That evidence is the record an audit needs, produced automatically. 4. ISSUE AND CHANGE TRACKING Jira, Bugzilla, Redmine, GitHub Issues, Trac Their CM role: they implement the change request → evaluation → approval → implementation workflow, and they hold the traceability that impact analysis needs. A commit message referencing an issue id is the source-traceability link from the requirements management topic, created in passing. 5. ARTEFACT AND DEPENDENCY REPOSITORIES Nexus, Artifactory, npm/PyPI/Maven Central, container registries Their CM role: they store immutable, versioned binaries so that "release 2.4.1" is a specific artefact rather than a rebuild that may differ. IMMUTABILITY IS THE POINT — if a published version can be changed or withdrawn, nothing built on it is reproducible, which is exactly what the left-pad incident demonstrated. 6. CONFIGURATION AND INFRASTRUCTURE AS CODE Terraform, Ansible, Puppet, Chef, Kubernetes manifests Their CM role: they bring the ENVIRONMENT under version control, which closes the last gap. A system is not fully reproducible while its servers are configured by hand. 7. DEFECT TRACKING AND TEST MANAGEMENT linking test results and defects to specific versions, so "which release has this bug?" is answerable.

MAP THE FIVE SCM TASKS ONTO WHAT THE TOOLS ACTUALLY DO — this is the practical synthesis of the whole configuration-management group of topics. ───────────────────────────────────────────────────────────── SCM TASK MANUAL TOOL-SUPPORTED ───────────────────────────────────────────────────────────── IDENTIFICATION a numbering scheme every commit has a in a spreadsheet; content hash; every someone must release has a tag; the maintain it identity is intrinsic and cannot drift VERSION CONTROL dated copies in full history with directories; deltas, branches, "final_v3_really" merges, blame CHANGE CONTROL forms, meetings, pull request with diff, email approvals required reviewers, automated checks, recorded merge CONFIGURATION manual inspection the diff IS the audit; AUDITING against the ECO CI proves the checks ran; unapproved changes are visible because every change is attributed STATUS REPORTING a status meeting and a dashboard, generated; a circulated the log is the report document ───────────────────────────────────────────────────────────── THE PATTERN: in every row, the tool converts a SEPARATE DOCUMENTATION ACTIVITY into a BY-PRODUCT of doing the work. That is why tool-supported CM survives schedule pressure and manual CM does not — when a deadline looms, the separate activity is the first thing dropped, and the by-product cannot be dropped without stopping work. WORKED — tracing one defect through the chain: A user reports that fees are wrong for one district. 1. ISSUE TRACKER the report becomes LIC-4471, triaged severity MAJOR, priority P2 2. VERSION CONTROL `git log --oneline -- FeeCalculator.java` lists 14 commits; `git blame` identifies the line and the commit that introduced it 3. TRACEABILITY that commit references LIC-3902, whose change request explains the intent — and reveals the district table was added without updating the default case 4. BRANCH a fix branch is created from the release tag v2.4.1, not from mainline, so the fix does not carry unrelated changes 5. CI the pull request runs 4,300 tests plus a new regression test for this district; coverage and static analysis attach to the revision 6. REVIEW two approvals required by branch protection; the diff is 6 lines, so the review is genuinely effective 7. MERGE + TAG merged, tagged v2.4.2, cherry-picked to mainline so the fix is not lost at the next release — the double-maintenance problem, avoided mechanically 8. ARTEFACT the build produces an immutable artefact recorded against the tag 9. RELEASE staged rollout to 1%, watched, then full 10. AUDIT TRAIL the whole path — report, cause, fix, approvals, evidence, deployment — is reconstructable from records nobody wrote specially STEP 10 IS THE POINT. Every artefact an auditor would want exists, and no one performed a documentation task to create it. Compare this with the 46-hour no-CM incident from the planning topic: the difference is not diligence, it is tooling. THE LIMITS OF TOOLS — worth stating, since this is the last topic of the group: · a tool cannot decide whether a change SHOULD be made; that is the change control authority's judgement · a tool cannot tell you whether your branching strategy fits your release model — teams routinely adopt a workflow that contradicts how they actually ship · commit messages, issue descriptions and review comments are written by humans, and their quality determines whether the history is useful in three years. A repository of "fix stuff" commits has version control without having traceability. · tools make bad process fast. An automated pipeline that deploys unreviewed changes to production is not an improvement over a manual process that reviews them. THE TOOL ENFORCES THE POLICY YOU CONFIGURE. Choosing the policy remains an engineering judgement, and that judgement is what this entire unit has been about.