Microsoft Azure services
20 / 24
Microsoft Azure

CI/CD — Azure Pipelines & GitHub Actions

Build, test and release automatically, with a deployment strategy that can be rolled back.

A pipeline takes a commit and moves it to production through stages that can stop it.

A conveyor with inspection points, and a second kitchen plated and ready — if the new dish is wrong, you serve the old one again immediately rather than cooking it afresh.

Key Concepts

1
    build -> test -> deploy dev -> approval -> deploy prod
                                     |
                              environment gate
2
Azure Pipelines and GitHub Actions overlap heavily. Pipelines has deeper Azure integration, environments with approvals, and deployment groups; Actions has the larger ecosystem and lives beside the code. Both are YAML.
3
Environments give you the approval gate.
    environment: production
      approvals: 2 reviewers
      checks: business hours only, no open incidents
4
That is the control auditors ask for, and it belongs in the platform rather than in a person's head.
5
Deployment slots are Azure's best release feature.
    deploy to the "staging" slot   (its own URL, warmed up)
    smoke test it
    swap staging <-> production    (instant, no cold start)
    a bad release? swap back.
6
The swap is a routing change, so rollback is seconds rather than another deploy. Enable warm-up so the swap does not serve cold requests.
7
The strategies, and what each costs.
    rolling   replace instances in batches. Two versions run at once.
    blue/green  via slots. Instant rollback, brief double capacity.
    canary    shift a small percentage, watch, then continue.
8
Database migrations break the neat picture, and saying so is what separates a good answer. Rolling and canary run two versions simultaneously, so migrations must be backward compatible: add a column, deploy, backfill, remove the old one in a later release. Never rename in one step.
9
Use OIDC federation, not a service principal secret. The pipeline exchanges a short-lived token with Entra ID, so there is no credential stored in the CI system at all.
10
Build once, promote the artifact. Rebuilding per environment means the thing you tested is not the thing you shipped.
11
What the interviewer is probing.1. "What makes deployment slots a strong release mechanism?" Probing: the swap. Stalls: "They are a staging site." Moves up: the swap is a routing change, so rollback is seconds rather than another deployment — with warm-up so the swap does not serve cold requests.
12
2. "Your canary runs two versions at once. What constrains the database?" Probing: backward compatibility. Stalls: "Nothing." Moves up: migrations must work with both versions — add, deploy, backfill, then remove in a later release. Never rename in one step.
13
3. "How do you avoid storing a service principal secret in CI?" Probing: federation. Stalls: "Rotate it often." Moves up: OIDC workload identity federation — the pipeline exchanges a short-lived token, so no credential is stored.
14
4. "Why can a heavy staging test affect production?" Probing: the shared plan. Stalls: "It cannot, they are separate." Moves up: slots share the App Service plan, so they share compute.
Use cases:azure-pipelinesgithub-actionsdeployment-slotsapprovalsoidc