Skip to content

8. Tagging & Deployment
What Tagging the QA-approved release as an immutable snapshot and deploying it to production.
Owner Engineering (tags), DevOps (deploys), with Support and Management coordination.
Triggers When QA gives the go-ahead on a clean build.

Summary

Once QA gives the go-ahead, the release branch is tagged. The tag is the immutable, permanent record of exactly what ships, and it is created at approval, never before. Production deployment follows only after explicit confirmation and coordination with Support and Management, because a deploy affects live clients and Support needs to be ready. This phase is the controlled boundary between "tested" and "live."

Full detail

Tag first

On QA's go-ahead, tag the release branch with the production version:

git tag v1.4.0
git push origin v1.4.0

The tag freezes exactly what was tested and approved. Because the JIRA Release version, the release branch name, and the app version all match, the tag is fully traceable: anyone can go from a running production version back to the tag, the branch, the JIRA Release, and every ticket in it.

The tag is not a test artifact

The tag is created after approval, purely to freeze production code. It is distinct from the earlier release-branch freeze, which was a working state for QA. Do not tag before QA approval.

Coordinate before deploying

Production deployment proceeds only after:

  • Confirmation that the release is approved to ship.
  • Coordination with Support: Support must know a deploy is coming, what is changing, and when, so they can field client questions and watch for issues.
  • Coordination with Management: sign-off that timing and client impact are acceptable.

For products deployed to multiple clients on dedicated deployments, coordination includes the rollout order and timing across those clients.

Deploy

DevOps deploys the tagged build to production. The deployment target and method follow the dedicated-deployment model in use for the product. After deployment, the team immediately moves into Post-Production Monitoring and the release is closed out (see Release Close-out).

flowchart TD
    A[QA go-ahead on clean build] --> B[Tag release branch with production version]
    B --> C[Push tag]
    C --> D{Confirmed to ship?}
    D -->|no| E[Hold]
    D -->|yes| F[Coordinate with Support]
    F --> G[Coordinate with Management]
    G --> H[DevOps deploys tagged build to production]
    H --> I[Begin Post-Production Monitoring]
    H --> J[Release Close-out]

Example

QA approves v1.4.0. The lead tags release/v1.4.0 as v1.4.0 and pushes the tag. The PM confirms with Management that the Thursday afternoon window is fine, and tells Support what is changing (CSV export, a payments retry fix) so they can answer client questions. DevOps deploys the tagged build to the client's dedicated production environment. The team starts watching New Relic and Crashlytics, and begins close-out.