What artifact promotion between environments is and why it matters
Artifact promotion between environments is the process that governs how a validated build moves from the development environment to production, passing through intermediate stages such as staging. An artifact is a compiled, packaged version of the code, containerized or in the form of a machine image, ready to be deployed. Without a structured promotion strategy, it is easy for a build containing a critical bug to reach production, or conversely for a legitimate build to be blocked for no clear reason.
For a scale-up or a mid-market company on AWS, this challenge intensifies as soon as the team grows and the number of daily deployments increases. A developer in France, another in Barcelona, an automated testing team, and an infrastructure spread across several AWS regions: without explicit promotion rules, the risk of collisions, accidental deployments, or lost traceability quickly becomes unmanageable. Structured promotion lets every participant know which artifact is authorized to go where, according to which criteria, and who approved each transition.
This progressive validation delivers several concrete benefits. First, it reduces the risk of a production incident by ensuring that every artifact has first proven its reliability in staging. Second, it creates a clear audit trail: if a problem occurs in production, you know exactly which build was responsible, who promoted it, and which tests it passed. Finally, it frees teams from the constant stress of "can we really deploy this now?", offering an objective answer based on predefined criteria.
Validation criteria before promotion
Before promoting an artifact from one environment to another, you must define the validation criteria it has to pass. These criteria vary with the organization's maturity and the risks of the business domain, but several elements are universal.
Test coverage is the first criterion. An artifact should have successfully passed a suite of unit tests (tests of business code in isolation), integration tests (tests of interactions between modules or services), and, ideally, contract tests (verifying that APIs and interfaces remain compatible). A minimum code coverage threshold (for example, 70-80 % for a new feature, 90 % for critical code) can be enforced. Some organizations use tools such as SonarQube or Codecov to measure this coverage automatically and refuse promotion if the threshold is not met.
Code quality is a second pillar, often measured through static analysis. Tools such as SonarQube, Checkmarx, or WhiteSource scan the compiled code or bytecode to detect known security flaws, anti-patterns, or open source vulnerabilities. An artifact should reach staging only if it contains no critical or high vulnerability, or if those vulnerabilities have been explicitly accepted by a security owner.
Validating the containerized image (if your artifact is a Docker image) is also important. This includes scanning the image to identify CVEs (Common Vulnerabilities and Exposures) in the system packages, verifying that the image does not export secrets or sensitive data, and checking compliance with organizational standards (image size, approved base layers, and so on). AWS ECR (Elastic Container Registry) offers this scanning capability natively and can block promotion if vulnerabilities are detected.
Signing and authenticity are a third aspect. An artifact should be digitally signed by the build system, so as to prove that it genuinely comes from the official pipeline and has not been altered along the way. This prevents substitution attacks or the accidental deployment of the wrong version.
Finally, business or regulatory compliance may require additional validations. For example, if your application must comply with GDPR or PCI-DSS, a check that the logs do not expose personal data or that in-transit encryption is correctly configured may be required before promotion.
Progressive promotion mechanisms: dev, staging, production
Progressive promotion typically flows through three or four environments, each serving a distinct purpose and providing an additional safety net.
The development environment (dev) is the team's playground. Developers push code there constantly, unit and integration tests run automatically, and builds are ephemeral: a dev broken in the morning is often fixed by noon, with no real consequence. Validation in dev is light; the goal is speed and a short feedback loop. An artifact produced in dev is not meant to leave the development environment unless it clears a first minimal quality bar (tests passing, no compilation errors, acceptable baseline coverage).
The move from dev to staging is a first serious promotion. At this stage, the artifact must be tagged (for example, v1.2.3-staging-20240115), all automated tests must pass, the security analysis must be complete and free of critical findings, and there must be an explicit build record (commit hash, author, commit message). In staging, the team can deploy the artifact onto infrastructure that resembles production as closely as possible, including a test data volume close to the real thing, real external services (or mocks), and exposure to loads close to reality. An artifact's lifetime in staging can be a week or more, allowing deeper testing, manual business validations, and performance trials.
The move from staging to production is the critical moment. At this step, you may require an explicit manual approval from an owner (Tech Lead, SRE, or Release Manager), verification that the artifact passed all tests in staging, verification that all dependencies (databases, external services, configurations) are in place on the production infrastructure, and possibly an automated "smoke test" that runs immediately after deployment to confirm that critical services are functional.
Some organizations add an intermediate step: "pre-production" or a "canary stage", a small subset of production where only a minimal percentage of real traffic is routed. The artifact runs there for a few hours or days, while metrics (latency, error rate, CPU, memory) are observed and no abnormal incident is expected before extending it to the rest of production.
In AWS practice, these environments correspond to separate AWS accounts (or at least isolated VPC resources within the same account), with CloudFormation or Terraform pipelines that deploy the artifact progressively. Tools such as CodePipeline orchestrate the stages and the manual approvals; tools such as CodeDeploy or AWS AppConfig handle the deployment itself with rolling update or canary strategies.
Automating promotion: pipelines and gates
Promoting by hand is slow, repetitive, and error-prone. Modern organizations automate this process by defining promotion pipelines: codified workflows that test, validate, and push the artifact from one environment to another according to predefined rules.
AWS CodePipeline is the native pipeline orchestration service. In it, you define stages (build, test, approval, deployment) and actions within each stage. For example: stage 1 builds the artifact (CodeBuild action), stage 2 runs the security tests (custom Lambda action or a call to Snyk, Checkmarx, and so on), stage 3 requests a manual approval (Manual Approval action), stage 4 deploys to staging (CodeDeploy or CloudFormation action), stage 5 requests a new approval after staging tests, stage 6 deploys to production (CodeDeploy action with a rolling update or canary strategy).
"Gates" or "quality gates" are the criteria that automatically stop the pipeline. If a stage does not satisfy them, the pipeline halts and sends an alert. For example, if a security scan detects a critical vulnerability, the pipeline stops, refuses to promote the artifact, and notifies the team. Gates can be configured at each stage: test gates (at least 80 % of unit tests must pass), security gates (zero critical vulnerability in the image scan), metric gates (the staging deployment must not increase average latency by more than 10 %).
In practice, you codify these pipelines in a YAML or JSON file (for example, a pipeline.yaml file at the root of the Git repo). This file describes the stages, actions, conditions, and notifications. Tools such as GitOps (ArgoCD, Flux) can even synchronize deployments automatically with this declarative state: if the file in Git says "this artifact v1.2.3 must be in staging", ArgoCD ensures the actual deployment matches, with no manual intervention.
Automated promotion also relies on metadata attached to the artifact. During the build, the pipeline stores the commit hash, the version tag, the source branch, the author, the timestamp, and the results of each validation. This creates a complete pedigree for the artifact: anyone can consult the history and see "this artifact v1.2.3 passed all tests on January 15 at 2:30 pm by Alice, was then manually approved by Bob for staging on January 16, and remained in staging until January 20, at which point it was promoted to production on the Release Manager's approval".
A common pitfall: gates that are too permissive. If the quality gate is easy to bypass (for example, a failing security scan that can be ignored with a simple comment), it loses all value. Effective gates are the ones that genuinely stop the pipeline, forcing the developer to fix the problem or to request an explicit exception from an owner.
Rollback and recovery in case of an anomaly after promotion
Despite all the tests and validations, an artifact can sometimes reveal a bug or a problem in production. It is rare, but it is possible. A complete promotion strategy must therefore include a clear and fast rollback plan.
Immediate rollback is the simplest and often the safest option. It consists of quickly redeploying the previous artifact (the one that was in production before the failed promotion). If the promotion happened less than an hour ago and critical errors surface, reverting to the earlier version is often faster and safer than fixing the bug live in production.
For rollback to be possible, you must retain the history of promoted artifacts: every version that reached production, with its state and configuration, remains accessible for a minimum period (for example, 30 days). In AWS, Docker images are stored in ECR with tags that identify them (v1.2.2, v1.2.3, stable, latest), making it possible to switch quickly to an earlier image. CloudFormation or Terraform configurations are versioned in Git, so a stack can be reverted to an earlier revision within minutes.
Two deployment strategies also reduce risk and make rollback easier. The first is blue-green deployment: you maintain two identical infrastructures in parallel (blue and green), deploy the new version on one (green, for example), test it, then switch traffic all at once (blue to green). If problems arise, you switch back immediately (green to blue). AWS AppConfig and CodeDeploy support this strategy natively.
The second is canary deployment: you roll out the new version progressively, for example 5 % of traffic first, then 20 %, then 50 %, then 100 %, observing error and performance metrics at each step. If an anomaly appears at the 5 % step, you stop and return to 0 % immediately, before 95 % of traffic is affected.
The rollback chain must also include an escalation procedure. If a simple rollback does not solve the problem (for example, the bug already existed in the earlier version), you need an emergency procedure: who to call, how to deploy a patch within minutes, how to communicate to customers, how to minimize damage while you fix it.
An often overlooked aspect: data reconciliation. If the new version changes a database structure and the previous version cannot interpret it, a simple code rollback is not enough. You must also run a reverse database migration, which can be complex or even impossible depending on the type of change. This is why database migrations must be designed upfront to be reversible, or at least not to break backward compatibility.
Tools and best practices for mastering artifact promotion
Several categories of tools support artifact promotion. Some orchestrate the pipelines, others validate quality, and others still maintain history and facilitate auditing.
For orchestration, AWS CodePipeline is the native choice. For organizations using multiple clouds or preferring an open source approach, GitLab CI/CD, Jenkins, or Tekton Pipelines offer more flexibility. GitOps tools such as ArgoCD or Flux declare the desired state in Git and automatically synchronize it with the real state of the infrastructure.
For validation and gates, you often combine several tools: AWS CodeBuild runs the tests and builds, SonarQube or Snyk analyze security and code quality, ECR scan or Trivy scan the Docker images, and load tests (JMeter, Gatling) confirm that performance stays acceptable.
For history and auditing, ECR and Artifactory keep images with their metadata. Git keeps the source code and its changes. CloudTrail records who approved which promotion to production. Continuous monitoring tools (Datadog, Prometheus + Grafana, CloudWatch) collect metrics from each environment, making it possible to detect quickly whether a new version introduces a degradation.
One essential best practice: artifact immutability. Once an artifact has been built with a specific tag (v1.2.3), it must never change. If the source code changes, a new build creates a new tag (v1.2.4). This prevents confusion: if I say "deploy v1.2.3 to prod", everyone knows exactly what will be deployed, with no surprises. Tools such as Docker and npm support immutability: an image tagged v1.2.3 cannot be re-tagged or modified; only a "latest" tag can be re-pointed.
Another best practice: explicit approvals. A promotion must not slip silently from one environment to another; on the contrary, each transition must be explicit, recorded, and approved (automatically by a gate, or manually by a person). If a problem arises later, you know who approved it.
Finally, notification channels. As soon as a pipeline fails, a promotion is blocked, or a rollback is triggered, the relevant people must know immediately. Integrating notification tools (Slack, PagerDuty, email) directly into the pipelines reduces the time to detect an incident and speeds up the response.