DEV Community

James Lee
James Lee

Posted on

Argo CD Application Updates & Rollbacks: GitOps-Driven Version Control in Practice

#devops #kubernetes #git #cicd

In the previous article, we deployed the Guestbook application to two clusters using Argo CD. Now let's put the GitOps model to the test: updating a live application and rolling it back — all driven through Git.

1. Application Update: v1 → v2

The GitOps Update Workflow

In a GitOps model, Git is the only entry point for application changes. You never update a running application by directly modifying the cluster. Instead:

Create feature branch
        ↓
Update config in Git
        ↓
Open Pull Request
        ↓
Code review + CI checks
        ↓
Merge to main branch
        ↓
Argo CD detects change → OutOfSync
        ↓
Sync (manual or auto) → Healthy ✅
Enter fullscreen mode Exit fullscreen mode

Step 1: Create a Feature Branch and Update the Config

Create a branch feat/guestbook-v2 from master. Update the image tag in both values files:

values.yaml (for guestbook-aliyun):

frontend:
  image:
    tag: v2   # was: v1
Enter fullscreen mode Exit fullscreen mode

values-idc.yaml (for guestbook-idc):

frontend:
  image:
    tag: v2   # was: v1
Enter fullscreen mode Exit fullscreen mode

Commit the changes and open a Pull Request targeting master.

Step 2: Review and Merge the PR

Before merging, the application admin reviews the PR. In a production setup, this step typically includes:

  • ✅ Automated CI checks (lint, unit tests, manifest validation)
  • ✅ Human review of the config diff
  • ✅ Approval from a designated reviewer

Only after all checks pass is the PR merged into master. This is the security and compliance gate — no change reaches production without going through Git history and review.

Step 3: Argo CD Detects the Drift

After the merge, Argo CD will detect the change either:

  • Immediately — if a Git webhook is configured
  • Within 3 minutes — Argo CD's default polling interval
  • On demand — by clicking the REFRESH button in the UI

Once detected, the application status updates to OutOfSync:

Application: guestbook-aliyun

Current live revision:    14afbac   (v1 — running in cluster)
Latest Git revision:      f9c5a9d   (v2 — declared in Git)

Sync Status:  OutOfSync ⚠️
Enter fullscreen mode Exit fullscreen mode

This is GitOps drift detection in action. The cluster hasn't changed yet — only Git has. Argo CD surfaces this discrepancy immediately.

Step 4: Inspect the Diff Before Syncing

Before applying the change, click on the frontend Deployment resource in the topology view to inspect the DIFF:

# Deployment: frontend
# containers[0].image

- image: gcr.io/heptio-images/ks-guestbook-demo:0.1   # v1
+ image: gcr.io/heptio-images/ks-guestbook-demo:0.2   # v2
Enter fullscreen mode Exit fullscreen mode

This diff view lets you verify the change matches your intent before it touches the cluster. It's one of Argo CD's most practical safety features.

Step 5: Sync to Deploy

Since guestbook-aliyun was created with a manual sync policy, trigger the deployment explicitly:

argocd app sync guestbook-aliyun
Enter fullscreen mode Exit fullscreen mode

Or via the Web UI: click SYNC → SYNCHRONIZE.

After a successful sync:

Deployment: frontend    rev:2   [Synced] [Healthy]
Deployment: redis-master        [Synced] [Healthy]
Deployment: redis-slave         [Synced] [Healthy]

Sync Status:   Synced to master @ f9c5a9d
Health Status: Healthy ✅
Enter fullscreen mode Exit fullscreen mode

The frontend Deployment is now at rev:2. Verify in the browser that the application is running v2.

Auto-sync alternative: If you set --sync-policy automated when creating the app, Argo CD would have applied the change automatically after detecting the Git update — no manual sync needed.

2. Application Rollback: v2 → v1

Why Rollback Is Trivial in GitOps

Because every deployed state is tied to a specific Git commit, rolling back is simply a matter of re-deploying a previous commit. Argo CD keeps a history of the last 10 deployments by default.

Step 1: Open the Rollback History

