Delivery and promotion

A Solution deploys a matrix: your services on one axis, your environments on the other. Each cell of that matrix is deployed independently, and each one decides for itself how a new version reaches it.

Two mechanisms drive that, and they are worth separating:

• Image updates decide which image version becomes a candidate for an environment. They write to the GitOps repository.
• Synchronization decides when the repository is applied to the cluster.

A deployment happens when both have run: a new tag is committed, then the environment syncs.

Automatic image updates

When enabled on a cell, the platform watches your registry and commits the new image version into the environment overlay of the GitOps repository. The commit is the trace: who deployed what, and when.

Which tags are eligible is filtered per environment. The usual setup:

Environment	Tag filter	Effect
Development	any tag	every push to the registry becomes a candidate
Staging	pre-release versions	build-dated versions become candidates
Production	release versions only	only a tagged release becomes a candidate

With that filter in place, production is already protected upstream: an ordinary push cannot become a production candidate, only a release tag can.

A manual gate before production

Automatic synchronization is a per-environment setting, and it can also be overridden on a single cell of the matrix. Turn it off on production and nothing reaches the cluster on its own.

The cell then reports that it is out of sync as soon as the repository moves, and waits. Deploying becomes an explicit action: open the cell, review what changed, and trigger the synchronization. This is the equivalent of an approval step before production, with the difference that what you approve is the exact set of resources about to be applied, not a pipeline stage.

Two related settings sit next to it:

• Self-heal brings the cluster back to the repository state when someone changes a resource by hand. Recommended on production.
• Prune deletes resources removed from the repository. Without it, a deleted manifest leaves its object behind in the cluster.

Note

Turning automatic synchronization off on production does not freeze it. Image updates keep committing candidates to the repository, they simply wait there until you synchronize.

Promoting a validated version

Once a version has been validated on one environment, promoting it to the next one means copying its image tag into the target overlay. The GitOps repository ships a script for exactly that:

./scripts/promote.sh {solution} {service} {from-environment} {to-environment}

It reads the tag currently deployed on the source environment, writes it into the target overlay, and leaves you with a diff to review and commit. The promotion is therefore a commit like any other: dated, attributed, revertable.

Rolling back

Because the repository holds the deployed state, a rollback is a Git operation:

# revert the commit that introduced the version
git revert {commit} && git push

The environment picks up the previous version on its next synchronization, or immediately if automatic synchronization is on. Reverting a promotion commit rolls back one environment; the others are untouched.