The Complete Responsive CMS Blog created by Francesco Malagrino

Eliminating Deployment Anxiety: GitOps and Progressive Delivery for Enterprise Workloads

Category: Cloud Native Architecture & Written by Francesco Malagrino On July-15-2026 14:39:41

---

Introduction

Traditional deployment pipelines often depend on imperative scripts, manual commands and environment-specific procedures. As the number of microservices increases, these practices create configuration drift, inconsistent releases and unnecessary operational risk.

The gitops-progressive-delivery project demonstrates a declarative delivery architecture in which Git stores the desired application state, ArgoCD reconciles Kubernetes environments, and Argo Rollouts controls how new versions are exposed to users.

Instead of deploying a release to every user at once, the platform introduces changes gradually, evaluates live Prometheus metrics and either continues, pauses or rolls back the deployment based on measurable system behaviour.

From Push-Based Deployment to GitOps

Traditional CI/CD pipelines frequently connect directly to Kubernetes and execute imperative deployment commands. This gives the pipeline significant cluster access and can make it difficult to determine whether the running configuration still matches the reviewed source code.

This project separates continuous integration from continuous delivery.

GitHub Actions builds and tests the services, scans the container images with Trivy, publishes them to GitHub Container Registry and updates the image references stored in Git. ArgoCD then detects the Git change and reconciles the target Kubernetes environment.

The CI system therefore produces and records the release, while the GitOps controller applies the declared state from inside the delivery platform.

Declarative Environment Management

The repository defines development, staging and production environments using reusable Helm charts and Kustomize overlays.

Shared resources remain in a common base, while each environment applies its own replica counts, resource settings, image versions and deployment controls.

Staging uses automatic ArgoCD synchronisation, allowing approved Git changes to flow into the environment without an engineer running kubectl apply. Production remains deliberately human-gated: images are pinned to an exact commit SHA, GitHub environment approval is required, and the ArgoCD synchronisation is performed manually during an approved deployment window.

This provides automation where rapid feedback is valuable while retaining operational control for production releases.

Progressive Delivery with Argo Rollouts

A successful GitOps architecture should control not only what is deployed, but also how a new version reaches users.

The project uses Argo Rollouts to implement two progressive-delivery strategies.

Canary Releases

The order-service and saga-orchestrator use canary deployments.

Traffic is progressively shifted through four stages:

• 5%


• 25%


• 50%


• 100%

At each stage, an Argo Rollouts AnalysisRun queries Prometheus before allowing the release to continue.

This limits the impact of a defective version because only a controlled percentage of traffic reaches the new pods during the early rollout stages.

Blue/Green Releases

The payment-service uses a blue/green strategy with manual promotion.

The stable version remains available while the replacement version is deployed separately and validated. A platform engineer then decides when to promote the new version.

This strategy is appropriate for payment processing because it avoids sending financial operations to two application versions simultaneously and provides a clear path back to the previous version.

Metrics-Driven Deployment Decisions

The platform does not assume that a healthy Kubernetes pod means a healthy release.

Argo Rollouts evaluates application-level metrics collected through the observability platform. The analysis checks conditions such as:

• Request success rate of at least 95%


• Failure conditions below the defined success threshold


• p99 latency below 500 milliseconds

When the analysis succeeds, the rollout advances to the next traffic stage. When the configured failure condition is reached, the rollout is aborted and traffic remains on the stable version.

The design also handles observability failures carefully. If Prometheus cannot provide a reliable result, the analysis is marked as inconclusive. After repeated inconclusive results, the rollout pauses for human investigation instead of treating missing telemetry as proof that the release is healthy or unhealthy.

Automated Rollback Without Blind Automation

Automated rollback is valuable, but only when it is driven by meaningful evidence.

For canary releases, failed Prometheus analysis can stop the rollout before the new version receives all production traffic. Engineers can also abort an active rollout manually through the provided promotion script or the Argo Rollouts dashboard.

The objective is not to remove people from every deployment decision. It is to automate predictable safety responses while preserving human control when telemetry is unavailable, results are ambiguous or the release affects a sensitive service.

App of Apps and Platform Separation

ArgoCD uses the App of Apps pattern to organise the platform into independently managed applications.

The structure includes:

• Automatically synchronised staging microservices


• Human-gated production microservices


• The shared observability platform


• ArgoCD projects for access and deployment boundaries


• Notification integrations for Slack and PagerDuty

This avoids managing the entire platform as one large Kubernetes manifest and provides clearer ownership and lifecycle boundaries between environments and platform components.

Validation Before Deployment

The repository includes a validation workflow that checks Kubernetes and delivery resources before changes are merged.

The pipeline validates Helm charts, Kustomize overlays and Prometheus queries. The main CI workflow also runs service smoke tests, builds container images and blocks publication when Trivy detects high or critical vulnerabilities.

These controls move deployment failures and security findings earlier in the lifecycle, where they are cheaper and safer to resolve.

Why It Matters for Enterprise Environments

GitOps creates a reviewable record of the intended deployment state.

Application versions, environment overlays and rollout configurations are represented through commits and pull requests. This improves traceability because teams can identify who proposed a change, what was reviewed and which version was intended for each environment.

It does not mean that Git records every runtime event automatically. Deployment history, rollout analysis and operational alerts must also be retained through ArgoCD, Argo Rollouts, Prometheus, Slack, PagerDuty and the wider observability platform.

Together, these components provide a stronger operational audit trail than unmanaged scripts and direct cluster modifications.

Limitations and Trade-offs

GitOps does not eliminate operational risk.

A faulty configuration committed to Git can still be reconciled consistently across a cluster. Poorly chosen metrics can approve a defective release, while an unavailable GitOps controller or observability platform can delay deployments and recovery operations.

The platform must therefore protect its repositories, controllers, credentials, metrics and approval processes with the same care applied to the applications it deploys.

Production automation must also remain proportional to risk. A low-risk stateless service may support automatic promotion, while financial or stateful workloads may require manual validation and controlled deployment windows.

Conclusion

Progressive delivery replaces the anxiety of an all-at-once release with a controlled, observable process.

Git defines the desired deployment state. GitHub Actions builds, tests, scans and publishes the release. ArgoCD reconciles Kubernetes environments, while Argo Rollouts gradually exposes the new version and uses Prometheus metrics to determine whether the release should advance, pause or roll back.

The result is not deployment without human responsibility. It is a delivery model in which automation handles repeatable controls, metrics provide objective evidence and engineers retain authority over high-risk production decisions.

Explore the Implementation

Review the ArgoCD applications, Argo Rollouts definitions, Prometheus analysis templates, Helm charts, Kustomize environments, GitHub Actions workflows and deployment scripts in the repository: GitOps Progressive Delivery

 

Facebook Whatsapp Twitter Linkein Pinterest Reddit Tumblr Mail

Systems Architecture
Cloud Native Architecture
Site Reliability Engineering (SRE)
typescript
nodejs
Distributed-Systems
Microservices
Software Architecture
Rest
Java
Technology

---

---

---

---

---