Learning GitOps with Argo CD and Kargo: From Sync to Promotion

I have been learning GitOps by building a hands-on lab on a Kind cluster, where Git is the source of truth and cluster changes are driven by commits, not manual kubectl edits.

The goal was simple:

• Understand how Argo CD continuously reconciles desired state
• Learn how Kargo handles promotions across environments
• Practice a repeatable dev -> test -> prod flow

Why I Chose This Learning Setup

I wanted practical experience rather than only reading docs. So I built a small HelloWorld workload and wired it into a full GitOps pipeline:

• Kind as the local Kubernetes cluster
• Helm chart for application packaging
• Argo CD ApplicationSet to generate one app per environment
• Kargo Warehouse + Stage resources for controlled promotions

This made it easier to understand the full lifecycle from code commit to promoted release.

How the Flow Works

At a high level, my setup works like this:

1. I push a commit to main.
2. Kargo Warehouse detects new Git history and creates Freight.
3. Kargo promotes through stages using policy:
   • dev: auto
   • test: auto
   • prod: manual approval gate
4. Each stage updates its matching Argo CD application revision.
5. Argo CD syncs that environment to the desired state.

This gave me a clear model of progressive delivery with guardrails.

Argo CD Structure I Trialled

I used an ApplicationSet pattern to create separate applications per environment (helloworld-dev, helloworld-test, helloworld-prod) and deploy each to its own namespace.

That separation helped with:

• Cleaner troubleshooting per environment
• Safer rollout progression
• Reduced chance of cross-environment mistakes

Kargo Promotion Model I Trialled

Kargo was the part I especially wanted to learn, because it adds promotion orchestration on top of GitOps reconciliation.

In my trial:

• Warehouse subscribed to the Git repository branch
• Stage resources defined promotion order (dev -> test -> prod)
• ProjectConfig enabled auto-promotion for dev/test and manual for prod
• Promotion steps used Argo CD update actions to move each app revision forward

This helped me understand the difference between:

• Syncing (Argo CD keeps an environment converged), and
• Promoting (Kargo decides what revision should move next)

What I Learned

A few things clicked while building this:

• GitOps is not just deployment automation; it is an operating model.
• Environment boundaries matter, even in a small lab.
• Promotion policy (automatic vs manual) is where release discipline starts.
• Keeping manifests and workflow definitions in Git makes troubleshooting easier.

Challenges I Ran Into

Like most learning projects, I hit a few practical issues:

• Credential setup for private repository access
• Port-forward and local access quirks while testing UIs
• Namespace and NodePort collisions during repeated experiments

Working through these was useful because they are the same kinds of issues teams face in real pipelines.

What I Plan to Explore Next

My next focus areas are:

• Policy checks before promotion
• Better rollback workflows by stage
• Using GitOps patterns with Gateway API and ingress changes
• Expanding this pattern into my cloud-hosted K3s lab

Final Thoughts

Trialling Argo CD and Kargo in a real repo taught me more than any diagram could. Seeing commits become promoted revisions across environments gave me a much stronger understanding of modern GitOps delivery.

I am still learning these tools and I am far from an expert. I still have many questions around Argo CD and Kargo that I need to clarify before I feel fully comfortable with them. My main goal now is to keep building more real, hands-on experience so I can deepen my practical understanding over time.

If you are learning GitOps too, start small, keep your environments clear, and make promotion rules explicit early.