Make Deployments Boring

Written by

in

The best deployment is usually the one nobody talks about afterward. It built the intended artifact, applied the intended configuration, passed its checks, and left enough evidence to explain what happened.

Separate the three questions

A deployment pipeline often becomes confusing because it tries to answer several questions at once:

  • Did the source produce a valid artifact?
  • Is the target configured correctly?
  • Did this release become active?

GitLab CI/CD is a natural place to answer the first question. SaltStack is a natural place to answer the second. The release step should connect the two without hiding either result.

Make the release identifiable

Every deployed version should have an identifier that appears in the pipeline, the artifact, and the running service. It can be a commit, build number, or release label. The exact format matters less than being able to map a running process back to the change that produced it.

Converge before switching

Configuration should be applied and checked before traffic or a worker is switched to the new release. This catches missing packages, permissions, directories, and service settings while the old version can still provide a recovery path.

Rollback should be a known operation

“Deploy the previous version” is not a rollback plan unless the previous artifact and compatible configuration are still available. Keep the recovery action explicit, test it occasionally, and make sure the operator can tell whether the rollback completed.

Measure the handoff

Useful deployment logs show the transition between systems: which pipeline produced the release, which configuration revision was applied, which target accepted it, and what health check passed afterward. That small chain of evidence makes routine work auditable without making it cumbersome.

Boring deployments are not accidental. They come from giving each layer a clear responsibility and making the boundaries visible when something goes wrong.


Current as of September 2026. All names, identifiers, hosts, and environment values in this discussion are placeholders.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *