Skip to content

Delivery pipeline

A change reaches an environment through four stages. Every workflow's name: starts with its stage. These are the following: 1 Check, 2 Build, 3 Deploy, 4 Release. A workflow outside the pipeline starts with Ops. What each workflow does: CI workflows.

flowchart TD
    pr[Pull request] --> check[1 Check]
    check -->|merge| main[main]
    main --> check
    main --> deploy[3 Deploy staging]
    main --> build[2 Build]
    branch[Any branch] -->|dispatch| build
    build --> registry[(platform-staging registry)]
    registry --> pin[Pin in staging.env]
    pin -->|pull request| pr
    main -.->|release tag| release[4 Release production]

    classDef broken stroke-dasharray: 5 5
    class release broken

A dashed arrow is a path that does not deploy today.

Stages

Each stage links to its workflows in CI workflows.

  1. Check: the sweep lints and tests every project on every pull request and push to main.
  2. Build: every push to main builds every service image into the platform-staging registry, tagged with its commit. A dispatch builds from any branch.
  3. Pin: a pull request repins staging.env to one commit's images. See below.
  4. Deploy: every push to main applies the staging service units.
  5. Release: production. It is broken, and production is deployed by hand.

Pin

  • infra/terraform/envs/staging.env pins each staging image by digest.
  • //infra/docker:pin-staging-images <commit> rewrites those pins to the images of one commit.
  • The pin is a pull request like any other. See trying a branch on staging.

If a change edits a service's Terraform config and its code, then it MUST be merged with a repin. Otherwise staging applies the new config to the old image.

Known gaps