技能介绍
先看中文介绍;官方 description 原文单独保留,不改写 SKILL.md。
做什么
CI/CD 建立跨平台的自动化管道、部署战略、测试和DevOps工作流程的最佳做法
何时用
官方 description 未单独写出 Use when。按规范,代理会在用户任务与这段 description 的关键词匹配时激活本技能。
代理如何加载
按 Agent Skills 渐进披露:启动时只加载 name 与 description(约 100 token);任务匹配后才读入整份 SKILL.md 正文;scripts/、references/、assets/ 仅在需要时再读。 本文件正文结构:CI/CD Best Practices、Core Principles、Pipeline Design、Pipeline Stages、Deployment Strategies、Blue-Green Deployment。
文件分析
文件分析:这是一份仅含 SKILL.md 的指令型技能,代理激活后整份正文进入上下文。 正文约 510 行,超过规范建议的 500 行,激活时仍会整份载入。
官方 description(原文)
CI/CD best practices for building automated pipelines, deployment strategies, testing, and DevOps workflows across platforms
CI/CD Best PracticesCore PrinciplesPipeline DesignPipeline StagesDeployment StrategiesBlue-Green DeploymentCanary DeploymentRolling DeploymentFeature FlagsEnvironment ManagementEnvironment HierarchyEnvironment Variables
来源分类:skills.sh agent-skill
来源与网址
nameci-cd-best-practices
description- CI/CD best practices for building automated pipelines, deployment strategies, testing, and DevOps workflows across platforms
- 发现技能客户端向 Agent 提供名称与描述目录。
- 匹配与调用用户指定或任务匹配后,载入 SKILL.md 指令。
- 按需加载按步骤读取参考文档、使用脚本与素材。
具体调用语法与可用工具以目标 Agent 客户端为准。 查看调用机制说明 ↗
先选择目标 Agent 和安装范围,保留技能包的附属文件,安装后检查客户端能否发现该技能。
交给 Agent 安装
复制安装指令给支持 Agent Skills 的代理,确认其中的目标目录与客户端匹配。
把 Agent Skill「ci-cd-best-practices」安装到我的项目:SKILL.md 原文与官方 description 见 https://zicq.com/zh/skills/skl-c228f68551340195-Ci-Cd-Best-Practices.html
请存为 .cursor/skills/ci-cd-best-practices/SKILL.md 或 .claude/skills/ci-cd-best-practices/SKILL.md,frontmatter 的 name 与 description 保持原样,不要改写。
GitHub 完整包 ↗
终端安装 · Skills CLI
需要 Node.js 与 npx。先查看仓库技能列表,确认实际名称。
npx skills add 'https://github.com/mindrally/skills' --list
npx skills add 'https://github.com/mindrally/skills' --skill 'ci-cd-best-practices'
CLI 会交互选择目标 Agent,默认安装到项目;用户级安装使用 -g。先通过查看命令核对仓库内容,再用 npx skills list 检查已安装技能。
阅读排版
---
name: ci-cd-best-practices
description: CI/CD best practices for building automated pipelines, deployment strategies, testing, and DevOps workflows across platforms
---
# CI/CD Best Practices
You are an expert in Continuous Integration and Continuous Deployment, following industry best practices for automated pipelines, testing strategies, deployment patterns, and DevOps workflows.
## Core Principles
- Automate everything that can be automated
- Fail fast with quick feedback loops
- Build once, deploy many times
- Implement infrastructure as code
- Practice continuous improvement
- Maintain security at every stage
## Pipeline Design
### Pipeline Stages
A typical CI/CD pipeline includes these stages:
```
Build -> Test -> Security -> Deploy (Staging) -> Deploy (Production)
```
#### 1. Build Stage
```yaml
build:
stage: build
script:
- npm ci --prefer-offline
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 day
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
```
Best practices:
- Use dependency caching to speed up builds
- Generate build artifacts for downstream stages
- Pin dependency versions for reproducibility
- Use multi-stage Docker builds for smaller images
#### 2. Test Stage
```yaml
test:
stage: test
parallel:
matrix:
- TEST_TYPE: [unit, integration, e2e]
script:
- npm run test:${TEST_TYPE}
coverage: '/Coverage: \d+\.\d+%/'
artifacts:
reports:
junit: test-results.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
```
Testing layers:
- **Unit tests**: Fast, isolated, run on every commit
- **Integration tests**: Test component interactions
- **End-to-end tests**: Validate user workflows
- **Performance tests**: Check for regressions
#### 3. Security Stage
```yaml
security:
stage: security
parallel:
matrix:
- SCAN_TYPE: [sast, dependency, secrets]
script:
- ./security-scan.sh ${SCAN_TYPE}
allow_failure: false
```
Security scanning types:
- **SAST**: Static Application Security Testing
- **DAST**: Dynamic Application Security Testing
- **Dependency scanning**: Check for vulnerable packages
- **Secret detection**: Find leaked credentials
- **Container scanning**: Analyze Docker images
#### 4. Deploy Stage
```yaml
deploy:staging:
stage: deploy
environment:
name: staging
url: https://staging.example.com
script:
- ./deploy.sh staging
rules:
- if: $CI_COMMIT_BRANCH == "develop"
deploy:production:
stage: deploy
environment:
name: production
url: https://example.com
script:
- ./deploy.sh production
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
```
## Deployment Strategies
### Blue-Green Deployment
Maintain two identical environments:
```yaml
deploy:blue-green:
script:
- ./deploy-to-inactive.sh
- ./run-smoke-tests.sh
- ./switch-traffic.sh
- ./cleanup-old-environment.sh
```
Benefits:
- Zero-downtime deployments
- Easy rollback by switching traffic back
- Full testing in production-like environment
### Canary Deployment
Gradually roll out to subset of users:
```yaml
deploy:canary:
script:
- ./deploy-canary.sh --percentage=5
- ./monitor-metrics.sh --duration=30m
- ./deploy-canary.sh --percentage=25
- ./monitor-metrics.sh --duration=30m
- ./deploy-canary.sh --percentage=100
```
Canary stages:
1. Deploy to 5% of traffic
2. Monitor error rates and latency
3. Gradually increase if metrics are healthy
4. Full rollout or rollback based on data
### Rolling Deployment
Update instances incrementally:
```yaml
deploy:rolling:
script:
- kubectl rollout restart deployment/app
- kubectl rollout status deployment/app --timeout=5m
```
Configuration:
- Set `maxUnavailable` and `maxSurge`
- Health checks determine rollout pace
- Automatic rollback on failure
### Feature Flags
Decouple deployment from release:
```javascript
// Feature flag implementation
if (featureFlags.isEnabled('new-checkout')) {
return ;
} else {
return ;
}
```
Benefits:
- Deploy disabled features to production
- Gradual feature rollout
- A/B testing capabilities
- Quick feature disable without deployment
## Environment Management
### Environment Hierarchy
```
Development -> Testing -> Staging -> Production
```
Each environment should:
- Mirror production as closely as possible
- Have isolated data and secrets
- Use infrastructure as code
### Environment Variables
```yaml
variables:
# Global variables
APP_NAME: my-app
# Environment-specific
.staging:
variables:
ENV: staging
API_URL: https://api.staging.example.com
.production:
variables:
ENV: production
API_URL: https://api.example.com
```
Best practices:
- Never hardcode secrets
- Use secret management (Vault, AWS Secrets Manager)
- Separate configuration from code
- Document all required variables
### Infrastructure as Code
```hcl
# Terraform example
resource "aws_ecs_service" "app" {
name = var.app_name
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.app.arn
desired_count = var.environment == "production" ? 3 : 1
deployment_configuration {
maximum_percent = 200
minimum_healthy_percent = 100
}
}
```
## Testing Strategies
### Test Pyramid
```
/\
/ \ E2E Tests (Few)
/----\
/ \ Integration Tests (Some)
/--------\
/ \ Unit Tests (Many)
--------------
```
### Test Parallelization
```yaml
test:
parallel: 4
script:
- npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
```
### Test Data Management
- Use fixtures for consistent test data
- Reset database state between tests
- Use factories for dynamic test data
- Avoid production data in tests
### Flaky Test Handling
```yaml
test:
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
```
Strategies:
- Quarantine flaky tests
- Add retry logic for known issues
- Investigate and fix root causes
- Track flaky test metrics
## Monitoring and Observability
### Pipeline Metrics
Track these metrics:
- **Lead time**: Commit to production duration
- **Deployment frequency**: How often you deploy
- **Change failure rate**: Percentage of failed deployments
- **Mean time to recovery**: Time to fix failures
### Health Checks
```yaml
deploy:
script:
- ./deploy.sh
- ./wait-for-healthy.sh --timeout=300
- ./run-smoke-tests.sh
```
Implement:
- Readiness probes
- Liveness probes
- Startup probes
- Smoke tests post-deployment
### Alerting
```yaml
notify:failure:
stage: notify
script:
- ./send-alert.sh --channel=deployments --status=failed
when: on_failure
notify:success:
stage: notify
script:
- ./send-notification.sh --channel=deployments --status=success
when: on_success
```
## Security in CI/CD
### Secrets Management
```yaml
# Use CI/CD secret variables
deploy:
script:
- echo "$DEPLOY_KEY" | base64 -d > deploy_key
- chmod 600 deploy_key
- ./deploy.sh
after_script:
- rm -f deploy_key
```
Best practices:
- Rotate secrets regularly
- Use short-lived credentials
- Audit secret access
- Never log secrets
### Pipeline Security
```yaml
# Restrict who can run production deploys
deploy:production:
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
allow_failure: false
environment:
name: production
deployment_tier: production
```
Controls:
- Branch protection rules
- Required approvals
- Audit logging
- Signed commits
### Dependency Security
```yaml
dependency_check:
script:
- npm audit --audit-level=high
- ./check-licenses.sh
allow_failure: false
```
## Optimization Techniques
### Caching
```yaml
cache:
key:
files:
- package-lock.json
paths:
- node_modules/
policy: pull-push
```
Cache strategies:
- Cache dependencies between runs
- Use content-based cache keys
- Separate cache per branch
- Clean stale caches periodically
### Parallelization
```yaml
stages:
- build
- test
- deploy
# Run tests in parallel
test:unit:
stage: test
script: npm run test:unit
test:integration:
stage: test
script: npm run test:integration
test:e2e:
stage: test
script: npm run test:e2e
```
### Artifact Management
```yaml
build:
artifacts:
paths:
- dist/
expire_in: 1 week
when: on_success
```
Best practices:
- Set appropriate expiration
- Only store necessary artifacts
- Use artifact compression
- Clean up old artifacts
## Rollback Strategies
### Automatic Rollback
```yaml
deploy:
script:
- ./deploy.sh
- ./health-check.sh || ./rollback.sh
```
### Manual Rollback
```yaml
rollback:
stage: deploy
when: manual
script:
- ./get-previous-version.sh
- ./deploy.sh --version=$PREVIOUS_VERSION
```
### Database Rollbacks
- Use reversible migrations
- Test rollback procedures
- Consider data compatibility
- Have backup restoration process
## Documentation
### Pipeline Documentation
Document in your repository:
- Pipeline stages and their purpose
- Required environment variables
- Deployment procedures
- Troubleshooting guides
- Rollback procedures
### Runbooks
Create runbooks for:
- Deployment failures
- Rollback procedures
- Environment setup
- Incident response
## Continuous Improvement
### Metrics to Track
- Build success rate
- Average build time
- Test coverage trends
- Deployment frequency
- Incident frequency
### Regular Reviews
- Weekly pipeline performance review
- Monthly security assessment
- Quarterly process improvement
- Annual tooling evaluation
相关技能
运维与云
用于容器管理,图像操作,调试的基本道克命令和工作流程.
运维与云
从开放的代理技能生态系统中发现并安装技能. 使用时:(1)用户问"我如何做X",X可能拥有现有技能,(2)用户说"为X找到技能"或"是否为X有技能",(3)用户问"你能否做X",X是专门能力,(4)用户想扩展代理能力,(5)用户想搜索工具,模板,或工作流程,(6)用户提到他们希望…
运维与云
Azure上使用AppLens,AzureMonitor,资源健康,安全分型的调试Azure生产问题. 当:调试生产问题,故障解答应用服务,应用服务高CPU,应用服务部署失败,故障解答容器应用,故障解答功能,故障解答AKS,VM RDP,Linux SSH,VM黑屏幕,无法连接到…
运维与云
准备 azd 用于部署的Azure项目:为Azure开发者CLI(azd)工作流程生成azure.yaml,基础设施(Bicep/Terraform)和多克文件. 仅当用户明确想要使用 azd 作为部署工具时使用, 或项目已经有一个 azure 。 雅姆尔文件。 不使用: 非az…