GitHub Actions for Deployment: CI/CD Pipeline Guide

Why GitHub Actions for Deployment?

Deployment should be boring — a predictable, automated process that happens dozens of times a day without drama. GitHub Actions turns your repository into the single source of truth for both code and delivery logic. Because PandaStack integrates natively with GitHub, every workflow you define feeds directly into PandaStack's auto-deploy engine.

Structuring a Production-Ready Pipeline

A well-designed pipeline separates concerns into discrete stages: validate → build → deploy. Each stage can fail independently, giving you fast, actionable feedback.

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

on:
  push:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm test -- --coverage

  build:
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

The needs: validate keyword ensures the build step only runs after all validation checks pass.

Environment-Specific Deployments

Most teams maintain at least two environments: staging and production. GitHub Actions supports this through environments, which can require manual approval before deploying to production.

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Install PandaStack CLI
        run: npm install -g @pandastack/cli
      - name: Deploy to staging
        env:
          PANDA_TOKEN: ${{ secrets.PANDA_TOKEN }}
        run: |
          panda login --token $PANDA_TOKEN
          panda deploy --env staging --branch main

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # Requires manual approval in GitHub UI
    steps:
      - uses: actions/checkout@v4
      - name: Install PandaStack CLI
        run: npm install -g @pandastack/cli
      - name: Deploy to production
        env:
          PANDA_TOKEN: ${{ secrets.PANDA_TOKEN }}
        run: |
          panda login --token $PANDA_TOKEN
          panda deploy --env production --branch main

Handling Rollbacks

Every PandaStack deployment is versioned. If a production deploy causes issues you can roll back from the dashboard at [dashboard.pandastack.io](https://dashboard.pandastack.io) or via the CLI:

# List recent deployments
panda deployments list --env production

# Roll back to a specific deployment
panda deployments rollback --id dep_abc123 --env production

You can also trigger an automatic rollback in your workflow by checking a health endpoint after deployment:

      - name: Smoke test
        run: |
          sleep 30
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://your-app.pandastack.io/health)
          if [ "$STATUS" != "200" ]; then
            echo "Smoke test failed with status $STATUS"
            panda deployments rollback --env production --latest
            exit 1
          fi

Notifications and Observability

Keep your team informed by posting deployment status to Slack or creating GitHub deployment statuses:

      - name: Notify on success
        if: success()
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }}             -H 'Content-type: application/json'             --data '{"text":"✅ Production deploy succeeded for ${{ github.sha }}"}'

      - name: Notify on failure
        if: failure()
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }}             -H 'Content-type: application/json'             --data '{"text":"🚨 Production deploy FAILED for ${{ github.sha }}"}'

Deployment Checklist

Before shipping your pipeline to production, verify the following:

• Secrets are stored in GitHub Secrets, never in workflow YAML.
• Production environment requires at least one approver.
• A smoke test or health check follows every production deploy.
• Concurrency groups prevent two production deploys from running simultaneously.
• Branch protection rules require the CI workflow to pass before merging.

concurrency:
  group: production-deploy
  cancel-in-progress: false   # Never cancel a running production deploy

With this pipeline in place your team can ship multiple times per day with confidence, knowing that every deployment is tested, approved, and monitored automatically.