Back to Details

deployment-pipeline

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deployment Pipeline

部署流水线（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)
在以下场景中启用此技能：
  • 使用GitHub Actions搭建或修改CI/CD流水线
  • 将应用变更部署到staging（预发布）或production（生产）环境
  • 规划环境升级策略（dev → staging → production）
  • 部署前验证关卡的实施
  • 为已部署服务配置健康检查与冒烟测试
  • 部署失败后规划或执行回滚流程
  • 搭建金丝雀（Canary）或蓝绿部署策略
  • 排查部署故障或流水线错误
输出要求： 将部署结果写入
deployment-report.md
，内容包含部署状态、已部署版本、健康检查结果，以及必要时的回滚说明。
以下场景请勿使用此技能：
  • Docker镜像的构建或优化（请使用
    docker-best-practices
    ）
  • 生产事件响应（请使用
    incident-response
    ）
  • 监控或告警配置（请使用
    monitoring-setup
    ）
  • 基础设施配置（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%
所有部署均遵循严格的四阶段流水线，不得跳过任何阶段。
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────────┐
│  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

阶段1：构建（Build）

Build stage validates code quality and produces deployable artifacts.
Steps:
  1. Lint and format check -- Run 
    ruff check
    and 
    ruff format --check
    for Python, 
    eslint
    and 
    prettier --check
    for React
  2. Type check -- Run 
    mypy
    for Python, 
    tsc --noEmit
    for TypeScript
  3. Build artifacts -- Build Python wheel/sdist, build React production bundle
  4. Build Docker images -- Tag with git SHA and branch name
Gate criteria: All checks pass, images build successfully.
yaml
undefined
构建阶段用于验证代码质量并生成可部署的制品。
步骤：
  1. 代码检查与格式校验 -- Python项目执行
    ruff check
    和
    ruff format --check
    ，React项目执行
    eslint
    和
    prettier --check
  2. 类型检查 -- Python项目执行
    mypy
    ，TypeScript项目执行
    tsc --noEmit
  3. 生成制品 -- 构建Python wheel/sdist包，构建React生产环境打包文件
  4. 构建Docker镜像 -- 使用Git SHA和分支名称打标签
关卡要求： 所有检查通过，镜像构建成功。
yaml
undefined

GitHub Actions build stage

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 .
undefined
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 .
undefined

Stage 2: Test

阶段2：测试（Test）

Run the full test suite. Never skip tests for "urgent" deployments.
Steps:
  1. Unit tests -- 
    pytest tests/unit/ -v --cov=src --cov-report=xml
  2. Integration tests -- 
    pytest tests/integration/ -v
    (requires test database)
  3. Frontend tests -- 
    npm test -- --coverage
  4. E2E tests -- 
    npx playwright test
    against a test environment
  5. Security scan -- 
    pip-audit
    for Python, 
    npm audit
    for Node
Gate criteria: All tests pass, coverage >= 80%, no critical vulnerabilities.
yaml
undefined
执行完整测试套件，请勿因“紧急”部署而跳过测试。
步骤：
  1. 单元测试 -- 执行
    pytest tests/unit/ -v --cov=src --cov-report=xml
  2. 集成测试 -- 执行
    pytest tests/integration/ -v
    （需要测试数据库）
  3. 前端测试 -- 执行
    npm test -- --coverage
  4. 端到端（E2E）测试 -- 在测试环境中执行
    npx playwright test
  5. 安全扫描 -- Python项目执行
    pip-audit
    ，Node项目执行
    npm audit
关卡要求： 所有测试通过，代码覆盖率≥80%，无严重漏洞。
yaml
undefined

GitHub Actions test stage

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
undefined
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
undefined

Stage 3: Staging Deployment

阶段3：预发布环境（Staging）部署

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:
  1. Run migration dry-run -- Validate Alembic migrations against staging DB clone
  2. Deploy to staging -- Push images, apply migrations, restart services
  3. Run smoke tests -- Execute 
    scripts/smoke-test.sh
    against staging URL
  4. Run health checks -- Execute 
    scripts/health-check.py
    for all endpoints
  5. Manual QA -- Team verifies critical user flows
Gate criteria: Smoke tests pass, health checks green, QA sign-off.
部署到staging环境进行验证，之后再部署到生产环境。
部署前检查清单：
  • CI中所有测试通过
  • 已使用
    scripts/migration-dry-run.sh
    测试数据库迁移
  • 已验证staging环境的环境变量
  • 已正确配置功能开关（Feature flags）
  • 已验证依赖服务可用
