Summary
One release must reach an environment the Opus team operates on AWS and one a customer’s platform team operates on Azure, where change management requires their own engineer to review and promote anything reaching production and nobody else to touch the cluster. Both expectations are legitimate; the engineering question is how to serve them from one process so the environments do not drift into two products.
The first separation is between platform changes (node pools, database versions, network rules, cluster tooling — rare, high blast radius, owned by platform engineers) and workload changes (Opus services — frequent, owned by the product release process), each getting its own repository, owners and approval. The pattern is GitOps: desired state is declared in a source-controlled repository, a controller continuously reconciles the live environment against it, routine changes are reviewed commits, and emergency access outside that path is an exception that must be justified and recorded. FluxCD reconciles, Crossplane declares cloud resources so infrastructure and workloads share a declaration style across AWS and Azure.
In the managed path, Opus engineers commit and FluxCD deploys into the customer’s cluster from a central operations layer; in the customer-operated path, each release ships as a package their engineer reviews, commits to their own repository and promotes with their own tooling, with central visibility only where they permit it — the same release, differing in who commits, approves and reconciles.
The article then closes the series by tracing four improvements to the invoice workflow through four different mechanisms: a promoted learning needs no platform release, an approved route refresh needs none either, a new extractor version is a component release but not an environment release, and only serving a fine-tuned model inside the trust boundary requires a platform change — new GPU capacity declared in the infrastructure repository — with the observation that knowing which kind of change you are making is most of the discipline.
A final caution notes that reverting a commit only requests a previous declared state; failed transitions, data restoration and reversed migrations remain separate planned operations. The series ends where it began: none of the parts is unique alone, and the value and the obligations both sit in the interfaces, where each subsystem hands the next a schema, a permission, a scope or a version it must honour.