Question 6 of 10: Configuration Management

Question 6: Configuration Management (a) 5, (b) 5, (c) 10 — 20 marks

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Configuration Management

Configuration management (CM) is the discipline of managing an evolving software system so that every change is controlled, tracked, and reproducible. A software system's configuration is the complete set of artifacts that together define a particular version of it — source code, requirements and design documents, test suites, build scripts, and third-party library versions — and CM is responsible for uniquely identifying every version of every one of those items, controlling how and by whom a change to any of them is approved and applied, recording which combination of item-versions makes up any released or buildable configuration, and being able to reconstruct any past configuration exactly on demand. CM exists because, without it, an uncontrolled or undocumented change to any one item can silently make the system unreproducible, un-buildable on a different machine, or impossible to roll back to a known-good state.

(b) Configuration Management vs. Version Management

Version management (or version control) is one specific, mechanical part of configuration management: it is the tool-level capability of storing successive revisions of an individual artifact (typically a source file), allowing any past revision to be retrieved, and merging concurrent edits by different developers. Configuration management is the broader process discipline built on top of version management: it governs which combination of specific artifact versions is assembled into a named, released configuration; it defines the change-control process (change requests, review, and approval) that decides whether a proposed change is allowed into the next configuration at all; and it extends beyond source code to the build scripts, environment, and third-party dependency versions needed to reproduce a build, none of which a version-control tool alone tracks or governs. In short, version management answers "what were the successive states of this one file," while configuration management answers "which exact set of file-versions, build settings, and approved changes constitutes release 3.2, and can I rebuild it."

(c) Programmer's Guidelines for Controlled System Building

The file-naming problem described is a special case of a broader failure mode — letting an assumption about the build/target environment leak directly into source code as a literal — and the guidelines below address both that specific case and the wider class of system-building problems it exemplifies.

1. Never embed absolute or hard-coded file paths in source code. A path such as "/usr/local/app/data/config.txt" or "C:/App/data/config.txt" assumes a specific file-system layout that will not exist on a different machine or operating system. Reference files by a relative path or a symbolic name resolved through configuration at run time, never by a literal path baked into the code.
2. Centralize every file/path name in one configuration module or build variable, never scattered as literals. When every file reference in the system is a literal string typed independently in dozens of places, porting to a new target requires finding and editing every occurrence, and any one missed occurrence reintroduces the original problem. A single named configuration point makes the port a one-line change.
3. Use the platform's/language's portable path-handling facilities rather than manual string concatenation. Manually joining directory and file names with a hard-coded separator character silently breaks on a target that uses a different separator or path convention; the standard library's path-join facilities abstract this away.
4. Keep environment-specific settings (paths, host names, credentials, device identifiers) out of compiled code entirely, in an external configuration file or environment variable read at start-up, so that redeploying to a new environment never requires recompiling or even reading the source.
5. Place build scripts and makefiles under the same version control as the source, and treat a change to them with the same review discipline as a change to source code. A large share of "it built on my machine but not on the build server" failures trace to an undocumented or unreviewed change to the build recipe rather than to the program logic itself.
6. Automate the build through a continuous-integration system rather than relying on any one developer's local machine state. A build that depends on manual, undocumented steps or on files that happen to already exist on one engineer's workstation is not reproducible, and reproducibility is a prerequisite for being able to rebuild an old release exactly.
7. Record, for every release, the exact source revision, configuration, and toolchain (compiler and library versions) used to build it, so that any past release can be reproduced or rolled back exactly — this is the core configuration-management discipline that the rest of these guidelines exist to support.
8. Periodically build and deploy on a clean machine that mirrors the target environment, not only on developers' own machines, since a developer's workstation accumulates incidental state (installed libraries, cached files, environment variables) that can silently satisfy an assumption the target environment does not share.

Guidelines 1–3 directly address the file-name/file-structure problem stated in the question; guidelines 4–8 generalize the same underlying principle — that any assumption about the environment a program will run or be built in must be made explicit and externally controlled, never implicit in the code — to the wider set of system-building problems (missing dependencies, undocumented build steps, environment drift) that configuration management exists to prevent.