Microsoft Azure

CI/CD — Azure Pipelines & GitHub Actions

Release to Azure from Azure Pipelines or GitHub Actions without stored secrets, through environments with approvals, using slot swaps for instant rollback.

Azure has two first-party CI/CD systems, and an interviewer will want to know you can choose between them and release safely with either.

An understudy waiting in the wings, fully costumed and warmed up. The swap is a walk-on, not a costume change, and if the new performer stumbles, the lead simply walks back on.

Key Concepts

1
    build -> test -> deploy to staging slot -> approval -> swap into production
                                                  |
                                          environment check
2
Azure Pipelines and GitHub Actions overlap heavily. Pipelines has deeper Azure DevOps integration — boards, test plans, deployment groups for on-premises machines. Actions has the larger marketplace and lives beside the code. Both are YAML, and Microsoft's newer investment leans towards Actions.
3
Environments carry the approval gate. In both systems a deployment job targets a named environment, and the environment holds the rules — required reviewers, business-hours checks, a wait timer. The control auditors ask for then lives in the platform, not in someone's memory.
4
Deployment slots are Azure's best release feature.
    deploy to the "staging" slot    its own hostname, warmed up
    smoke-test it there
    swap staging <-> production     a routing change, no cold start
    a bad release? swap back
5
Rollback is seconds rather than another deployment. Configure warm-up so the swap never serves cold requests, and mark settings that must not travel with the code — connection strings, feature flags — as slot settings.
6
Slots share the App Service plan. A load test against staging competes with production for the same CPU, so heavy testing belongs elsewhere.
7
Two versions are live around every swap or canary, so a schema change has to work for both: add first, migrate, and remove the old column only in a later release.
8
No secrets in CI. Use workload identity federation: the pipeline presents a short-lived OIDC token to Microsoft Entra ID and receives an Azure token in return, so there is no service principal secret to leak or rotate.
9
What the interviewer is probing.1. "What makes a slot swap a better release mechanism than redeploying?" Probing: the swap. Stalls: "Staging is a copy of production." Moves up: the swap is a routing change between warmed-up slots, so rollback is swapping back in seconds — provided warm-up and slot-specific settings are configured.
10
2. "How do you deploy to Azure from GitHub Actions without storing a secret?" Probing: federation. Stalls: "Put the service principal secret in GitHub secrets." Moves up: a federated credential on the Entra app registration trusts GitHub's OIDC tokens for that repository and environment, so the workflow signs in with no stored secret.
11
3. "Why can a heavy test of the staging slot hurt production?" Probing: the shared plan. Stalls: "It cannot, they are separate." Moves up: slots run on the same App Service plan, so they share CPU and memory with production.
12
4. "Azure Pipelines or GitHub Actions for a new team?" Probing: reasoning over preference. Stalls: "Whichever the team knows." Moves up: Actions if the code is on GitHub and the needs are standard; Pipelines when the organisation already runs Azure DevOps, or needs deployment groups for on-premises servers.