DevOps · CI/CD

Release Pipelines

The release pipeline takes a tested artifact and moves it safely through environments to production.

Intermediate 5 min Lesson 11 of 30
Before you start:Build Pipelines
0/30 in DevOps
On this page · 5 min · Intermediate

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#

YAML.github/workflows/release.yml Illustrative
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 }} }
Expected output
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#

  1. A version tag starts the release.
  2. Staging deploys and is smoke-tested.
  3. needs: makes production wait for staging.
  4. 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#

Different artifacts per environment

Promote the exact artifact that passed staging.

Production secrets available to every job

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
YAML Illustrative
b:
  needs: a

Mini quiz#

Release Pipelines quizMultiple choice Question 1 of 1

Where are required reviewers for production configured in GitHub?

Score so far: 0/0

Want more? Practise all DevOps MCQs · DevOps interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.