Since the last lesson, every commit to main goes to dev on its own. For prod that is not enough. There, a person should see beforehand what changes, and agree. And if something goes wrong anyway, the way back should take seconds, not a new build. In this lesson the Kladde gets both: a prod stage that waits for an approval, and rolling back to a previous revision.

Stages

A stage is an environment that a version passes through on its way into operation. Since lesson 3.2.6 the Kladde has dev and test; now prod joins them.

Stage What for When rolled out Who
dev see whether it runs in Azure at all on every commit to main the pipeline, without approval
test automatic checks against real services, such as the load test after dev, without approval the pipeline
prod operation after an approval the pipeline, once a person has agreed

This lesson builds the way from dev to prod. A test stage looks like dev; the Kladde puts it in between in the final project (lesson 3.10.3), when there is something to check there: the load test from 3.10.7 runs against test. The integration tests from module 3.8 need no stage, they start their dependencies themselves in the build.

Three rules apply to all stages:

  • Every stage has its own identity, with a federated credential only for its GitHub environment and, ideally, with permissions only on its resource group. Then the identity of dev cannot reach prod.
  • Every stage gets the same image. It is built once, in dev. Exactly that image goes to prod, not a newly built one.
  • Every stage ends with the probe at /health. The pipeline is green only when the environment reports the expected version.

A prod environment costs money as long as it runs. For the exercises, you tear it down again at the end of the lesson (azd down --purge -e prod); the next run of the pipeline builds it again. What such an environment costs, you see beforehand in the pricing calculator.