Release Pipelines
The release pipeline takes a tested artifact and moves it safely through environments to production.
On this page · 5 min · Intermediate
On this page
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Intermediate
- Updated
- Oct 29, 2026
Related tutorials
Interview questions
Learning objectives#
- Model environments in a pipeline
- Promote one artifact through stages
- Add approvals and checks
- Keep configuration out of the artifact
Explanation#
Environments (dev, staging, production) have their own configuration, secrets and protection rules.
Promotion deploys the same artifact to staging, runs smoke tests, then to production after approval.
GitHub Environments support required reviewers, wait timers and environment-specific secrets.
Release notes can be generated from merged pull requests and tags.
Code example: Staging then production with approval#
name: release
on: { push: { tags: ['v*'] } }
jobs:
staging:
runs-on: ubuntu-latest
environment: staging
steps:
- run: ./deploy.sh staging ${{ github.ref_name }}
- run: curl --fail --retry 5 https://staging.techiebabaji.com/health
production:
needs: staging
runs-on: ubuntu-latest
environment: production # required reviewers configured in repo settings
steps:
- run: ./deploy.sh production ${{ github.ref_name }}
- run: gh release create ${{ github.ref_name }} --generate-notes
env: { GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} }
Pushing tag v1.4.0 deploys to staging, checks health, waits for an approver, deploys the same version to production and publishes release notes.
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- A version tag starts the release.
- Staging deploys and is smoke-tested.
- needs: makes production wait for staging.
- The production environment requires approval before running.
Real-world use case#
A bank-style process: every production release is approved, auditable and traceable to a tag.
Common mistakes#
Promote the exact artifact that passed staging.
Scope secrets to the production environment.
Best practices#
- Environment-scoped secrets
- Smoke tests after each deployment
- Approvals for production
- Automatic release notes
Remember this#
Same artifact: staging → production.
Environments hold config, secrets and approvals.
Smoke test before promoting.
Practice exercise#
Your task: How do you make job B run only after job A succeeds?
Show solution
b:
needs: a
Mini quiz#
Where are required reviewers for production configured in GitHub?
Want more? Practise all DevOps MCQs · DevOps interview questions
My notes#
Saved in this browser.