CI/CD pipeline design

[sudoUgando]

What's a common pattern for deploying to staging first, running integration tests, and then promoting to production only if those tests pass — without re-building the code at each stage?

[EimanTahir027]

What's a common pattern for deploying to staging first, running integration tests, and then promoting to production only if those tests pass — without re-building the code at each stage?

This is a build-once, deploy-many pattern, and it's a best practice for CI/CD pipelines. The key insight is to pass the build artifact (or container image) through the stages without rebuilding.

Here's the common pattern using GitHub Actions:

name: Build and promote across environments

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/
          # Keep it around for promotion later
          retention-days: 7

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/
      - run: ./deploy.sh staging

  test-staging:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:integration -- --base-url=${{ secrets.STAGING_URL }}

  promote-to-production:
    needs: test-staging
    runs-on: ubuntu-latest
    if: success()  # Only if integration tests passed
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/
      - run: ./deploy.sh production

Core mechanics:

• A single build job produces the artifact and uploads it with actions/upload-artifact
• Every downstream job downloads the exact same artifact via actions/download-artifact
• The pipeline gates on environment order: build → staging → test → production
• Tests run against the live staging environment, not against the build itself — catching integration and infrastructure issues before production

Variations of this pattern:

• Docker-based: Build the image once, tag it with the commit SHA, push to a registry, then deploy the same image tag to staging → test → production. No download-artifact needed — just reference the tag.
• Environment promotion gates: Use GitHub Environments with required reviewers or approval gates on the production deployment step for an extra safety layer.
• Sliding window: Keep the artifact long enough that a human can inspect it if tests pass but you still want a manual go/no-go before production.

The critical rule is: never rebuild. If you rebuild at each stage, you risk shipping a different artifact than what was tested.