步骤：
  1. 执行迁移预演 -- 针对staging数据库克隆验证Alembic迁移
  2. 部署到staging -- 推送镜像、执行迁移、重启服务
  3. 执行冒烟测试 -- 针对staging URL执行
    scripts/smoke-test.sh
  4. 执行健康检查 -- 对所有端点执行
    scripts/health-check.py
  5. 人工QA -- 团队验证核心用户流程
关卡要求： 冒烟测试通过，健康检查结果正常，QA签字确认。

Stage 4: Production Deployment

阶段4：生产环境（Production）部署

Production deployment uses canary strategy to minimize risk.
Canary deployment steps:
  1. Deploy canary (10% traffic) -- Route 10% of traffic to new version
  2. Monitor for 10 minutes -- Watch error rates, latency, resource usage
  3. Evaluate canary -- If error rate < 1% and p99 latency within 20% of baseline, proceed
  4. Ramp to 50% -- Increase traffic to 50%, monitor for 5 minutes
  5. Full rollout (100%) -- Complete the deployment
  6. 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
生产环境部署采用金丝雀（Canary）策略以降低风险。
金丝雀部署（Canary deployment）步骤：
  1. 部署金丝雀版本（10%流量） -- 将10%的流量路由到新版本
  2. 监控10分钟 -- 观察错误率、延迟、资源使用率
  3. 评估金丝雀版本 -- 若错误率<1%且p99延迟在基准值的20%范围内，则继续
  4. 扩容至50%流量 -- 将流量提升至50%，监控5分钟
  5. 全量发布（100%流量） -- 完成部署
  6. 部署后冒烟测试 -- 执行完整冒烟测试套件
Canary Timeline:
  0 min    10 min   15 min   20 min
  |--------|--------|--------|
  10%      Check    50%      100%
  Deploy   Metrics  Ramp     Full
           OK?      Up       Rollout
           |
           No -> Rollback immediately
自动回滚触发条件：
  • 金丝雀版本错误率超过5%
  • p99延迟增加超过50%
  • 金丝雀实例健康检查失败
  • 内存使用率超过90%阈值

Pre-Deployment Validation

部署前验证

Run these validations before any deployment. Use 
scripts/deploy.sh --validate-only
for a dry run.
Backend validation:
bash
undefined
任何部署前都需执行以下验证。使用
scripts/deploy.sh --validate-only
进行预演。
后端验证：
bash
undefined

Verify migrations are consistent

Verify migrations are consistent

alembic check
alembic check

Verify no pending migrations

Verify no pending migrations

alembic heads --verbose
alembic heads --verbose

Test migration against staging clone

Test migration against staging clone

./skills/deployment-pipeline/scripts/migration-dry-run.sh
--db-url "$STAGING_DB_URL"
--output-dir ./deploy-validation/
./skills/deployment-pipeline/scripts/migration-dry-run.sh
--db-url "$STAGING_DB_URL"
--output-dir ./deploy-validation/

Verify all dependencies are pinned

Verify all dependencies are pinned

pip-compile --dry-run requirements.in

**Frontend validation:**
```bash
pip-compile --dry-run requirements.in

**前端验证：**
```bash

Verify build succeeds

Verify build succeeds

npm run build
npm run build

Check bundle size limits

Check bundle size limits

npx bundlesize
npx bundlesize

Verify environment variables are set

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') })"
undefined
node -e "const vars = ['REACT_APP_API_URL']; vars.forEach(v => { if(!process.env[v]) throw new Error(v + ' not set') })"
undefined

Environment Promotion

环境升级

Strict rules govern how changes move between environments.
AspectDevelopmentStagingProduction
Deploy triggerPush to 
main
Manual or auto after testsManual approval required
DatabaseLocal PostgreSQLStaging PostgreSQLProduction PostgreSQL (RDS)
Secrets
.env
file		GitHub SecretsAWS Secrets Manager
Log levelDEBUGINFOWARNING
Feature flagsAll enabledPer-featureGradual rollout
SSLSelf-signedACM certACM cert
Replicas123+ (auto-scaled)
Promotion rules:
  1. Code must pass ALL gates in the previous stage
  2. Database migrations must be backward-compatible (no column drops without migration window)
  3. Environment variables must be configured BEFORE deployment
  4. Feature flags must be set to correct state BEFORE deployment
  5. Rollback plan must be documented BEFORE production deployment
