Skip to content

git_ops_with_argo_cd_spring_boot.md

Latest commit

 

History

History
453 lines (321 loc) · 8.3 KB

git_ops_with_argo_cd_spring_boot.md

File metadata and controls

453 lines (321 loc) · 8.3 KB

GitOps with Argo CD – Spring Boot (Dev & QA)

This README explains GitOps from first principles, using a Spring Boot application, GitHub Actions (CI), and Argo CD (CD).

The goal is clarity and auditability, not clever automation.

1. What problem GitOps solves

Traditional pipelines:

  • CI builds the app
  • CI directly deploys to Kubernetes

Problems:

  • Cluster state can drift from Git
  • Hard to audit who deployed what
  • Rollbacks are tool-specific

GitOps flips this model:

Git is the single source of truth for what should be running in the cluster.

The cluster is continuously reconciled to match Git.

2. Two-repo model (most common and safest)

Repo A – Application repo (Spring Boot)

Purpose: build artifacts only

lending-app/
  src/
  Dockerfile
  pom.xml
  .github/workflows/ci.yml

Responsibilities:

  • Compile and test code
  • Build container image
  • Push image to registry

This repo does NOT deploy to Kubernetes.

Repo B – GitOps repo (environment state)

Purpose: declare what runs in each environment

lending-gitops/
  apps/
    lending-app/
      base/
      overlays/
        dev/
        qa/

Responsibilities:

  • Kubernetes manifests (Deployment, Service, Route)
  • Environment-specific configuration
  • Image tag / commit hash

This repo represents the desired state of the cluster.

3. CI pipeline (GitHub Actions) – what it does

CI is intentionally boring and limited.

Typical flow:

  1. Build & test Spring Boot app
  2. Build container image
  3. Push image to registry

Example outcome:

my-registry/lending-app:1a2b3c

CI stops here.

No kubectl. No helm. No cluster credentials.

4. Manual GitOps deployment (intentional & valid)

Deployment happens via Git change, not CI.

Step-by-step

  1. Developer opens the GitOps repo
  2. Chooses environment (dev or qa)
  3. Updates image tag
  4. Commits or raises a PR

Example (kustomization.yaml):

images:
  - name: my-registry/lending-app
    newTag: 1a2b3c

This commit now represents:

"This is what should be running in dev."

5. Argo CD – what it does

Argo CD runs inside the cluster and continuously:

  1. Pulls the GitOps repo
  2. Renders manifests (plain YAML / Kustomize / Helm)
  3. Compares Git vs live cluster state
  4. Applies changes to reconcile the cluster

Argo CD does not build images. Argo CD does not contain business logic.

6. End-to-end flow (manual promotion)

Developer pushes code
   |
   v
GitHub Actions (CI)
   - build
   - test
   - push image
   |
   v
Image registry
   |
   |  (manual Git change)
   v
GitOps repo (image tag updated)
   |
   v
Argo CD detects Git change
   |
   v
Kubernetes Deployment rolls out

7. Why teams prefer manual GitOps updates

Clear separation of concerns

Responsibility Owner
Build artifacts CI
Decide what runs Humans via Git
Apply to cluster Argo CD

Auditability

  • Every deployment is a Git commit
  • Who, when, why is recorded
  • Rollback = git revert

Safety (especially for prod)

  • CI has no prod access
  • No accidental auto-deploys
  • PR approvals enforce control

8. Dev vs QA with Kustomize (example)

Base (shared)

apps/lending-app/base/
  deployment.yaml
  service.yaml
  kustomization.yaml

Dev overlay

apps/lending-app/overlays/dev/
  kustomization.yaml   # image tag, replicas

QA overlay

apps/lending-app/overlays/qa/
  kustomization.yaml   # different image tag, replicas

Only the differences live in overlays.

9. Rollback model

Rollback is boring (by design):

  1. Revert Git commit in GitOps repo
  2. Argo CD reconciles cluster back

No special tooling required.

