Go GitOps with Argo CD
Continues from the last build: TaskFlow CI pushes images and the pipeline runs helm upgrade against the cluster (push-based).
In the previous rung your GitHub Actions pipeline built the TaskFlow image, pushed it to ECR, and finished with a `helm upgrade` straight into EKS.
What you'll build
TaskFlow is deployed by Argo CD using GitOps. A dedicated config repo holds the Helm chart values and the current image tag; Argo CD watches it and syncs EKS to match. CI no longer has cluster credentials, it only commits a new tag to the config repo. You can see live-vs-desired drift in the Argo CD UI, a PreSync hook runs the database migration before the app rolls out, and you can roll back any release with a single `git revert`.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
# Single source of truth for what runs in the cluster. # CI changes ONLY the image.tag line below. Nothing else. image: repository: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/taskflow-backend tag: "sha-0000000" # CI overwrites this with the new commit SHA pullPolicy: IfNotPresent # sha- tags are immutable, so IfNotPresent is safe replicaCount: 2 # Probe path stays stable across every rung. healthcheck: path: /healthz # DATABASE_URL comes from a Secret, never hard-coded (12-factor). database: secretName: taskflow-db secretKey: DATABASE_URL # Run the DB migration before the app rolls out (see sync hooks milestone). migration: enabled: true
Reading this file
tag: "sha-0000000"A placeholder image tag; CI overwrites this exact line with the real commit SHA on every build.repository: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/taskflow-backendThe full ECR address Argo CD tells Kubernetes to pull the image from; replace the account number with yours.pullPolicy: IfNotPresentPins the pull behavior; because each deploy uses a unique sha- tag, a node only pulls an image it does not already have.path: /healthzThe same health endpoint used as the readiness probe in every rung, kept stable on purpose.secretName: taskflow-dbTells the chart which Kubernetes Secret holds the database URL, so credentials never sit in Git.
The image.tag line is the only thing CI is allowed to change. Everything else is reviewed by humans through pull requests. pullPolicy is pinned explicitly so the rollback drill behaves the same on a freshly scaled node.
That's 1 of 8 explained code blocks in this single project.
The build, milestone by milestone
- 1
Install Argo CD on EKS and reach the UI
4 guided stepsArgo CD is the in-cluster brain of GitOps. It runs the reconciliation loop that compares Git to the live cluster. Installing it correctly, with its own namespace and a known admin login, is the foundation everything else in this rung sits on.
- 2
Create the config repo and the first Argo CD Application
4 guided stepsSplitting app code from deployment config is the core GitOps move. The config repo becomes the single declarative source of truth for what runs, separate from the code that gets built. The Application object is the contract that says: this Git path equals this place in the cluster.
- 3
Turn on automated sync, self-heal, and prune
4 guided stepsThis is the moment the cluster stops being editable by hand and starts being a projection of Git. Self-heal closes the 2am-kubectl-edit hole, prune keeps Git the complete picture, and automated sync is what makes a merge a deploy.
- 4
Order the rollout with a PreSync hook: migrate DB before app
4 guided stepsWithout ordering, Argo CD may apply the new Deployment and the migration Job at the same time, and the app can start against a schema it expects to already be migrated. A PreSync hook gives you a deterministic order: schema first, then code, which is exactly what schema-then-code deploys need.
- 5
Make CI write the image tag instead of deploying
4 guided stepsThis is the security payoff of the rung. With pull-based GitOps the CI runner never holds cluster-admin; the worst a compromised pipeline can do is open a commit to the config repo, which a human can review and revert. Deploys become auditable git history instead of opaque pipeline logs.
- 6
Roll back a bad deploy with git revert
4 guided stepsRollback discipline is what makes GitOps trustworthy in an incident. Because desired state is Git history, recovery is a normal git operation that leaves an audit trail and keeps Git and cluster in agreement. UI rollbacks drift from Git unless they are followed by a commit.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building