Back to path
AdvancedTaskFlow · Project 10 of 13 ~8h· 6 milestones

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.

GitOps and declarative desired-state deliveryInstalling and operating Argo CD on EKSStructuring app vs config repositoriesArgo CD Applications, sync phases, hooks, and automated sync policiesDrift detection and git-revert rollback

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:

taskflow-config/apps/taskflow/values.yamlyaml
# 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. 1

    Install Argo CD on EKS and reach the UI

    4 guided steps

    Argo 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. 2

    Create the config repo and the first Argo CD Application

    4 guided steps

    Splitting 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. 3

    Turn on automated sync, self-heal, and prune

    4 guided steps

    This 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. 4

    Order the rollout with a PreSync hook: migrate DB before app

    4 guided steps

    Without 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. 5

    Make CI write the image tag instead of deploying

    4 guided steps

    This 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. 6

    Roll back a bad deploy with git revert

    4 guided steps

    Rollback 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

2 starter files, ready to clone
6 guided milestones
6 full reference solutions
8 code blocks explained line-by-line
6 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A separate taskflow-config repo holding the vendored Helm chart and the current image tag as the single source of truth
Argo CD installed on EKS with a taskflow Application using automated sync, self-heal, and prune
A migration Job ordered ahead of the app via a PreSync hook with a BeforeHookCreation delete policy
A CI pipeline that builds and pushes the image then writes only the image tag to the config repo, with no cluster credentials
A demonstrated git revert rollback restoring TaskFlow to a previous good image tag

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