Production Release Checklist

The production release is a manual workflow, coordinated through a Linear card created from the New Release Template. The card carries a checklist that drives the human-in-the-loop steps; this document is the engineer-facing reference for what each checklist item actually does and what to watch for while doing it.

This workflow only begins after a fully green SIT run on the latest staging deployment — see 02-sit-tests.md.

Status: the steps below cover the release through the manual Azure ADO Release to AKS production. Further post-release steps (smoke checks, communications, follow-ups) are not yet documented; see the TODO at the end of this page.

Step 1 — Open the release card

Create a new Linear card from the New Release Template. The template populates the checklist described below; the card serves as the single point of coordination and audit trail for the release.

Make sure the card is assigned to whoever is driving the release and that the relevant Linear project / cycle is set, so that the release shows up where stakeholders are looking.

Step 2 — Raise and merge PRs across the release repos

Eight repositories are released in lock-step. For each, raise a PR merging dev into master, get the required review, and merge.

Repository	What it contains
meltano-catalog	Backend, shelltask, frontend — the primary source. Its merge is what triggers the Azure ADO build (see Step 3).
meltano-www	Marketing / public website.
meltano-build	Deployment scripts and Helm charts used by both staging and production.
meltano-config	Environment-specific configuration — including production values.
meltano-sit	System integration test suite. Merged so that any SIT updates ship with the release they were written for.
meltano-docs	Documentation site.
meltano-cli	Command-line tool.
meltano-ce	Community edition.

Order matters in one respect: the merge into meltano-catalog is the event that kicks off the Azure ADO build (Step 3). If meltano-build or meltano-config changes are needed for the production deploy in Step 4, those merges should land before the Azure ADO Release is manually triggered — but they do not need to land before the meltano-catalog merge. The other repos (meltano-www, meltano-docs, meltano-cli, meltano-ce, meltano-sit) can be merged in any order relative to the build, as they are not consumed by it; the principle is that they ship together so the release is self-consistent.

Each PR should reference the Linear release card in its description so that the release-time view of “what’s in this release” can be reconstructed later.

Step 3 — Azure ADO build

The merge into master on meltano-catalog is picked up by an Azure DevOps pipeline. This is the equivalent of the AWS meltano-catalog-build pipeline, but produces production-grade images:

The pipeline runs the same Java and frontend unit tests as the AWS build pipeline. It builds the catalog and shelltask container images from the master commit. It tags each image with the Azure build number (immutable — every build produces a new tag, and the tag is never overwritten). It pushes both images to Azure Container Registry (ACR).

The Azure build does not push to ECR or Artifact Registry — those registries hold only latest-dev builds from the AWS pipeline. The production deployment pulls from ACR.

Recording the Azure build number on the Linear card is important: it is the unambiguous reference to which image is being released, and becomes the input to Step 4.

Step 4 — Azure ADO Release to AKS production

Once the Azure ADO build is green, a Release is triggered manually in Azure DevOps. This is the manual gate that separates “we have production images built” from “we are deploying to production”.

The release deploys to the production Azure AKS cluster. It follows the same general process the AWS staging pipeline uses — clone meltano-build and meltano-config at deploy time, run Helm against the cluster — with two key differences:

The image tag deployed is the Azure build number from Step 3, not latest-dev. This means the release is reproducible: re-running the same Azure Release with the same build-number tag deploys exactly the same image content.

The values overlay used is the production overlay in meltano-config, which carries production-specific hostnames, replica counts, resource limits, secret references, and any feature flag overrides.

The manual trigger is intentional. SIT being green on staging is not on its own sufficient justification to push to production — the human running the release is expected to confirm the change is intended, that no other ongoing work conflicts, and that any time-of-day or freeze-window constraints are respected before clicking through.

Step 5 onward — TODO

The remaining steps that follow a successful AKS deployment are not yet documented here. Likely candidates include:

• Post-deploy smoke checks against production.
• Verification of the production image’s build-number tag against the Linear card.
• Communications (release notes, internal announcement, customer-facing changelog updates via meltano-docs).
• Closing out the Linear card and any follow-up tickets.
• Rollback procedure if smoke checks fail.

These will be filled in in a follow-up pass. The intent of this document is that the checklist above mirrors the Linear template, so a release can be driven through to AKS deployment using it today.