变更在各环境间的流转遵循严格规则。
维度开发环境（Development）预发布环境（Staging）生产环境（Production）
部署触发条件推送到
main
分支		测试通过后手动或自动触发需要手动审批
数据库本地PostgreSQLStaging PostgreSQL生产PostgreSQL（RDS）
密钥管理
.env
文件		GitHub SecretsAWS Secrets Manager
日志级别DEBUGINFOWARNING
功能开关全部启用按功能配置逐步发布
SSL证书自签名证书ACM证书ACM证书
副本数123+（自动扩缩容）
升级规则：
  1. 代码必须通过上一阶段的所有关卡
  2. 数据库迁移必须向后兼容（无迁移窗口期时不得删除列）
  3. 必须在部署前配置好环境变量
  4. 必须在部署前将功能开关设置为正确状态
  5. 必须在生产环境部署前记录回滚计划

Health Checks

健康检查

Every service exposes health check endpoints. The deployment pipeline validates these after every deployment.
Required health check endpoints:
python
undefined
每个服务都需暴露健康检查端点。部署流水线会在每次部署后验证这些端点。
必填健康检查端点：
python
undefined

FastAPI 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:
```bash
python scripts/health-check.py \
  --url https://staging.example.com \
  --retries 3 \
  --timeout 30 \
  --output-dir ./health-results/
@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}
)

**部署期间的健康检查策略：**
部署完成后： 等待10秒 → 检查/health（存活状态） 等待5秒 → 检查/health/ready（就绪状态） 等待5秒 → 再次检查/health/ready（稳定性） 全部通过 → 部署成功 任意失败 → 触发回滚

使用`scripts/health-check.py`进行自动化健康验证：
```bash
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):
bash
undefined
当部署失败时，请立即遵循以下回滚流程。完整的分步指南请参阅
references/rollback-runbook.md
。
自动回滚（推荐方式）：
bash
undefined

