Day 4 of 5

Deployment Pipelines

A deployment pipeline automates delivery to staging and production. Today you will deploy to a cloud platform after tests pass, using environment protection rules to require manual approval for production.

yaml

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci && npm test

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Render (staging)
        run: |
          curl -X POST ${{ secrets.RENDER_STAGING_DEPLOY_HOOK }}

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # requires manual approval
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Render (production)
        run: |
          curl -X POST ${{ secrets.RENDER_PROD_DEPLOY_HOOK }}

Tip: In GitHub Settings → Environments, add required reviewers to the production environment to gate deployments behind manual approval.

yaml

# Deploy to Fly.io
      - uses: superfly/flyctl-actions/setup-flyctl@master
      - run: flyctl deploy --remote-only
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Exercise: Build a Full Deploy Pipeline

Create staging and production environments in GitHub
Add required reviewers to the production environment
Set up a deploy hook or API token for your platform
Add needs: to chain test → staging → production
Push code and walk through the approval flow

Day 4 Summary

needs: creates a dependency between jobs
Environments gate jobs behind protection rules
Deploy hooks are secret URLs that trigger a redeploy
Staging deployments should be automatic; prod needs approval
Use concurrency: to cancel in-flight runs on new push

← Previous

Docker Builds in CI

Secrets, Caching, and Optimization