Flows / How a change reaches production

How a change reaches production

When you merge your work, we build it and store it away. Getting that build running somewhere is a separate job that somebody has to start, and for production somebody else has to agree to it.

Written for everyone. You do not need to know git to follow it.

The build happens on its own You do not need to do anything here, and when it finishes nothing has been deployed. Someone starts the deploy Every step here is a person deciding to do it. Nothing deploys yet if it passes on merge for production approved Merge to mainyour pull request is mergedBuild and quality checksruns by itselfImage in the registrysaved with its build numberChange the image tagone pull request, tag onlyArgo CD syncskeeps the cluster matching gitdevwhere work gets tried outstagingthe last stop before productionDevops approvalonly needed for productionproductionwhat customers are using
  • Something happens
  • A thing that was built
  • A place it runs
  • Someone must approve
People often expect these two halves to be joined up, and they are not. We keep building and deploying separate on purpose. When a build finishes, all it means is that a new version is ready and waiting. Somebody still has to ask for it to go somewhere.

Step 1 of 9

Something happens

Merge to main

What happens

Once a reviewer approves your pull request and it goes into the main branch, everything below starts by itself. Before that, nothing has been built and nothing has moved anywhere.

Who does this

You, after a reviewer approves your work.