Cloud & DevOps💻 Technical CourseLearnAspire Certified

GitHub Actions + Docker 25.0: Multi-Environment Deployment Pipelines Without Copy-Paste

“Ship to three environments without copy-pasting a single workflow.”

Build a production-grade dev→staging→prod pipeline with environment-scoped secrets, OIDC auth, matrix testing, and manual approval gates — the way a senior DevOps engineer actually configures it.

Intermediate12h6 modules52 slides18 exercises24 quiz Qs
🔥 Launch Price — 63% off. Limited time.
₹2,999₹7,999

One-time · Lifetime access · Certificate included

Sign in to Enroll
7-day money-back guarantee
  • ✓6 modules of content
  • ✓52 concept slides
  • ✓18 practical exercises
  • ✓24 quiz questions
  • ✓Capstone project
  • ✓LearnAspire certificate

Learning Outcomes

What you'll learn

→You will be able to write a Docker 25.0 multi-stage build that produces a lean production image and a separate test-runner stage, with layer ordering that survives a cache miss without rebuilding your dependency install layer
→You will be able to configure a GitHub Actions workflow that runs a Jest 29 test matrix across Node.js 18 and 20, gates a GHCR image push on all matrix jobs passing, and tags the image with the Git SHA so every pushed image is traceable to a specific commit
→You will be able to configure three GitHub Environments (dev, staging, prod) with environment-scoped secrets, inject those secrets into ECS Fargate task definitions using OIDC role assumption (no static AWS_ACCESS_KEY_ID), and verify that a secret set in staging never leaks into a prod job
→You will be able to add a manual approval gate to a prod deployment job using GitHub Environment protection rules, write a conditional job that only runs when needs.deploy-staging.result == 'success', and produce a deploy summary using the GitHub Actions summary API that your team lead can read in the Actions run log without opening a terminal
→You will be able to diagnose and fix the three most common silent failure modes in a multi-environment pipeline — a Docker layer cache miss that invalidates a passing build, a matrix job that marks a workflow green despite one leg failing, and an OIDC token that expires mid-job — by reading the exact log lines that signal each failure

The day after you finish

The day after completing this course, you will open the Velo Systems repository, delete the three environment-specific workflow files Maya inherited, replace them with a single reusable workflow that references GitHub Environment secrets by name, configure a manual approval gate on the prod environment in the GitHub UI, push a commit, and watch dev and staging deploy automatically while prod waits for your approval — with a deploy summary in the Actions run log showing the image SHA promoted across all three environments.

Who this is for

  • Primary: Mid-level backend developer or junior DevOps engineer with 2–3 years of experience who has written a Dockerfile and a basic GitHub Actions workflow but is copy-pasting workflow files across environments and managing secrets manually
  • Secondary: Platform engineer or SRE who inherited a brittle single-environment pipeline and needs to make it auditable and multi-environment before a compliance or due-diligence review
  • Tertiary: Engineering manager or tech lead who will review, approve, or inherit the pipelines their team builds using these patterns

Prerequisites

  • Can write a Dockerfile from scratch and understand what COPY, RUN, and EXPOSE do — no layer caching or multi-stage theory required, but syntax must be familiar
  • Has triggered at least one GitHub Actions workflow (e.g., run tests on push) and can read a workflow YAML file without confusion at the on:, jobs:, and steps: keys
  • Understands git branches, pull requests, and what 'pushing to main' means in a team workflow
  • Knows what an environment variable is and has set one in a .env file or a CI settings panel — does NOT need to know GitHub Secrets or OIDC
  • Has a GitHub account and can create a repository — no AWS account required for Modules 1–4; AWS OIDC setup is demonstrated in Module 4 with a step-by-step IAM role configuration included

Curriculum

6 modules · full breakdown

☁️ Part of: Cloud & DevOps Path

Step 1 — AWS Basics
→Step 2 — CI/CD
→Step 3 — Docker + CI/CD
→Step 4 — Advanced CI/CD
→Step 5 — Terraform IaC
→Step 6 — Security
← Previous: Step 3 — Docker + CI/CDNext in path: Step 5 — Terraform IaC →
🏆

Capstone Project

Velo Systems Production Pipeline: Three-Environment Promotion with OIDC, Matrix Tests, and Approval Gates

Fork the Velo Systems starter repository (Node.js 20 Express API with Jest 29 test suite and a /health endpoint), configure three GitHub Environments with environment-scoped secrets, write a single reusable workflow that builds a Docker 25.0 multi-stage image, runs a matrix test across Node.js 18 and 20, pushes a SHA-tagged image to GHCR only on full matrix pass, promotes the image through dev and staging automatically, gates prod behind a manual approval step using environment protection rules, and injects AWS credentials via OIDC role assumption at each stage — then submit the Actions run URL and workflow YAML for rubric evaluation against six criteria: no hardcoded secrets, conditional job gates using needs context, environment protection rules applied, matrix failure correctly blocks image push, OIDC used for all AWS auth, and deploy summary visible in run log

What you'll deliver

A public GitHub repository containing: one reusable workflow file (.github/workflows/deploy.yml), one caller workflow per environment trigger pattern, three configured GitHub Environments with scoped secrets, and a passing end-to-end Actions run URL showing successful dev→staging promotion and a prod job waiting on manual approval, with a deploy summary artifact in the run log

Sign in to Enroll →