deployment-pipeline-design
关于
This Claude Skill helps developers design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use it when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices to create robust pipelines that balance speed and safety.
技能文档
Deployment Pipeline Design
Architecture patterns for multi-stage CI/CD pipelines with approval gates and deployment strategies.
Purpose
Design robust, secure deployment pipelines that balance speed with safety through proper stage organization and approval workflows.
When to Use
- Design CI/CD architecture
- Implement deployment gates
- Configure multi-environment pipelines
- Establish deployment best practices
- Implement progressive delivery
Pipeline Stages
Standard Pipeline Flow
┌─────────┐ ┌──────┐ ┌─────────┐ ┌────────┐ ┌──────────┐
│ Build │ → │ Test │ → │ Staging │ → │ Approve│ → │Production│
└─────────┘ └──────┘ └─────────┘ └────────┘ └──────────┘
Detailed Stage Breakdown
- Source - Code checkout
- Build - Compile, package, containerize
- Test - Unit, integration, security scans
- Staging Deploy - Deploy to staging environment
- Integration Tests - E2E, smoke tests
- Approval Gate - Manual approval required
- Production Deploy - Canary, blue-green, rolling
- Verification - Health checks, monitoring
- Rollback - Automated rollback on failure
Approval Gate Patterns
Pattern 1: Manual Approval
# GitHub Actions
production-deploy:
needs: staging-deploy
environment:
name: production
url: https://app.example.com
runs-on: ubuntu-latest
steps:
- name: Deploy to production
run: |
# Deployment commands
Pattern 2: Time-Based Approval
# GitLab CI
deploy:production:
stage: deploy
script:
- deploy.sh production
environment:
name: production
when: delayed
start_in: 30 minutes
only:
- main
Pattern 3: Multi-Approver
# Azure Pipelines
stages:
- stage: Production
dependsOn: Staging
jobs:
- deployment: Deploy
environment:
name: production
resourceType: Kubernetes
strategy:
runOnce:
preDeploy:
steps:
- task: ManualValidation@0
inputs:
notifyUsers: '[email protected]'
instructions: 'Review staging metrics before approving'
Reference: See assets/approval-gate-template.yml
Deployment Strategies
1. Rolling Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
Characteristics:
- Gradual rollout
- Zero downtime
- Easy rollback
- Best for most applications
2. Blue-Green Deployment
# Blue (current)
kubectl apply -f blue-deployment.yaml
kubectl label service my-app version=blue
# Green (new)
kubectl apply -f green-deployment.yaml
# Test green environment
kubectl label service my-app version=green
# Rollback if needed
kubectl label service my-app version=blue
Characteristics:
- Instant switchover
- Easy rollback
- Doubles infrastructure cost temporarily
- Good for high-risk deployments
3. Canary Deployment
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 5m}
- setWeight: 25
- pause: {duration: 5m}
- setWeight: 50
- pause: {duration: 5m}
- setWeight: 100
Characteristics:
- Gradual traffic shift
- Risk mitigation
- Real user testing
- Requires service mesh or similar
4. Feature Flags
from flagsmith import Flagsmith
flagsmith = Flagsmith(environment_key="API_KEY")
if flagsmith.has_feature("new_checkout_flow"):
# New code path
process_checkout_v2()
else:
# Existing code path
process_checkout_v1()
Characteristics:
- Deploy without releasing
- A/B testing
- Instant rollback
- Granular control
Pipeline Orchestration
Multi-Stage Pipeline Example
name: Production Pipeline
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build application
run: make build
- name: Build Docker image
run: docker build -t myapp:${{ github.sha }} .
- name: Push to registry
run: docker push myapp:${{ github.sha }}
test:
needs: build
runs-on: ubuntu-latest
steps:
- name: Unit tests
run: make test
- name: Security scan
run: trivy image myapp:${{ github.sha }}
deploy-staging:
needs: test
runs-on: ubuntu-latest
environment:
name: staging
steps:
- name: Deploy to staging
run: kubectl apply -f k8s/staging/
integration-test:
needs: deploy-staging
runs-on: ubuntu-latest
steps:
- name: Run E2E tests
run: npm run test:e2e
deploy-production:
needs: integration-test
runs-on: ubuntu-latest
environment:
name: production
steps:
- name: Canary deployment
run: |
kubectl apply -f k8s/production/
kubectl argo rollouts promote my-app
verify:
needs: deploy-production
runs-on: ubuntu-latest
steps:
- name: Health check
run: curl -f https://app.example.com/health
- name: Notify team
run: |
curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
-d '{"text":"Production deployment successful!"}'
Pipeline Best Practices
- Fail fast - Run quick tests first
- Parallel execution - Run independent jobs concurrently
- Caching - Cache dependencies between runs
- Artifact management - Store build artifacts
- Environment parity - Keep environments consistent
- Secrets management - Use secret stores (Vault, etc.)
- Deployment windows - Schedule deployments appropriately
- Monitoring integration - Track deployment metrics
- Rollback automation - Auto-rollback on failures
- Documentation - Document pipeline stages
Rollback Strategies
Automated Rollback
deploy-and-verify:
steps:
- name: Deploy new version
run: kubectl apply -f k8s/
- name: Wait for rollout
run: kubectl rollout status deployment/my-app
- name: Health check
id: health
run: |
for i in {1..10}; do
if curl -sf https://app.example.com/health; then
exit 0
fi
sleep 10
done
exit 1
- name: Rollback on failure
if: failure()
run: kubectl rollout undo deployment/my-app
Manual Rollback
# List revision history
kubectl rollout history deployment/my-app
# Rollback to previous version
kubectl rollout undo deployment/my-app
# Rollback to specific revision
kubectl rollout undo deployment/my-app --to-revision=3
Monitoring and Metrics
Key Pipeline Metrics
- Deployment Frequency - How often deployments occur
- Lead Time - Time from commit to production
- Change Failure Rate - Percentage of failed deployments
- Mean Time to Recovery (MTTR) - Time to recover from failure
- Pipeline Success Rate - Percentage of successful runs
- Average Pipeline Duration - Time to complete pipeline
Integration with Monitoring
- name: Post-deployment verification
run: |
# Wait for metrics stabilization
sleep 60
# Check error rate
ERROR_RATE=$(curl -s "$PROMETHEUS_URL/api/v1/query?query=rate(http_errors_total[5m])" | jq '.data.result[0].value[1]')
if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
echo "Error rate too high: $ERROR_RATE"
exit 1
fi
Reference Files
references/pipeline-orchestration.md- Complex pipeline patternsassets/approval-gate-template.yml- Approval workflow templates
Related Skills
github-actions-templates- For GitHub Actions implementationgitlab-ci-patterns- For GitLab CI implementationsecrets-management- For secrets handling
快速安装
/plugin add https://github.com/lifangda/claude-plugins/tree/main/deployment-pipeline-design在 Claude Code 中复制并粘贴此命令以安装该技能
GitHub 仓库
相关推荐技能
sglang
元SGLang是一个专为LLM设计的高性能推理框架,特别适用于需要结构化输出的场景。它通过RadixAttention前缀缓存技术,在处理JSON、正则表达式、工具调用等具有重复前缀的复杂工作流时,能实现极速生成。如果你正在构建智能体或多轮对话系统,并追求远超vLLM的推理性能,SGLang是理想选择。
langchain
元LangChain是一个用于构建LLM应用程序的框架,支持智能体、链和RAG应用开发。它提供多模型提供商支持、500+工具集成、记忆管理和向量检索等核心功能。开发者可用它快速构建聊天机器人、问答系统和自主代理,适用于从原型验证到生产部署的全流程。
project-structure
元这个Skill为开发者提供全面的项目目录结构设计指南和最佳实践。它涵盖了多种项目类型包括monorepo、前后端框架、库和扩展的标准组织结构。帮助团队创建可扩展、易维护的代码架构,特别适用于新项目设计、遗留项目迁移和团队规范制定。
issue-documentation
元该Skill为开发者提供标准化的issue文档模板和指南,适用于创建bug报告、GitHub/Linear/Jira问题等场景。它能系统化地记录问题状况、复现步骤、根本原因、解决方案和影响范围,确保团队沟通清晰高效。通过实施主流问题跟踪系统的最佳实践,帮助开发者生成结构完整的故障排除文档和事件报告。
