Azure DevOps Pipelines

The transcript service is designed and coded; Module 12 gets it into production and keeps it healthy. In a Commission shop, the delivery platform is Azure DevOps, and the difference between a hobby deploy and a public-sector deploy is mostly discipline you configure once.

Repos and branch policy

One Git repository in Azure Repos, with main as the protected trunk. Configure branch policies on main so the rules are enforced by the server, not by memory:

• Minimum reviewers (usually two for this domain) with "reset votes on new pushes."
• Linked work items required — every change traces to a Board item; auditors love this and so will you, six months later.
• Build validation — the PR cannot complete unless the validation build passes.
• No direct pushes to main, ever, including admins.

Short-lived feature branches (feature/1234-analyst-queue-filter) merge via pull request. Long-lived branches rot; the branch policy makes small, frequent PRs the path of least resistance.

PR validation builds

The validation build is your quality gate and should finish in minutes: restore, compile, run unit tests (the service-layer tests your thin controllers made possible), and fail on warnings you've promoted to errors. For this codebase add two domain-specific checks: the EF model/migration consistency check (a migration was added if the model changed) and any static analysis your agency mandates. What validation builds don't do is deploy — they exist to keep main releasable.

YAML pipelines

Define the pipeline as code in azure-pipelines.yml, versioned with the app — click-configured "classic" pipelines drift and can't be code-reviewed. The shape is a multi-stage pipeline:

stages:
  - stage: Build      # compile, test, publish artifacts
  - stage: DeployDev  # automatic
  - stage: DeployTest # automatic, smoke tests
  - stage: DeployProd # gated by approvals

The Build stage produces immutable artifacts — the web app package plus the EF migration bundle/script (next lesson) — and every later stage deploys that same artifact. Never rebuild per environment; the binary you tested is the binary you ship.

Environments and approvals

Model dev / test / prod as Azure DevOps Environments, each mapped to its own app instance and SQL Server database. Environments give you two things pipelines alone don't: a deployment history per environment ("what's on test right now?") and approvals and checks — prod requires a named approver (your lead or the Commission's release manager) to click approve, and that click is recorded. For a system holding candidate PII, that recorded human approval isn't ceremony; it's the deployment-time echo of the same principle the app itself is built on: automated pipeline, human determination.

With the skeleton in place, the next lesson fills in the risky parts: database migrations and per-environment configuration.