Software Configuration and Release Management
Configuration management (CM) keeps the evolving product under control. Know its four pillars: identification (what are the configuration items - code, docs, build scripts, environments), control (change management, baselines, approval), status accounting (what version is where, what changed), and audit/verification (does the delivered artifact match its specification and baseline). A baseline is an approved, frozen reference point against which change is measured.
Understand branching and merging strategies - trunk-based development, feature branches, release branches - and their trade-offs: long-lived branches reduce integration pain but increase merge risk. Grasp continuous integration (frequent integration with automated build and test), continuous delivery (always releasable), and continuous deployment (auto-release to production) as distinct levels. Know build reproducibility, artifact repositories, semantic versioning (major.minor.patch signaling breaking/feature/fix), and release vs. deployment as separate acts.
Traps: treating version control as synonymous with configuration management (it is one tool within it); confusing continuous delivery with continuous deployment; assuming a hotfix should skip the baseline or audit trail; and questions about "which version is in production?" where status accounting is the missing discipline. Also watch for change control that is so heavy it blocks emergency fixes - balance is the point.
Rule of thumb: if you cannot reproduce the exact build from recorded inputs, you do not control your configuration.
Worked example: A production bug appears. The team must identify the deployed artifact (status accounting), branch from the release baseline (control), fix, test, and record the change (audit) - not patch the server by hand.