I'm building a CI/CD process for AKS with native Azure DevOps Pipelines and KubernetesManifest@1, rather than a GitOps controller. The basic Microsoft example combines build and deployment in one YAML pipeline, but I'm unsure how that should evolve for QA, UAT, and production with a manual approval before production.
Would you use one deployment pipeline with sequential environment stages and approval gates, or separate nonproduction and production pipelines? How should the same container be promoted between environments—by importing its digest into a separate production registry, or by using one ACR with repository-level RBAC? If CI can only push to a nonproduction registry, what should trigger deployment: a pipeline-completion resource, a published artifact containing the image digest, or a manually supplied tag? I'm also interested in practical reasons teams have stayed with native Azure Pipelines or moved to GitOps, without treating GitOps as the only acceptable answer.
5 Answers
A strong baseline is to separate build from deployment. The build pipeline creates and tests one immutable image, then publishes the exact image digest as an artifact. Deployment pipelines consume that digest and only handle environment configuration and rollout. This keeps CI from holding production credentials and makes it clear that the identical build is moving through QA, UAT, and production.
For the registry, a single ACR can be sufficient if compliance does not require physical isolation. Push the image once, refer to its immutable digest, and use repository-level permissions or separate paths for nonproduction and production access. A separate production registry can be justified for network, identity, or regulatory isolation, but copying images between registries adds another dependency and should still preserve the original digest.
There are two reasonable pipeline layouts. A single YAML with templated deployment stages is easy to audit and works well when every environment must progress in order. Separate nonproduction and production pipelines are safer when you want independent operation and a hard credential boundary. In that model, share the deployment template, but use separate service connections scoped to each environment. Production should have its own approval gate and credentials that the nonproduction pipeline cannot access.
Separate pipelines also avoid having QA wait behind an unrelated production approval. The shared template keeps the duplication manageable.
The main reason teams move from push-based deployment to a GitOps controller is drift detection. A manual cluster change can otherwise exist without the deployment pipeline knowing about it. Native pipelines are still workable when approvals, service connections, manifests, and deployment history are tightly controlled; the important parts are immutable artifacts, least-privilege credentials, and a deterministic promotion path.
For triggering CD, publish a small pipeline artifact containing the image digest and release metadata, then have the deployment process consume that artifact. A pipeline-completion trigger can work, but explicitly passing the digest is easier to audit than relying on a mutable tag. A manual run with a digest parameter is a useful fallback for controlled promotions or recovery.
That build-once, deploy-many boundary is exactly what I'm trying to preserve. I especially like keeping the production credentials completely outside CI.