CI/CD Pipelines
GitHub Actions Workflow Structure
Workflow files live in .github/workflows/ and use YAML syntax:
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm test
- run: npm run build
Common Pipeline Stages
1. Lint
Run static analysis early to catch formatting and style issues fast:
- Python:
ruff check . or flake8, black --check ., mypy .
- JavaScript/TypeScript:
eslint ., prettier --check .
- Fail the pipeline on lint errors. Do not allow exceptions.
2. Test
- Run the full test suite. Use
--coverage flags to generate coverage reports.
- Upload coverage to a service like Codecov or Coveralls for tracking over time.
- Run unit tests first (fast feedback), then integration tests, then end-to-end tests.
3. Build
- Compile, bundle, or package the application.
- Store build artifacts using
actions/upload-artifact@v4 for use in later jobs.
- Verify the build output (e.g., check bundle size, run smoke tests against the build).
4. Deploy
- Deploy only from the main branch after all checks pass.
- Use environment-specific jobs with GitHub Environments for approval gates.
- Never deploy directly from feature branches to production.
Caching Strategies
Cache dependencies to speed up builds significantly:
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-npm-
- Cache package manager directories (
~/.npm, ~/.cache/pip, ~/.cargo).
- Use
hashFiles() on lock files to bust the cache when dependencies change.
- Cache Docker layers with
docker/build-push-action and GitHub Container Registry.
Secrets Management
- Store secrets in GitHub Actions Secrets (Settings > Secrets and Variables > Actions).
- Reference in workflows with
${{ secrets.MY_SECRET }}.
- Never print secrets to logs. Use
::add-mask:: to redact values if needed.
- Use OIDC tokens for cloud deployments (AWS, GCP, Azure) instead of long-lived credentials.
- Rotate secrets regularly and audit access.
Matrix Builds
Test across multiple environments in parallel:
strategy:
matrix:
node-version: [18, 20, 22]
os: [ubuntu-latest, macos-latest]
fail-fast: false
- Use
fail-fast: false to see all failures, not just the first.
- Use
include and exclude to fine-tune combinations.
Deployment Strategies
| Strategy |
Description |
Risk |
Rollback Speed |
| Blue/Green |
Run two identical environments; switch traffic at once |
Low |
Instant (switch back) |
| Canary |
Route a small percentage of traffic to new version |
Low |
Fast (route back) |
| Rolling |
Gradually replace instances one by one |
Medium |
Moderate |
| Recreate |
Stop all old instances, start new ones |
High (downtime) |
Slow |
- Use blue/green or canary for critical production services.
- Rolling updates work well for Kubernetes deployments.
- Always have a rollback plan documented and tested.
Status Checks and Branch Protection
Tips for Fast Pipelines
- Run independent jobs in parallel (lint, test, and build can often run simultaneously).
- Use
concurrency groups to cancel redundant runs when new commits are pushed.
- Split slow test suites across multiple runners with test sharding.
- Keep Docker images small: use multi-stage builds and alpine base images.
Source: SalesTeamToolbox/frood — distributed by TomeVault.
1---2name: ci-cd-153description: Configure and manage CI/CD pipelines — GitHub Actions, testing, building, deploying. Use when this capability is needed.4---56# CI/CD Pipelines78## GitHub Actions Workflow Structure910Workflow files live in `.github/workflows/` and use YAML syntax:1112```yaml13name: CI14on:15 push:16 branches: [main]17 pull_request:18 branches: [main]1920jobs:21 build:22 runs-on: ubuntu-latest23 steps:24 - uses: actions/checkout@v425 - uses: actions/setup-node@v426 with:27 node-version: '20'28 cache: 'npm'29 - run: npm ci30 - run: npm test31 - run: npm run build32```3334## Common Pipeline Stages3536### 1. Lint37Run static analysis early to catch formatting and style issues fast:38- **Python**: `ruff check .` or `flake8`, `black --check .`, `mypy .`39- **JavaScript/TypeScript**: `eslint .`, `prettier --check .`40- Fail the pipeline on lint errors. Do not allow exceptions.4142### 2. Test43- Run the full test suite. Use `--coverage` flags to generate coverage reports.44- Upload coverage to a service like Codecov or Coveralls for tracking over time.45- Run unit tests first (fast feedback), then integration tests, then end-to-end tests.4647### 3. Build48- Compile, bundle, or package the application.49- Store build artifacts using `actions/upload-artifact@v4` for use in later jobs.50- Verify the build output (e.g., check bundle size, run smoke tests against the build).5152### 4. Deploy53- Deploy only from the main branch after all checks pass.54- Use environment-specific jobs with GitHub Environments for approval gates.55- Never deploy directly from feature branches to production.5657## Caching Strategies5859Cache dependencies to speed up builds significantly:6061```yaml62- uses: actions/cache@v463 with:64 path: ~/.npm65 key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}66 restore-keys: |67 ${{ runner.os }}-npm-68```6970- Cache package manager directories (`~/.npm`, `~/.cache/pip`, `~/.cargo`).71- Use `hashFiles()` on lock files to bust the cache when dependencies change.72- Cache Docker layers with `docker/build-push-action` and GitHub Container Registry.7374## Secrets Management7576- Store secrets in **GitHub Actions Secrets** (Settings > Secrets and Variables > Actions).77- Reference in workflows with `${{ secrets.MY_SECRET }}`.78- Never print secrets to logs. Use `::add-mask::` to redact values if needed.79- Use OIDC tokens for cloud deployments (AWS, GCP, Azure) instead of long-lived credentials.80- Rotate secrets regularly and audit access.8182## Matrix Builds8384Test across multiple environments in parallel:8586```yaml87strategy:88 matrix:89 node-version: [18, 20, 22]90 os: [ubuntu-latest, macos-latest]91 fail-fast: false92```9394- Use `fail-fast: false` to see all failures, not just the first.95- Use `include` and `exclude` to fine-tune combinations.9697## Deployment Strategies9899| Strategy | Description | Risk | Rollback Speed |100|----------|-------------|------|----------------|101| **Blue/Green** | Run two identical environments; switch traffic at once | Low | Instant (switch back) |102| **Canary** | Route a small percentage of traffic to new version | Low | Fast (route back) |103| **Rolling** | Gradually replace instances one by one | Medium | Moderate |104| **Recreate** | Stop all old instances, start new ones | High (downtime) | Slow |105106- Use blue/green or canary for critical production services.107- Rolling updates work well for Kubernetes deployments.108- Always have a rollback plan documented and tested.109110## Status Checks and Branch Protection111112- Require all CI checks to pass before merging PRs.113- Configure branch protection rules on `main`: require reviews, status checks, and up-to-date branches.114- Add status badges to your README:115 ```markdown116 117 ```118119## Tips for Fast Pipelines120121- Run independent jobs in parallel (lint, test, and build can often run simultaneously).122- Use `concurrency` groups to cancel redundant runs when new commits are pushed.123- Split slow test suites across multiple runners with test sharding.124- Keep Docker images small: use multi-stage builds and alpine base images.125126---127> Source: [SalesTeamToolbox/frood](https://github.com/SalesTeamToolbox/frood) — distributed by [TomeVault](https://tomevault.io).128<!-- tomevault:4.0:skill_md:2026-06-15 -->