← Change management: production decisions
03 / 5 · 18 MIN

Connect the approved artifact to recoverable state

Control versions, configuration drift, and persistent effects.

Concept and mechanism

A release name is insufficient when it can point to different files. Connect the approved commit, build, artifact, and configuration to what will run. An immutable identifier helps verify that the installed binary is the one tested; it does not itself prove functional correctness. Also record parameters, permissions, and dependencies that affect the outcome. If disk and running configuration differ, investigate activation, scope, and instance before declaring success.

Guided application

Recovery must consider data produced after the change. An older application may not understand a new schema or messages already emitted. In a fictional exercise, first add a compatible field, migrate consumers, and remove the old field only when compatibility is no longer needed. This sequence is a design option, not a universal rollback guarantee. The plan should state what is recovered, which transactions need reconciliation, and how to validate the service. A backup without a rehearsed restore does not establish the deadline.

IN PRACTICE

Package 4.2 was rebuilt after approval. Its name stayed the same but its hash changed. Before execution, reconcile artifact, tests, and authorization; do not assume equivalence from the name.

Common pitfalls

Using mutable tags as identity evidence; promising rollback without assessing new data.

Related topics: Execution and impact control · Validation, closure, and improvement

Take this idea with you

Repeatability and recovery require knowing artifact, configuration, and state.

Create account

Reference: Release engineering · DR Change Management 2026.1; independent technical curriculum