From Azure Pipelines to Argo CD

An artifact and a deployment answer different questions

An application pipeline establishes whether a source revision can produce a validated artifact. Deployment configuration describes what an environment should run. Culina and Elysion keep those responsibilities in separate repositories.

Application code is built through Azure DevOps Pipelines and packaged as Docker images. Infrastructure configuration uses Helm and Argo CD to describe and reconcile Kubernetes deployments. The repository boundary makes deployment intent independently reviewable without separating it from the application it operates.

Keep the handoff visible

The delivery model can be summarized as:

Application revision
    → validation and build
    → Docker image
    → image reference in deployment configuration
    → Helm manifests
    → Argo CD reconciliation

The important handoff is the image reference. A successful build does not, by itself, say which environment should run that artifact. The desired configuration must identify it. This sketch describes the separation of responsibilities; it does not imply that a pipeline automatically promotes every image or opens a configuration change.

Elysion’s CI covers formatting, linting, tests, builds and image publication. Its frontend workspace also supports checks for affected Nx projects. Culina combines pipeline automation with environment configuration, health checks and telemetry.

Environments carry different release decisions

Culina defines development, testing, staging and production environments. Non-production supports automatic synchronization; production uses manual synchronization. That is a concrete point at which a validated artifact and a release decision remain distinct.

Elysion’s infrastructure describes development, staging and production deployments. Those environments share the GitOps model, but that alone does not establish the same promotion or approval policy as Culina. Similar tools should not be mistaken for identical release processes.

Recovery includes the application state

Version-controlled configuration provides a record of deployment intent. Returning to an earlier image reference is only one part of recovery: database changes and external state can affect whether the earlier application remains compatible. A Git revert is therefore not a complete rollback strategy by itself.

The practical design principle is to keep build evidence, desired configuration and runtime health connected. Pipelines establish what was built; deployment configuration establishes what should run; health checks and telemetry help determine what is happening after it starts.