09 · Run & release · Repeatable artifacts
A package built on a laptop cannot be built again next week
The DevOps engineer turns build, config, and release into a repeatable pipeline. Production must not depend on a handmade package from someone’s laptop. Which warehouses open, and when, sits with the release manager.
Development: This machine just compiled. Uploading from here is fastest.
DevOps: Production takes pipeline artifacts only. A local package has no build number. On rollback nobody knows which version to go back to.
The DevOps engineer makes the same commit always produce the same package
Environment drift is a common source of go-live failures. The mark of this role is keeping build, test, artifact, and config apart. Code version, locked dependencies, build number, and config items: missing any one of them, it does not go to production. He does not treat a one-line edit on the server plus a restart as a release. That change has no record. The next deploy overwrites it, and the fault comes back.
The pipeline has at least the gates that automation holds. If a gate is red, the artifact cannot enter the release candidate. Split with the Release manager: DevOps guarantees the candidate is traceable; the release manager decides when which warehouses open. With no candidate, the release manager can only pass packages by hand.
Config does not go into the package
Database addresses and secrets do not enter the code repository. Environment differences are injected as config. DevOps keeps the build steps the same in test and production; only config differs. If the steps differ, a passing test does not mean production can start. Secret rotation has an owner. Secrets are not pasted into a group announcement.
A hotfix of unknown origin
Once a production fault was fixed by a colleague who built a hotfix on a laptop and replaced the files. That day recovered. Three days later another colleague released from the pipeline, overwrote the hotfix, and the fault returned. The DevOps engineer banned further local uploads, turned that hotfix into a commit, let the pipeline produce the artifact again, and replaced it in the release window. The rollback button pointed at the previous build number. Rollback was drilled once. After that, a file with no build number could not be uploaded even with a server account.
The limit costs a few minutes on an emergency fix. The slowness it prevents is the slowness of nobody being able to build the package again. The DevOps engineer requires rollback and forward to use the same pipeline. If rollback is a manual copy back into a directory, the files in that directory may still be laptop builds. In drill he rolls back from a build number, then goes forward from a build number, and records duration both times. If duration exceeds the window, fix the pipeline first, then talk about emergency release. Emergency release is the easiest way to wash this discipline out, so it must be drilled in advance. A renamed config item must stay compatible with old candidates. A new service that only knows the new name will not start after rollback of the old service. A rollback that will not start is no rollback. He keeps lockfiles and the build cache apart. Cache may speed things up. It must not change artifact contents. Skipping locked dependencies for speed lets a build quietly upgrade a library. Behaviour changes with no commit to find.
A change with no commit is the most dangerous kind, because rolling back the code still cannot go back. The pipeline would rather be a little slower and let the same commit produce the same digest. A production environment-variable change must be written back to the config repository. Otherwise the next deploy wipes the line that saved you. Artifact digests are kept past the version’s retirement. When tracing what production ran in a given week, a digest is more reliable than memory. Rollback and forward use the same pipeline: back from a build number, then forward from a build number. If rollback is a manual directory copy, that directory may still hold a laptop package. A file with no build number cannot be uploaded even with a server account. Which warehouses open, and when, is still the release manager’s decision.
If the build-agent clock and the artifact-repo clock differ by more than two minutes, matching digests can still treat an expired signature as valid. He requires the pipeline to sync clocks before it stamps an artifact, and writes the agent hostname into the build record. Production refuses an artifact with no hostname.