Software Configuration Management and DevOps
Domain 6 tests how artifacts are identified, versioned, integrated and released. Questions typically involve branching strategy, semantic version numbers, pipeline meaning and release strategy selection.
Configuration management fundamentals
A configuration item is any artifact under change control; a baseline is an approved, repeatable snapshot; a change control board authorizes changes; configuration audits verify that what was built matches what is recorded. Branching options include trunk-based development with short-lived branches and feature flags, versus GitFlow with long-lived develop and release branches. Prefer small atomic commits with meaningful messages. Merge preserves history; rebase rewrites commit identity, so never rebase a shared public branch. Semantic versioning is MAJOR.MINOR.PATCH: MAJOR for backward-incompatible changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes; versions below 1.0.0 are explicitly unstable.
DevOps and pipelines
Continuous integration means every commit triggers a build and automated tests. Continuous delivery keeps the product always releasable with a manual production approval; continuous deployment releases automatically. A typical pipeline runs build, unit and integration tests, static analysis and dependency scanning, publishes to an artifact repository, deploys to staging, runs automated acceptance tests, then promotes. Release strategies: blue-green keeps two environments and switches traffic for instant rollback; canary sends a small traffic slice first; rolling replaces instances gradually. Infrastructure as code gives reproducible, idempotent environments, and secrets belong in a vault rather than the repository. DORA metrics are deployment frequency, lead time for changes, change failure rate and time to restore service.
Worked example
Your library is at 2.4.1 and you remove a deprecated public function. Reasoning: removal breaks existing callers, which is a backward-incompatible change, so the new version is 3.0.0. If instead you added an optional parameter while keeping the old signature working, the change is backward compatible with new functionality, so 2.5.0. If it were a bug fix with no interface change, 2.4.2. The disciplined path is to deprecate first, ship the removal only in the next major so downstream users can migrate.
Traps that cost marks
- Calling a pipeline continuous deployment when it stops for manual approval at staging.
- Committing secrets, build outputs or local configuration instead of ignoring and externalizing them.
- Confusing lead time for changes with time to restore service.
- Long-lived branches and rare merges, which produce integration pain.
- Describing DevOps as a toolchain rather than collaboration plus automation.