Back to path
AdvancedTaskFlow · Project 9 of 13 ~10h· 5 milestones

Ship it from a CI/CD pipeline

Continues from the last build: TaskFlow deploys to EKS when you run helm upgrade by hand from your laptop.

Last rung you got TaskFlow running on EKS, but every release still means SSHing into your own headspace: open a terminal, export the right AWS profile, build and push images, then run helm upgrade --install by hand.

Authoring a multi-stage GitHub Actions workflow with job dependencies and gatesConfiguring GitHub-to-AWS OIDC federation and a scoped IAM trust policyBuilding, tagging by git SHA, and pushing container images to Amazon ECR from CIDeploying to EKS with helm upgrade --install driven by CI, parameterizing the image tagGating production with GitHub Environments and required reviewersWriting a deploy and rollback runbook and performing a SHA-based rollback
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

TaskFlow now ships from a GitHub Actions pipeline: every push to main runs backend tests, builds and pushes both images to ECR tagged by commit SHA, and runs helm upgrade to EKS through OIDC with no stored AWS keys, gated by a manual prod approval. You can trace any running pod to an exact commit and roll back deterministically by SHA. No more laptop deploys.

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:

.github/workflows/deploy.ymlyaml
name: deploy
on:
  push:
    branches: [main]

# OIDC needs id-token: write; checkout needs contents: read.
permissions:
  id-token: write
  contents: read

env:
  AWS_REGION: eu-west-1

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - working-directory: backend
        run: |
          pip install -r requirements.txt -r requirements-dev.txt
          pytest -q

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # TODO: configure-aws-credentials with role-to-assume (OIDC)
      # TODO: amazon-ecr-login
      # TODO: docker build + push backend and frontend tagged ${{ github.sha }}

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: prod   # gated by required reviewer in repo settings
    steps:
      - uses: actions/checkout@v4
      # TODO: assume OIDC role, update-kubeconfig, helm upgrade --install with SHA tags

Reading this file

  • permissions: id-token: writeAllows the workflow to mint an OIDC token, the prerequisite for keyless AWS auth.
  • needs: testBuild waits for tests; deploy waits for build, enforcing the pipeline order.
  • environment: prodTies the deploy job to the protected prod environment so it pauses for approval.
  • ${{ github.sha }}The commit SHA you will use as the image tag for traceable, rollback-able deploys.

The job order (test -> build -> deploy) and OIDC permissions are correct out of the box; you fill the TODOs.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Establish OIDC trust between GitHub and AWS

    4 guided steps

    Until now you deployed from your laptop using your personal AWS credentials. A pipeline cannot use your laptop. The naive fix, pasting an access key into GitHub secrets, creates a permanent credential that an attacker keeps forever if it leaks. OIDC removes the standing secret entirely: GitHub proves its identity per run and AWS hands back credentials that expire in minutes.

  2. 2

    Build and push both images to ECR, tagged by git SHA

    4 guided steps

    A pipeline must produce the exact artifact it will deploy, and that artifact must be uniquely named so you can trace what is running and roll back precisely. Building on the runner with a fresh checkout also kills the works on my machine problem: the image is built from the committed source every time, not from whatever is sitting on your laptop.

  3. 3

    Deploy to EKS with helm upgrade --install from the pipeline

    4 guided steps

    Hand-running helm upgrade from a laptop is unrepeatable and unauditable: nobody knows which values or which image actually shipped, and you cannot deploy when you are offline or on holiday. Moving it into the pipeline makes every deploy identical, logged, and tied to a commit, and it lets you pass the SHA tag so Kubernetes does a real rolling update instead of silently reusing a cached latest.

  4. 4

    Gate prod behind a manual approval

    4 guided steps

    Continuous deploy to production with zero human checkpoint is risky for a team still building confidence and for changes like schema migrations. An approval gate gives you a recorded human acknowledgement and a chance to time releases, without reverting to laptop deploys. It is a checkpoint, not a substitute for tests.

  5. 5

    Document and prove a SHA-based rollback

    4 guided steps

    The point of tagging by SHA is deterministic recovery. When a deploy breaks prod, the fastest safe action is returning to the last known-good image, and that must be a documented, practiced procedure, not improvisation during an outage. Writing the runbook also forces you to articulate the trigger, the stages, and who can approve, which is what an on-call engineer needs at 3am.

What's inside when you start

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

You'll walk away with

A .github/workflows/deploy.yml that runs backend tests, builds and pushes both TaskFlow images to ECR tagged by git SHA, and runs helm upgrade --install to EKS, all on push to main.
An IAM OIDC identity provider for GitHub plus an IAM role with a trust policy scoped to your repo, so the pipeline authenticates with no long-lived AWS access keys stored in GitHub.
A GitHub Environment named prod with a required reviewer, gating the deploy job behind a manual approval click.
Helm values wired so the pipeline passes image.tag=<git-sha> at deploy time, making every rollout traceable to an exact commit.
A README section documenting the pipeline: trigger, stages, how to roll back by re-running an older SHA, and who can approve prod.

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