
deployment-pipeline
Deployment procedures and CI/CD pipeline configuration for Python/React projects. Use when deploying to staging or production, creating CI/CD pipelines with GitHub Actions, troubleshooting deployment failures, or planning rollbacks. Covers pipeline stages (build/test/staging/production), environment promotion, pre-deployment validation, health checks, canary deployment, rollback procedures, and GitHub Actions workflows. Does NOT cover Docker image building (use docker-best-practices) or incident response (use incident-response).
- Installs
- 57
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/hieutrtr/ai1-skills --skill deployment-pipeline- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads deployment-pipeline automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Deployment Pipeline
When to Use
Activate this skill when:
- Setting up or modifying CI/CD pipelines with GitHub Actions
- Deploying application changes to staging or production environments
- Planning environment promotion strategies (dev -> staging -> production)
- Implementing pre-deployment validation gates
- Configuring health checks and smoke tests for deployed services
- Planning or executing rollback procedures after a failed deployment
- Setting up canary or blue-green deployment strategies
- Troubleshooting deployment failures or pipeline errors
Output: Write deployment results to deployment-report.md with status, version deployed, health check results, and rollback instructions if needed.
Do NOT use this skill for:
- Building or optimizing Docker images (use
docker-best-practices) - Responding to production incidents (use
incident-response) - Setting up monitoring or alerting (use
monitoring-setup) - Infrastructure provisioning (Terraform, CloudFormation)
Instructions
Pipeline Stages Overview
Every deployment follows a strict four-stage pipeline. No stage may be skipped.
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│ BUILD │───>│ TEST │───>│ STAGING │───>│ PRODUCTION │
│ │ │ │ │ │ │ │
│ • Lint │ │ • Unit │ │ • Deploy │ │ • Canary 10% │
│ • Build │ │ • Integ │ │ • Smoke │ │ • Monitor │
│ • Image │ │ • E2E │ │ • QA │ │ • Full 100% │
└──────────┘ └──────────┘ └──────────┘ └──────────────┘
Gate: Gate: Gate: Gate:
Build pass Tests pass Smoke pass Health checks
No lint err Coverage ≥80% Manual approve Error rate <1%
Stage 1: Build
Build stage validates code quality and produces deployable artifacts.
Steps:
- Lint and format check -- Run
ruff checkandruff format --checkfor Python,eslintandprettier --checkfor React - Type check -- Run
mypyfor Python,tsc --noEmitfor TypeScript - Build artifacts -- Build Python wheel/sdist, build React production bundle
- Build Docker images -- Tag with git SHA and branch name
Gate criteria: All checks pass, images build successfully.
# GitHub Actions build stage
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Lint Python
run: ruff check src/ && ruff format --check src/
- name: Type check Python
run: mypy src/
- name: Build backend image
run: docker build -t app-backend:${{ github.sha }} -f Dockerfile.backend .
- name: Build frontend
run: npm ci && npm run build
- name: Build frontend image
run: docker build -t app-frontend:${{ github.sha }} -f Dockerfile.frontend .
Stage 2: Test
Run the full test suite. Never skip tests for "urgent" deployments.
Steps:
- Unit tests --
pytest tests/unit/ -v --cov=src --cov-report=xml - Integration tests --
pytest tests/integration/ -v(requires test database) - Frontend tests --
npm test -- --coverage - E2E tests --
npx playwright testagainst a test environment - Security scan --
pip-auditfor Python,npm auditfor Node
Gate criteria: All tests pass, coverage >= 80%, no critical vulnerabilities.
# GitHub Actions test stage
test:
needs: build
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_PASSWORD: testpass
ports: ['5432:5432']
redis:
image: redis:7-alpine
ports: ['6379:6379']
steps:
- uses: actions/checkout@v4
- name: Run unit tests
run: pytest tests/unit/ -v --cov=src --cov-report=xml
- name: Run integration tests
run: pytest tests/integration/ -v
env:
DATABASE_URL: postgresql://postgres:testpass@localhost:5432/testdb
- name: Check coverage threshold
run: coverage report --fail-under=80
Stage 3: Staging Deployment
Deploy to staging environment for validation before production.
Pre-deployment checklist:
- All tests pass in CI
- Database migrations tested with
scripts/migration-dry-run.sh - Environment variables verified for staging
- Feature flags configured appropriately
- Dependent services verified available
Steps:
- Run migration dry-run -- Validate Alembic migrations against staging DB clone
- Deploy to staging -- Push images, apply migrations, restart services
- Run smoke tests -- Execute
scripts/smoke-test.shagainst staging URL - Run health checks -- Execute
scripts/health-check.pyfor all endpoints - Manual QA -- Team verifies critical user flows
Gate criteria: Smoke tests pass, health checks green, QA sign-off.
Stage 4: Production Deployment
Production deployment uses canary strategy to minimize risk.
Canary deployment steps:
- Deploy canary (10% traffic) -- Route 10% of traffic to new version
- Monitor for 10 minutes -- Watch error rates, latency, resource usage
- Evaluate canary -- If error rate < 1% and p99 latency within 20% of baseline, proceed
- Ramp to 50% -- Increase traffic to 50%, monitor for 5 minutes
- Full rollout (100%) -- Complete the deployment
- Post-deployment smoke tests -- Run full smoke test suite
Canary Timeline:
0 min 10 min 15 min 20 min
|--------|--------|--------|
10% Check 50% 100%
Deploy Metrics Ramp Full
OK? Up Rollout
|
No -> Rollback immediately
Automatic rollback triggers:
- Error rate exceeds 5% during canary
- p99 latency increases by more than 50%
- Health check failures on canary instances
- Memory usage exceeds 90% threshold
Pre-Deployment Validation
Run these validations before any deployment. Use scripts/deploy.sh --validate-only for a dry run.
Backend validation:
# Verify migrations are consistent
alembic check
# Verify no pending migrations
alembic heads --verbose
# Test migration against staging clone
./skills/deployment-pipeline/scripts/migration-dry-run.sh \
--db-url "$STAGING_DB_URL" \
--output-dir ./deploy-validation/
# Verify all dependencies are pinned
pip-compile --dry-run requirements.in
Frontend validation:
# Verify build succeeds
npm run build
# Check bundle size limits
npx bundlesize
# Verify environment variables are set
node -e "const vars = ['REACT_APP_API_URL']; vars.forEach(v => { if(!process.env[v]) throw new Error(v + ' not set') })"
Environment Promotion
Strict rules govern how changes move between environments.
| Aspect | Development | Staging | Production |
|---|---|---|---|
| Deploy trigger | Push to main | Manual or auto after tests | Manual approval required |
| Database | Local PostgreSQL | Staging PostgreSQL | Production PostgreSQL (RDS) |
| Secrets | .env file | GitHub Secrets | AWS Secrets Manager |
| Log level | DEBUG | INFO | WARNING |
| Feature flags | All enabled | Per-feature | Gradual rollout |
| SSL | Self-signed | ACM cert | ACM cert |
| Replicas | 1 | 2 | 3+ (auto-scaled) |
Promotion rules:
- Code must pass ALL gates in the previous stage
- Database migrations must be backward-compatible (no column drops without migration window)
- Environment variables must be configured BEFORE deployment
- Feature flags must be set to correct state BEFORE deployment
- Rollback plan must be documented BEFORE production deployment
Health Checks
Every service exposes health check endpoints. The deployment pipeline validates these after every deployment.
Required health check endpoints:
# FastAPI health check endpoints
@router.get("/health")
async def health():
"""Basic liveness check -- returns 200 if process is running."""
return {"status": "healthy", "timestamp": datetime.utcnow().isoformat()}
@router.get("/health/ready")
async def readiness(db: AsyncSession = Depends(get_db)):
"""Readiness check -- verifies all dependencies are accessible."""
checks = {}
# Database
try:
await db.execute(text("SELECT 1"))
checks["database"] = "ok"
except Exception as e:
checks["database"] = f"error: {str(e)}"
# Redis
try:
await redis.ping()
checks["redis"] = "ok"
except Exception as e:
checks["redis"] = f"error: {str(e)}"
all_ok = all(v == "ok" for v in checks.values())
return JSONResponse(
status_code=200 if all_ok else 503,
content={"status": "ready" if all_ok else "not_ready", "checks": checks}
)
Health check strategy during deployment:
After deploy:
Wait 10s -> Check /health (liveness)
Wait 5s -> Check /health/ready (readiness)
Wait 5s -> Check /health/ready again (stability)
All pass -> Deployment successful
Any fail -> Trigger rollback
Use scripts/health-check.py for automated health validation:
python scripts/health-check.py \
--url https://staging.example.com \
--retries 3 \
--timeout 30 \
--output-dir ./health-results/
Rollback Procedure
When a deployment fails, follow this rollback procedure immediately. See references/rollback-runbook.md for the full step-by-step guide.
Automated rollback (preferred):
# Roll back to previous version
./skills/deployment-pipeline/scripts/deploy.sh \
--rollback \
--version "$PREVIOUS_VERSION" \
--output-dir ./rollback-results/
Rollback decision matrix:
| Signal | Action | Timeline |
|---|---|---|
| Error rate > 5% | Automatic rollback | Immediate |
| p99 latency > 2x baseline | Automatic rollback | Immediate |
| Health check failures | Automatic rollback | After 2 retries |
| User-reported issues | Manual rollback decision | Within 15 minutes |
| Data inconsistency | Stop traffic, investigate | Immediate |
Database rollback considerations:
- Forward-only migrations are preferred; avoid
alembic downgradein production - If migration must be reversed, use a new forward migration to undo changes
- Never drop columns or tables in the same release that removes code references
- Use a two-phase approach: Phase 1 deploys new code (backward compatible), Phase 2 removes old columns
GitHub Actions CI/CD
The full CI/CD pipeline is defined in .github/workflows/deploy.yml. See references/github-actions-template.yml for the complete template.
Key workflow features:
- Matrix testing -- Test against Python 3.12 and 3.13
- Caching -- Cache pip, npm, and Docker layers for faster builds
- Concurrency -- Cancel in-progress deployments when new commits arrive
- Environment protection -- Require manual approval for production
- Secrets management -- Use GitHub environment secrets per stage
# Key sections of the workflow
on:
push:
branches: [main]
workflow_dispatch:
inputs:
environment:
type: choice
options: [staging, production]
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: true
jobs:
build: # Stage 1
test: # Stage 2 (needs: build)
staging: # Stage 3 (needs: test)
production: # Stage 4 (needs: staging, manual approval)
Canary Deployment
Canary deployment routes a small percentage of traffic to the new version before full rollout.
Implementation with Docker and Nginx:
# nginx canary configuration
upstream backend {
server backend-stable:8000 weight=9; # 90% to stable
server backend-canary:8000 weight=1; # 10% to canary
}
Canary evaluation criteria:
# Canary health evaluation
def evaluate_canary(metrics: dict) -> bool:
"""Return True if canary is healthy enough to proceed."""
checks = [
metrics["error_rate"] < 0.01, # < 1% error rate
metrics["p99_latency_ms"] < 500, # p99 under 500ms
metrics["memory_usage_pct"] < 85, # Memory under 85%
metrics["cpu_usage_pct"] < 75, # CPU under 75%
metrics["successful_health_checks"] >= 3, # 3+ consecutive passes
]
return all(checks)
Canary monitoring checklist:
- Error rate compared to baseline (must be within 1%)
- Latency percentiles (p50, p95, p99) compared to baseline
- Resource utilization (CPU, memory) within thresholds
- No increase in log error volume
- Health check endpoints responding correctly
- No degradation in dependent service metrics
Deployment Scripts
The following scripts automate deployment tasks:
| Script | Purpose | Usage |
|---|---|---|
scripts/deploy.sh | Main deployment orchestration | ./scripts/deploy.sh --env staging --output-dir ./results/ |
scripts/smoke-test.sh | Post-deployment smoke tests | ./scripts/smoke-test.sh --url https://staging.example.com --output-dir ./results/ |
scripts/health-check.py | Health endpoint validation | python scripts/health-check.py --url https://staging.example.com --output-dir ./results/ |
scripts/migration-dry-run.sh | Test migrations safely | ./scripts/migration-dry-run.sh --db-url $DB_URL --output-dir ./results/ |
Quick Reference
Deploy to staging:
./skills/deployment-pipeline/scripts/deploy.sh \
--env staging \
--version $(git rev-parse --short HEAD) \
--output-dir ./deploy-results/
Deploy to production (with canary):
./skills/deployment-pipeline/scripts/deploy.sh \
--env production \
--version $(git rev-parse --short HEAD) \
--canary \
--output-dir ./deploy-results/
Run smoke tests:
./skills/deployment-pipeline/scripts/smoke-test.sh \
--url https://staging.example.com \
--output-dir ./smoke-results/
Emergency rollback:
./skills/deployment-pipeline/scripts/deploy.sh \
--rollback \
--env production \
--version $PREVIOUS_SHA \
--output-dir ./rollback-results/
Output File
Write deployment results to deployment-report.md:
# Deployment Report
## Summary
- **Environment:** staging | production
- **Version:** abc1234 (git SHA)
- **Status:** SUCCESS | FAILED | ROLLED_BACK
- **Timestamp:** 2024-01-15T14:30:00Z
- **Duration:** 12 minutes
## Pipeline Stages
| Stage | Status | Duration | Notes |
|-------|--------|----------|-------|
| Build | PASS | 3m | Image built: app:abc1234 |
| Test | PASS | 5m | 142 tests, 85% coverage |
| Staging | PASS | 2m | Smoke tests passed |
| Production | PASS | 2m | Canary 10% → 50% → 100% |
## Health Checks
- `/health` — 200 OK (12ms)
- `/health/ready` — 200 OK (45ms)
## Rollback Instructions
If issues occur, run:
\`\`\`bash
./scripts/deploy.sh --rollback --env production --version $PREV_SHA
\`\`\`
Previous version: def5678
## Next Steps
- Run `/monitoring-setup` to verify alerts are configured
- Run `/incident-response` if errors occur
FAQ
What does the deployment-pipeline skill do?
Deployment procedures and CI/CD pipeline configuration for Python/React projects. Use when deploying to staging or production, creating CI/CD pipelines with GitHub Actions, troubleshooting deployment failures, or planning rollbacks. Covers pipeline stages (build/test/staging/production), environment promotion, pre-deployment validation, health checks, canary deployment, rollback procedures, and GitHub Actions workflows. Does NOT cover Docker image building (use docker-best-practices) or incident response (use incident-response).
How do I install deployment-pipeline?
Run npx skills add https://github.com/hieutrtr/ai1-skills --skill deployment-pipeline in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/deployment-pipeline/ (personal) or .claude/skills/deployment-pipeline/ (project).
Which AI agents can use deployment-pipeline?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is deployment-pipeline safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains deployment-pipeline?
It is published by hieutrtr in hieutrtr/ai1-skills. It has 57 recorded installs.
More from hieutrtr/ai1-skills
e2e-testing
hieutrtr/ai1-skills
End-to-end testing patterns with Playwright for full-stack Python/React applications. Use when writing E2E tests for complete user workflows (login, CRUD, navigation), critical path regression tests, or cross-browser validation. Covers test structure, page object model, selector strategy (data-testid role label), wait strategies, auth state reuse, test data management, and CI integration. Does NOT cover unit tests or component tests (use pytest-patterns or react-testing-patterns).
code-review-security
hieutrtr/ai1-skills
Security-focused code review checklist and automated scanning patterns. Use when reviewing pull requests for security issues, auditing authentication/authorization code, checking for OWASP Top 10 vulnerabilities, or validating input sanitization. Covers SQL injection prevention, XSS protection, CSRF tokens, authentication flow review, secrets detection, dependency vulnerability scanning, and secure coding patterns for Python (FastAPI) and React. Does NOT cover deployment security (use docker-best-practices) or incident handling (use incident-response).
react-frontend-expert
hieutrtr/ai1-skills
React/TypeScript frontend implementation patterns. Use during the implementation phase when creating or modifying React components, custom hooks, pages, data fetching logic with TanStack Query, forms, or routing. Covers component structure, hooks rules, custom hook design (useAuth, useDebounce, usePagination), TypeScript strict-mode conventions, form handling, accessibility requirements, and project structure. Does NOT cover testing (use react-testing-patterns), E2E testing (use e2e-testing), or deployment.
react-testing-patterns
hieutrtr/ai1-skills
Open the skill to read its SKILL.md instructions.
python-backend-expert
hieutrtr/ai1-skills
Open the skill to read its SKILL.md instructions.
pytest-patterns
hieutrtr/ai1-skills
Python backend testing patterns with pytest for FastAPI applications. Use when writing Python tests: unit tests for services and repositories, integration tests for API endpoints with httpx.AsyncClient, fixture creation, factory setup with factoryboy, async testing with pytest-asyncio, mocking strategies, and parametrized tests. Covers test organization (tests/unit, tests/integration), conftest hierarchy, and coverage requirements. Does NOT cover frontend tests (use react-testing-patterns) or E2E browser tests (use e2e-testing).
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.