In the Web UI, click HISTORY AND ROLLBACK on the guestbook-aliyun application detail page.

You'll see the full deployment history:

#  Git Revision  Deployed At              Status
─────────────────────────────────────────────────
2  f9c5a9d       2020-10-10 17:30 CST     Current
1  14afbac       2020-10-10 16:07 CST     Previous
Enter fullscreen mode Exit fullscreen mode

Step 2: Trigger the Rollback

Click ROLLBACK next to revision 14afbac (v1).

Argo CD immediately re-applies the manifests from that Git revision to the cluster.

Step 3: Verify the Rollback

After the rollback completes:

Deployment: frontend    rev:3   [Synced] [Healthy]

Sync Status:   OutOfSync ⚠️
Health Status: Healthy ✅
Enter fullscreen mode Exit fullscreen mode

Two things to note here:

Why rev:3 and not rev:1?
Kubernetes increments the Deployment revision counter on every rollout — including rollbacks. rev:3 means this is the third rollout event, even though the running image is back to v1.

Why OutOfSync?
After a rollback, the cluster is running v1 but Git still declares v2. Argo CD correctly reports this as OutOfSync — the cluster state no longer matches the Git state. This is intentional: a rollback is an emergency operation, and Git should be updated to reflect the new desired state when the team is ready.

Cluster state:  v1 (rolled back)
Git state:      v2 (unchanged)
Sync Status:    OutOfSync ⚠️  ← expected after rollback
Enter fullscreen mode Exit fullscreen mode

Best practice: After a rollback, open a PR to revert the Git config back to v1 (or to a fixed v3). This keeps Git as the source of truth and closes the drift gap.

Verify in the browser that the application is back to v1. ✅

3. The Full Update & Rollback Lifecycle 

v1 deployed (14afbac) → Synced / Healthy
        ↓
PR merged: image tag → v2 (f9c5a9d)
        ↓
Argo CD detects drift → OutOfSync
        ↓
Diff reviewed → Sync triggered
        ↓
v2 deployed (f9c5a9d) → Synced / Healthy
        ↓
Issue detected → Rollback to 14afbac
        ↓
v1 re-deployed → OutOfSync / Healthy
        ↓
PR opened to revert Git → Synced / Healthy ✅
Enter fullscreen mode Exit fullscreen mode

4. Manual Sync vs Auto-Sync — When to Use Which

Scenario Recommended Policy Reason
Production environment Manual Require human approval before any cluster change
Staging / dev environment Auto Fast feedback loop, no manual intervention needed
Hotfix deployment Manual Extra caution, verify diff before applying
Infrastructure config Manual High blast radius — always review before sync

You can set the sync policy at creation time:

# Manual (default)
argocd app create myapp ... --sync-policy none

# Automatic
argocd app create myapp ... --sync-policy automated

# Automatic with self-healing (reverts manual cluster changes)
argocd app create myapp ... --sync-policy automated --self-heal
Enter fullscreen mode Exit fullscreen mode

5. Summary

Operation How it works in Argo CD
Update Merge PR to Git → Argo CD detects OutOfSync → Sync
Diff inspection Click resource in topology → view Live vs Desired manifest
Manual sync argocd app sync <name> or UI SYNC button
Auto sync Argo CD applies changes automatically on Git update
Rollback HISTORY AND ROLLBACK → select revision → ROLLBACK
Post-rollback Open PR to revert Git config → restore Synced state

The GitOps model makes updates and rollbacks auditable, reversible, and safe. Every change has a PR, a reviewer, a commit hash, and a deployment record. When something goes wrong, you know exactly what changed, when, and by whom — and you can undo it in seconds.

Series Complete! You've now covered the full GitOps stack:

  • Part 1–3: GitOps fundamentals, DevOps comparison, CD model
  • Part 4–6: Tekton components, concept model, and CI pipeline in practice
  • Part 7–8: Argo CD architecture, installation, and configuration
  • Part 9–10: Argo CD application management, updates, and rollbacks

Thanks for following the series. If you found it useful, share it with your team — and check out the Argo CD and Tekton official docs for deeper dives into production configurations.

Top comments (0)