[premun]

Summary

• Replace the approval-only deployment job and separate migration/deploy stages with one environment-gated Release stage.
• Run database migrations before the DeployPCS runOnce deployment job, retaining the existing Production/Staging environment selection and approval protection for both jobs.
• Classify DeployPCS as a 1ES releaseJob, with isProduction true only on refs/heads/production.
• Run deployment without a repository checkout: package global.json and the GitHub App token helper in the CLI artifact, and declare same-run PCS CLI and production-only AssetManifests artifacts through templateContext.inputs.
• Document the 1ES requirement that the Azure DevOps environments use resource type None (no attached resources).
• Preserve the deployment CLI, service connections, image-tag output, production-only release actions, and E2E jobs; update the E2E stage dependency and deployment documentation.

No changes to Azure DevOps environment approval settings or exclusive locking are included.

Azure DevOps/1ES server-side template validation and a staging deployment remain to be performed; authenticated Azure DevOps access was unavailable locally. Confirm that both the Production and Staging environments use resource type None before running the deployment.

[Copilot]

🔵 Needs a closer look

Azure DevOps/1ES server-side validation and a staging deployment remain pending for this production release pipeline change.

No open issues 🎉

What changed in this PR

Consolidates PCS releases into one environment-gated stage while preserving the existing deployment workflow.

Changes:

• Runs database migrations before the DeployPCS deployment job in a single Release stage.
• Adds explicit checkout and selective artifact downloads; updates the E2E dependency.
• Documents environment approvals and the existing CLI-based rollout.

File	Description
eng/​pipelines/​templates/​stages/​deploy.yaml	Consolidates release jobs and updates E2E sequencing.
docs/​DevGuide.md	Explains release gating and corrects the deployment CLI link.

_{Review effort: Balanced}

[premun]

Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=3111923&view=results

[dkurepa]

We intentionally separated DB migration and Deployment into different sequential stages so we can just run deployment in case of a Maestro outage where we need to redeploy some version. Is there a way to separate them while keeping the deployment job?