10. Why this is considered “mature GitOps”

  • Git is the only source of truth
  • CI and CD are cleanly separated
  • Humans control promotion
  • Argo CD enforces convergence

This model is common in:

  • banks
  • regulated enterprises
  • multi-team platforms

11. One-sentence summary (use in interviews)

"Our CI only builds images. Deployment is a Git change in the GitOps repo, and Argo CD reconciles the cluster to match Git."

12. Key takeaway

GitOps is not about speed.

It is about:

  • correctness
  • traceability
  • predictability

Boring on purpose.

13. Repo structure (tailored, end-to-end)

Below is a realistic, end-to-end repo layout matching what we discussed.

Application repo (Spring Boot)

lending-app/
├── src/main/java/
├── src/test/java/
├── Dockerfile
├── pom.xml
└── .github/
    └── workflows/
        └── ci.yml

Responsibilities

  • Build & test Java code
  • Build container image
  • Push image to registry

This repo has no Kubernetes manifests.

GitOps repo (desired runtime state)

lending-gitops/
├── apps/
│   └── lending-app/
│       ├── base/
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── dev/
│           │   └── kustomization.yaml
│           └── qa/
│               └── kustomization.yaml
└── argo-apps/
    └── lending-app-dev.yaml

Key points

  • base/ never changes often
  • overlays/* change per environment
  • image tag changes happen only in overlays

14. ASCII diagrams

High-level GitOps flow

┌────────────┐
│ Developer  │
└─────┬──────┘
      │  git push
      v
┌────────────┐
│ App Repo   │  (Spring Boot)
└─────┬──────┘
      │  CI: build & push image
      v
┌────────────┐
│ Registry   │  lending-app:<sha>
└─────┬──────┘
      │
      │  manual Git change
      v
┌────────────┐
│ GitOps Repo│  (image tag updated)
└─────┬──────┘
      │
      │  watched by Argo CD
      v
┌────────────┐
│ Argo CD    │
└─────┬──────┘
      │  kubectl apply
      v
┌────────────┐n│ Kubernetes │
│ Deployment │
└────────────┘

Dev → QA promotion

GitOps Repo

apps/lending-app/overlays/dev  ---> image: abc123
apps/lending-app/overlays/qa   ---> image: xyz999

Promotion = copy known-good image tag from dev to qa

15. FAQ / Gotchas

Q: Why not let CI update the GitOps repo automatically?

A: You can, but manual updates:

  • enforce human approval
  • prevent accidental prod deploys
  • give cleaner audit trails

Many regulated orgs prefer manual promotion.

Q: What if someone edits Kubernetes resources directly?

A: Argo CD will revert them back to Git state.

This is called self-healing and is a core GitOps feature.

Q: Where do secrets live?

A: Not in plain Git. Common patterns:

  • sealed-secrets
  • SOPS-encrypted YAML
  • external secret operators

GitOps repo stores references, not raw secrets.

Q: Who owns the GitOps repo?

A: Usually:

  • platform / SRE team owns structure
  • app teams own their app folders

This prevents teams from breaking each other.

Q: Is Argo CD doing deployments or Kubernetes?

A: Kubernetes does deployments.

Argo CD only:

  • detects Git drift
  • applies manifests

Q: How do rollbacks work exactly?

A:

  1. git revert the image-tag commit
  2. push
  3. Argo CD syncs back automatically

No special rollback tooling required.

16. GitOps for Architects (short version)

The model

  • CI builds immutable artifacts
  • Git declares desired runtime state
  • Argo CD reconciles continuously

Why it scales

  • no shared deployment credentials
  • no snowflake clusters
  • consistent promotion model

Why it’s safe

  • Git is auditable
  • rollbacks are deterministic
  • environments are explicit

One-liner for leadership

“We separated build from deploy. Git defines what runs, and Argo CD enforces it.”

17. Final takeaway

GitOps works best when it is:

  • boring
  • explicit
  • human-controlled

Argo CD is not magic.

It is a Git-to-cluster reconciliation engine.