CI/CD Pipeline Integration
Build continuous integration and deployment pipelines.
CI/CD is how teams ship changes safely at speed. CI (continuous integration) verifies changes (build, test, lint). CD (continuous delivery/deployment) promotes verified artifacts into environments (staging โ production).
GitHub Actions Example
A good pipeline is deterministic (same inputs โ same outputs), fast enough to run on every PR, and strict about quality gates.
name: CI/CD Pipeline
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: npm ci && npm run build
- name: Test
run: npm test
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: npm ci && npm run build
- name: Test
run: npm test
Pipeline stages (common pattern)
- Validate: lint, typecheck, unit tests
- Build: produce an artifact (container image, static site, binary)
- Security: dependency scanning, secret scanning, image scanning
- Deploy: staging first, then production with approvals
- Observe: monitor metrics/logs and support fast rollback
Key ideas that keep production safe
- โขQuality gates: block merges if tests/lint fail
- โขArtifact immutability: build once, deploy the same artifact everywhere
- โขSecrets management: use CI secrets; never commit keys in repo
- โขRollbacks: make rollback a first-class action, not a panic response
CI/CD Best Practices
- โ Automate testing on every commit
- โ Use environment-specific configurations
- โ Implement blue-green or canary deployments
- โ Monitor deployments with rollback capabilities
โ Practice (30 minutes)
- Add lint + tests to your pipeline and make them required for merges.
- Add a staging deploy step that only runs on
mainafter successful tests. - Define a rollback plan (what command do you run? what do you verify?) before you need it.