Question 7 of 9: Configuration Management

Question 7: Configuration Management (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.

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.