Roll back to previous version

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 downgrade` in 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
./skills/deployment-pipeline/scripts/deploy.sh
--rollback
--version "$PREVIOUS_VERSION"
--output-dir ./rollback-results/

**回滚决策矩阵：**

| 信号 | 操作 | 时间要求 |
|------|------|----------|
| 错误率>5% | 自动回滚 | 立即执行 |
| p99延迟>基准值2倍 | 自动回滚 | 立即执行 |
| 健康检查失败 | 自动回滚 | 重试2次后执行 |
| 用户反馈问题 | 人工决策是否回滚 | 15分钟内完成决策 |
| 数据不一致 | 停止流量，排查问题 | 立即执行 |

**数据库回滚注意事项：**
- 优先使用仅向前的迁移；生产环境中避免使用`alembic downgrade`
- 若必须回滚迁移，请使用新的向前迁移来撤销变更
- 切勿在移除代码引用的同一版本中删除列或表
- 采用两阶段方式：第一阶段部署新代码（向后兼容），第二阶段移除旧列

GitHub Actions CI/CD

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
yaml
undefined
完整的CI/CD流水线定义在
.github/workflows/deploy.yml
中。完整模板请参阅
references/github-actions-template.yml
。
工作流核心特性：
  • 矩阵测试 -- 针对Python 3.12和3.13版本进行测试
  • 缓存 -- 缓存pip、npm和Docker层以加快构建速度
  • 并发控制 -- 有新提交时取消正在进行的部署
  • 环境保护 -- 生产环境部署需要手动审批
  • 密钥管理 -- 为每个阶段使用GitHub环境密钥
yaml
undefined

Key sections of the workflow

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)
undefined
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)
undefined

Canary Deployment

金丝雀部署（Canary Deployment）

Canary deployment routes a small percentage of traffic to the new version before full rollout.
Implementation with Docker and Nginx:
nginx
undefined
金丝雀部署会在全量发布前将小部分流量路由到新版本。
基于Docker与Nginx的实现：
nginx
undefined

nginx canary configuration

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:**

```python
upstream backend { server backend-stable:8000 weight=9; # 90% to stable server backend-canary:8000 weight=1; # 10% to canary }

**金丝雀版本评估标准：**

```python

Canary health evaluation

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
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)

**金丝雀版本监控检查清单：**
- [ ] 错误率与基准值对比（差异需在1%以内）
- [ ] 延迟百分位数（p50、p95、p99）与基准值对比
- [ ] 资源使用率（CPU、内存）在阈值范围内
- [ ] 日志错误量未增加
- [ ] 健康检查端点响应正常
- [ ] 依赖服务指标未出现下降

Deployment Scripts

部署脚本

The following scripts automate deployment tasks:
ScriptPurposeUsage
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/
以下脚本可自动化部署任务：
脚本用途使用示例
scripts/deploy.sh
主部署编排脚本
./scripts/deploy.sh --env staging --output-dir ./results/
scripts/smoke-test.sh
部署后冒烟测试脚本
./scripts/smoke-test.sh --url https://staging.example.com --output-dir ./results/
scripts/health-check.py
健康端点验证脚本
python scripts/health-check.py --url https://staging.example.com --output-dir ./results/
scripts/migration-dry-run.sh
安全测试迁移脚本
./scripts/migration-dry-run.sh --db-url $DB_URL --output-dir ./results/

Quick Reference

快速参考

Deploy to staging:
bash
./skills/deployment-pipeline/scripts/deploy.sh \
  --env staging \
  --version $(git rev-parse --short HEAD) \
  --output-dir ./deploy-results/
Deploy to production (with canary):
bash
./skills/deployment-pipeline/scripts/deploy.sh \
  --env production \
  --version $(git rev-parse --short HEAD) \
  --canary \
  --output-dir ./deploy-results/
Run smoke tests:
bash
./skills/deployment-pipeline/scripts/smoke-test.sh \
  --url https://staging.example.com \
  --output-dir ./smoke-results/
Emergency rollback:
bash
./skills/deployment-pipeline/scripts/deploy.sh \
  --rollback \
  --env production \
  --version $PREVIOUS_SHA \
  --output-dir ./rollback-results/
部署到staging环境：
bash
./skills/deployment-pipeline/scripts/deploy.sh \
  --env staging \
  --version $(git rev-parse --short HEAD) \
  --output-dir ./deploy-results/
部署到生产环境（使用金丝雀策略）：
bash
./skills/deployment-pipeline/scripts/deploy.sh \
  --env production \
  --version $(git rev-parse --short HEAD) \
  --canary \
  --output-dir ./deploy-results/
执行冒烟测试：
bash
./skills/deployment-pipeline/scripts/smoke-test.sh \
  --url https://staging.example.com \
  --output-dir ./smoke-results/
紧急回滚：
bash
./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
:
markdown
undefined
将部署结果写入
deployment-report.md
：
markdown
undefined

Deployment Report

部署报告（Deployment Report）

Summary

摘要

  • Environment: staging | production
  • Version: abc1234 (git SHA)
  • Status: SUCCESS | FAILED | ROLLED_BACK
  • Timestamp: 2024-01-15T14:30:00Z
  • Duration: 12 minutes
  • 环境： staging | production
  • 版本： abc1234（Git SHA）
  • 状态： SUCCESS | FAILED | ROLLED_BACK
  • 时间戳： 2024-01-15T14:30:00Z
  • 耗时： 12分钟

Pipeline Stages

流水线阶段

StageStatusDurationNotes
BuildPASS3mImage built: app:abc1234
TestPASS5m142 tests, 85% coverage
StagingPASS2mSmoke tests passed
ProductionPASS2mCanary 10% → 50% → 100%
阶段状态耗时备注
BuildPASS3分钟镜像已构建：app:abc1234
TestPASS5分钟142个测试，覆盖率85%
StagingPASS2分钟冒烟测试通过
ProductionPASS2分钟金丝雀版本10% → 50% → 100%

Health Checks

健康检查结果

  • /health
    — 200 OK (12ms)
  • /health/ready
    — 200 OK (45ms)
  • /health
    — 200 OK（12毫秒）
  • /health/ready
    — 200 OK（45毫秒）

Rollback Instructions

回滚说明

If issues occur, run: ```bash ./scripts/deploy.sh --rollback --env production --version $PREV_SHA ```
Previous version: def5678
若出现问题，请执行：
bash
./scripts/deploy.sh --rollback --env production --version $PREV_SHA
上一版本：def5678

Next Steps

后续步骤

  • Run 
    /monitoring-setup
    to verify alerts are configured
  • Run 
    /incident-response
    if errors occur
undefined
  • 执行
    /monitoring-setup
    以验证告警配置
  • 若出现错误，请执行
    /incident-response
undefined