You now know ALL the tools. The final skill: knowing WHEN to use which one. This lesson is a collection of decision frameworks — the judgment that makes someone a senior DevOps architect rather than a tool operator.
Decision 1: Push CD vs GitOps
Decision 2: Helm vs Kustomize
| Helm | Kustomize | |
|---|---|---|
| Choose when | Complex templating, many parameters, shared charts across teams | Simple overlays, no template logic, pure K8s YAML |
| Learning curve | Higher (Go templates, chart structure) | Lower (just patches on base YAML) |
| Packaging | Versioned chart in registry | Just directories in Git |
| ArgoCD support | Native | Native |
| Rollback | helm rollback (built-in history) | git revert (Git is the history) |
Architect's rule of thumb: Start with Kustomize (simpler). Graduate to Helm when you need: versioned chart packaging, complex conditionals, or shared charts across multiple teams/repos.
Decision 3: Deployment Strategy
| Service Type | Strategy | Why |
|---|---|---|
| Internal API, low traffic | Rolling Update | Simple, zero-downtime, K8s default |
| User-facing, high traffic | Canary (Argo Rollouts) | Limit blast radius, automated validation |
| Database migration required | Blue-Green | Atomic switch, easy rollback, no mixed versions |
| Dev/preview environments | Recreate | Fast, simple, downtime acceptable |
Decision 4: Mono-Repo vs Multi-Repo
| Mono-Repo | Multi-Repo | |
|---|---|---|
| Best for | Tightly coupled services, shared libs, small team | Independent services, large org, clear ownership |
| CI complexity | Higher (path filtering, change detection) | Lower per repo (but many repos to manage) |
| Shared code | Direct imports (same repo) | Published packages (npm, etc.) |
| GitOps repo | One GitOps repo, many paths | One GitOps repo (or one per cluster) |
Decision 5: When to Auto-Deploy vs Gate
| Environment | Auto-Deploy? | Gate Type |
|---|---|---|
| Dev/Preview | ✅ Always | None — fail fast |
| Staging | ✅ Always | Smoke test (automated) |
| Production (low-risk) | ✅ With canary | Automated analysis |
| Production (high-risk) | ❌ PR-based | Human review + merge |
| Compliance/regulated | ❌ Never | Multi-party approval + audit |
The Complete Architecture (What You Can Now Build)
┌───────────────────────────────────────────────────────────────────────────┐
│ YOUR PRODUCTION CI/CD ARCHITECTURE │
├───────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────────────┐ ┌──────────────────┐ │
│ │ App Repo │─CI─▶│ GitHub Actions │─────▶│ ACR │ │
│ │ (src, test) │ │ test → build → sign │ │ (signed images) │ │
│ └──────────────┘ └──────────┬───────────┘ └──────────────────┘ │
│ │ │
│ update image tag │
│ │ │
│ ┌──────────────┐ ▼ │
│ │ GitOps Repo │◀────── commit / PR │
│ │ (Kustomize) │ │
│ └──────┬───────┘ │
│ │ ArgoCD watches │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ AKS Cluster │ │
│ │ ┌──────────┐ ┌──────────────┐ ┌─────────┐ ┌──────────────────┐ │ │
│ │ │ ArgoCD │ │ Argo │ │ Gate- │ │ External │ │ │
│ │ │ (sync) │ │ Rollouts │ │ keeper │ │ Secrets (ESO) │ │ │
│ │ └──────────┘ │ (canary) │ │ (policy)│ └──────────────────┘ │ │
│ │ └──────────────┘ └─────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ staging │ │ production │ │ preview │ │ │
│ │ │ (auto-sync) │ │ (PR-based) │ │ (per-PR) │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │
│ Security: OIDC auth │ Signed images │ Policies │ No stored secrets │
│ Speed: Caching │ Parallelism │ Concurrency cancel │ Layer cache │
│ Reliability: Atomic deploys │ Self-heal │ Auto-rollback │ DR via Git │
│ │
└───────────────────────────────────────────────────────────────────────────┘
🧠 Final Recall Check
As an architect, answer these scenario questions:
- A startup with 3 devs, 1 service, deploying to Azure App Service. What CI/CD approach?
- A fintech company with 20 microservices on AKS, strict audit requirements. What approach?
- Your canary is showing 3% error rate (baseline is 1%). What happens automatically?
- Someone accidentally deletes the production namespace. How fast can you recover with GitOps?
- You need to roll back the last production deploy. What do you do?
Reveal answers
- Simple push-based CD. GitHub Actions → test → deploy to App Service with OIDC. Add Environments for staging/production approval. Don't over-engineer with GitOps for 1 service.
- Full GitOps. ArgoCD + ApplicationSet + PR-based promotion + image signing + Gatekeeper policies + External Secrets. Audit trail = Git history. Compliance = signed images + admission control.
- Argo Rollouts auto-rollback. The AnalysisTemplate detects error rate > threshold → rollout aborted → traffic returns to stable version. Zero human intervention.
- Minutes. ArgoCD's self-heal detects the drift and recreates everything in that namespace from Git. If ArgoCD itself is gone: reinstall ArgoCD → apply root app → everything syncs back.
git revert <deploy-commit>in the GitOps repo (or revert the PR). ArgoCD syncs the reverted state → old image deployed. Under 5 minutes total.
🎓 What You've Mastered
You can now:
- ✅ Design a CI/CD architecture for any team size and complexity
- ✅ Implement GitHub Actions pipelines from simple to production-grade
- ✅ Deploy to Azure (App Service, AKS) with zero stored credentials
- ✅ Build, scan, sign, and push container images
- ✅ Operate ArgoCD for GitOps delivery with progressive rollouts
- ✅ Secure the entire pipeline (supply chain, admission, policies)
- ✅ Optimize for speed, cost, and reliability
- ✅ Make architectural decisions with confidence and defend them
You're ready to be the person who designs the pipeline architecture for your team. 🎉