World map

 

BM: Baca dalam Bahasa Melayu

World C1: Pipeline Thinking

Build once, promote through environments

You will learn: why the build that staging tested is the build that production gets.

Checked with GitHub Actions 2026-10 on 31 Oct 2026

The problem

Staging worked perfectly. Then production broke. Same code! What changed?

Pick one answer.

Watch

Tap each point on the timeline.

Tap each place. Each place your app runs is an environment: A named place you deploy to, like production, with its own secrets and rules..

Try it

Cook once and seal the pack. That sealed pack is the artifact: Files a workflow run saves, so you can download them later.. Put its trip in order.

First step at the top. Put these in order. Use the arrows, or drag.

  • Deploy it to staging
  • Send the same artifact to production
  • Check staging
  • Build and seal the artifact

Watch

Pick an event. Press Run and watch the line.

What happened on GitHub

Workflow file .github/workflows/promote.yml

name: Promote
on:
push:
branches: [main]
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: npm ci && npm test && npm run build
- uses: actions/upload-artifact@v7
with:
name: site
path: dist
staging:
needs: build
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v7
- uses: actions/download-artifact@v8
with:
name: site
path: dist
- run: npx wrangler deploy --env staging
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
- run: curl --fail --silent https://staging.example.com/health
production:
needs: staging
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v7
- uses: actions/download-artifact@v8
with:
name: site
path: dist
- run: npx wrangler deploy
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

The line

Push to main · main

Press Run. The build happens once. Staging and production get the same pack. Moving it on is called promote: Move the same tested build on to the next environment, like from staging to production..

Predict

Why not make a fresh build just for production?

Pick one answer.

Predict

Staging’s health check finds a problem.

Which station will stop the line? Tap it, then press Run.

What happened on GitHub

Workflow file .github/workflows/promote.yml

name: Promote
on:
push:
branches: [main]
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: npm ci && npm test && npm run build
- uses: actions/upload-artifact@v7
with:
name: site
path: dist
staging:
needs: build
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v7
- uses: actions/download-artifact@v8
with:
name: site
path: dist
- run: npx wrangler deploy --env staging
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
- run: curl --fail --silent https://staging.example.com/health
production:
needs: staging
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v7
- uses: actions/download-artifact@v8
with:
name: site
path: dist
- run: npx wrangler deploy
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

The line

Push to main · main

Check

Good habit, or needs work? Swipe each one.

Swipe right for good, left for needs work. Or use the buttons.

1 / 4

Build once, then deploy that same artifact everywhere

Build once, then deploy that same artifact everywhere

You did it!

You can now build once and promote the same artifact.

Go deeper (optional)

Web addresses and keys differ per place. They come in at deploy time. In GitHub, environment: on a job picks that place’s secrets and rules. Container images make this easy: one image, many places (World C2).

Real rep (optional): find where your repo builds. Does a deploy job build again? Pass the build on with actions/upload-artifact and actions/download-artifact instead.