In module 3.7 you built the parts of a pipeline one by one: CI on every pull request, versions from the Git tag, versioned
images, the sign-in without a secret, approvals before prod. They ran against a subscription that you had set up piece by piece,
and against identities that azd pipeline config had created for you. In this lesson you put the parts together into a delivery
that runs against the empty subscription from 3.10.2. In the end a pull request goes through review and CI, is merged, and
lands without any further step in dev and test, and after an approval in prod.
The path of a change
Pull request ──► ci.yml (3.7.1): build, test, format, NuGet audit no access to Azure
│ review, merge
▼
main ──► deliver.yml
build test, version from the tag, build and push images id-kladde-build
│
dev platform, migration, apps, smoke test id-kladde-deploy-dev
│
test the same id-kladde-deploy-test
│
preview-prod what-if for prod, read-only id-kladde-preview
│
prod waits for the approval, then like dev id-kladde-deploy-prod
Four rules are built into this picture:
- Build once. Only the job
buildbuilds images.dev,testandprodget the same image with the same version. What was tested intestis, byte for byte, what goes toprod. - Every job has its own identity with exactly the permissions it needs (3.10.2). CI in the pull request can't get at Azure at all.
- The order is fixed. If
devfails,testdoesn't run, andprodcertainly doesn't. - The approval sees what it approves. What-if for
prodruns before the approval, and its result is in the run when the person clicks "Approve".
The workflow azure-dev.yml, which azd pipeline config created in 3.7.5, is replaced by deliver.yml. Delete it in the same
pull request, or two deliveries will run side by side. ci.yml from 3.7.1 stays as it is.