Pipelines and Promotions

A pipeline groups several apps that represent stages of the same product (staging, production) and lets you move releases through them in a controlled way.

Why pipelines

Without a pipeline, every environment builds independently — staging builds from your branch, production builds from your branch, and the two artifacts technically aren’t the same image.

With a pipeline, promotion moves the artifact that staging just validated into production. No rebuild. Same bytes.

A typical shape

• myapp-staging — auto-deploys on main push
• myapp-production — receives promotions from staging

The flow:

1. you merge to main
2. staging builds, deploys, and runs (your QA, smoke tests, manual checks happen here)
3. when staging is healthy, you promote → production gets the same image, with production’s own config vars and add-ons

Promote vs. redeploy

These are not the same thing:

• promote — copy a release’s image into the next stage and let it run there with that stage’s config and add-ons
• redeploy — build from source again

Promote when you want production to run the exact build staging validated. Redeploy when you want a fresh build from current source.

Required checks gate the whole pipeline

If GitHub required checks are configured, the pipeline respects them. A staging deploy that depends on a check won’t proceed until the check passes; the same applies on the way to production.

Tips

• keep staging and production add-ons separate. The whole point is to validate without touching production data.
• match staging and production as closely as you can otherwise. Differences in plan size are fine; differences in code paths defeat the point.
• promote often. Long gaps between staging and production releases turn promotion into a guessing game.