chapter two

2 Deployment is not promotion

 

This chapter covers

  • Distinguishing deployment from promotion in one shared transition
  • Identifying the questions deployment can’t answer
  • Understanding why Kubernetes widens the promotion gap
  • Recognizing the Git-branch and CI-pipeline illusions
  • Handling multi-service and compliance pressures
  • Making the case for explicit promotion control

In chapter 1, Maya Chen’s Friday-afternoon hotfix at Lumen Retail closed an incident in minutes, then cost three engineers three days of forensic work when a SOC 2 auditor asked for the approval record. Her tooling let her deploy. It had no concept of promotion. That gap, between deploying software and governing how it moves, is what we make precise here.

Most practitioners use "deployment" and "promotion" as synonyms. They aren’t. Deployment is the act of bringing one environment into its desired state. Promotion is the governed movement of an artifact between environments, with a recorded identity, a recorded approval, and a recorded outcome. You can have a great deployment system, Argo CD, Flux, or anything else that reconciles cluster state, and still have no answer when someone asks, "Which artifact, advanced from where, by whom, on what evidence?"

Getting there means seeing the two side by side, understanding why Kubernetes turns a manageable problem into an unavoidable one, and recognizing the workarounds that look like promotion but aren’t.

2.1 The same transition through two systems

The same transition, with a promotion control plane

2.2 What deployment solves, what promotion asks

2.3 Why Kubernetes makes the gap unavoidable

2.4 The patterns that look like promotion but aren’t

2.4.1 The Git branch illusion

2.4.2 The CI pipeline anti-pattern

2.5 The forcing functions: many services and compliance

2.5.1 The multi-service multiplier

2.5.2 The compliance forcing function

2.6 Making promotion explicit

2.7 Summary