PromptDevelopment & Engineering
Specify a webhook-driven task for OpenClaw
Describe event inputs, validation, deduplication, and intended actions before integration work.
◈OpenClaw
By Dave AIDave AI original
MIT · FreeView prompt
Installable skillApache-2.0
CI/CD Skill
Continuous Integration and Continuous Deployment best practices. Use when setting up automated build pipelines, test automation, deployment workflows, or improving release processes.
instructions.md
---
name: ci-cd-432d62ba54ac
description: Continuous Integration and Continuous Deployment best practices. Use when setting up automated build pipelines, test automation, deployment workflows, or improving release processes.
---
# CI/CD Skill
## Core Principle
**Automate everything from commit to production.**
CI/CD eliminates manual steps, catches issues early, and enables rapid, reliable releases. Every commit should automatically:
- Build
- Test
- Deploy (to appropriate environment)
---
## Continuous Integration (CI)
### What is CI?
**CI = Automatically build and test every commit**
When code is pushed:
1. Automated build runs
2. All tests execute
3. Code quality checks run
4. Team sees results immediately
### CI Pipeline Stages
```
┌─────────────────────────────────────────────────────┐
│ CI PIPELINE │
└─────────────────────────────────────────────────────┘
Commit → Build → Test → Lint → Security → Report
│ │ │ │ │ │
│ ├──✅ ├──✅ ├──✅ ├──✅ ├──✅ PASS
│ └──❌ └──❌ └──❌ └──❌ └──❌ FAIL
│
└──────► Block merge if any stage fails
```
### Essential CI Steps
1. **Checkout Code**
```yaml
- uses: actions/checkout@v3
```
2. **Setup Environment**
```yaml
- uses: actions/setup-node@v3
with:
node-version: '18'
```
3. **Install Dependencies**
```yaml
- run: npm ci # Use 'ci' not 'install' for reproducibility
```
4. **Build**
```yaml
- run: npm run build
```
5. **Test**
```yaml
- run: npm test -- --coverage
```
6. **Lint & Format Check**
```yaml
- run: npm run lint
- run: npm run format:check
```
7. **Security Scan**
```yaml
- run: npm audit
```
---
## Continuous Deployment (CD)
### What is CD?
**CD = Automatically deploy passing builds to environments**
Deployment progression:
```
Development → Staging → Production
↑ ↑ ↑
Auto Auto Manual approval
or Auto
```
### Deployment Strategies
#### 1. Blue-Green Deployment
Two identical environments (Blue = current, Green = new):
```
┌────────────┐ ┌────────────┐
│ BLUE │ │ GREEN │
│ (Current) │ │ (New) │
└─────┬──────┘ └─────┬──────┘
│ │
└────────┬─────────┘
│
┌────▼────┐
│ Router │ ← Switch traffic instantly
└─────────┘
```
**Benefits:**
- Zero downtime
- Instant rollback (switch back to Blue)
- Test Green before switching
---
#### 2. Canary Deployment
Gradual rollout to subset of users:
```
Version A (old): 90% of traffic
Version B (new): 10% of traffic
→ Monitor metrics
→ If good: increase B to 50%
→ If good: increase B to 100%
→ If bad: rollback to 100% A
```
**Benefits:**
- Limit blast radius of bugs
- Real-world testing
- Data-driven rollout decisions
---
#### 3. Rolling Deployment
Update instances one at a time:
```
Instance 1: v1.0 → v1.1 ✅
Instance 2: v1.0 → v1.1 ✅ (after 1 is healthy)
Instance 3: v1.0 → v1.1 ✅ (after 2 is healthy)
```
**Benefits:**
- No downtime
- Automatic rollback if health checks fail
- Resource efficient
---
## CI/CD Pipeline Examples
### GitHub Actions (Node.js)
```yaml
name: CI/CD Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run linter
run: npm run lint
- name: Run tests
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Upload coverage
uses: codecov/codecov-action@v3
deploy-staging:
needs: build-and-test
if: github.ref == 'refs/heads/develop'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy to staging
run: |
echo "Deploying to staging..."
# Your deployment script here
deploy-production:
needs: build-and-test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # Requires manual approval
steps:
- uses: actions/checkout@v3
- name: Deploy to production
run: |
echo "Deploying to production..."
# Your deployment script here
```
---
### GitLab CI (Python)
```yaml
stages:
- test
- build
- deploy
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
cache:
paths:
- .cache/pip
- venv/
test:
stage: test
image: python:3.11
before_script:
- python -m venv venv
- source venv/bin/activate
- pip install -r requirements.txt
script:
- pytest --cov=src --cov-report=xml
- pylint src/
coverage: '/TOTAL.*\s+(\d+%)$/'
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage.xml
build:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
deploy-staging:
stage: deploy
only:
- develop
script:
- echo "Deploy to staging"
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
deploy-production:
stage: deploy
only:
- main
when: manual # Requires approval
script:
- echo "Deploy to production"
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
```
---
## Best Practices
### 1. Fast Feedback
**Keep CI pipeline fast (<10 minutes):**
✅ **Do:**
- Parallel test execution
- Test only changed code (when possible)
- Cache dependencies
- Use faster test runners
❌ **Don't:**
- Run slow integration tests on every commit
- Rebuild everything from scratch
- Run tests sequentially
---
### 2. Fail Fast
**Stop pipeline at first failure:**
```yaml
# Good: Fail fast
- run: npm run lint
- run: npm test # Only runs if lint passes
```
**Why:** Saves CI resources and developer time
---
### 3. Reproducible Builds
**Same input = same output:**
✅ **Do:**
- Lock dependency versions (`package-lock.json`, `Pipfile.lock`)
- Use specific tool versions (`node-version: '18.0.0'`)
- Use `npm ci` not `npm install`
- Tag Docker images with commit SHA
❌ **Don't:**
- Use `latest` tags
- Use version ranges without locks
- Rely on global installations
---
### 4. Separate Build from Deploy
**Build once, deploy many times:**
```
Build artifact → Test → Deploy to dev
Deploy to staging
Deploy to production
(Same artifact everywhere)
```
**Benefits:**
- Consistent deployments
- Faster deployments (no rebuild)
- Test the actual artifact that goes to production
---
### 5. Environment Parity
**Keep environments similar:**
```
Development ≈ Staging ≈ Production
```
**Same:**
- Operating system
- Runtime versions
- Configuration structure
- Database schema
**Different:**
- Scale (production has more resources)
- Data (production has real data)
- Secrets (different credentials)
---
### 6. Infrastructure as Code
**Define infrastructure in version control:**
```yaml
# terraform/main.tf
resource "aws_instance" "app" {
ami = "ami-12345678"
instance_type = "t2.micro"
tags = {
Name = "app-server"
}
}
```
**Benefits:**
- Version controlled
- Reviewable
- Reproducible
- Self-documenting
---
## Security in CI/CD
### 1. Secrets Management
❌ **Never commit secrets:**
```yaml
# BAD - Secrets in code
- run: deploy.sh --api-key=abc123
```
✅ **Use secret management:**
```yaml
# GOOD - Secrets from vault
- run: deploy.sh --api-key=${{ secrets.API_KEY }}
```
---
### 2. Dependency Scanning
**Scan for vulnerabilities:**
```yaml
- name: Security audit
run: |
npm audit --audit-level=moderate
# Or use Snyk, Dependabot, etc.
```
---
### 3. Container Scanning
**Scan Docker images:**
```yaml
- name: Scan image
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:${{ github.sha }}'
severity: 'CRITICAL,HIGH'
```
---
### 4. Least Privilege
**CI/CD should have minimal permissions:**
- Read-only access to repos
- Deploy-only access to environments
- No admin permissions
- Scoped tokens with expiration
---
## Monitoring CI/CD
### Key Metrics
1. **Build Success Rate**
- Target: >95%
- Track: Percentage of passing builds
2. **Build Time**
- Target: <10 minutes
- Track: P50, P95, P99 build durations
3. **Deployment Frequency**
- Target: Multiple per day (for high-performing teams)
- Track: Deployments per day/week
4. **Mean Time to Recovery (MTTR)**
- Target: <1 hour
- Track: Time from incident to fix deployed
5. **Change Failure Rate**
- Target: <15%
- Track: Percentage of deployments causing issues
---
## Troubleshooting
### Build Failures
**Debug steps:**
1. **Reproduce locally**
```bash
# Use same versions as CI
nvm use 18.0.0
npm ci
npm test
```
2. **Check CI logs**
- Look for error messages
- Check environment variables
- Verify dependencies installed correctly
3. **Common issues:**
- Flaky tests (non-deterministic)
- Network timeouts
- Resource limits (memory, disk)
- Race conditions (parallel tests)
---
### Deployment Failures
**Rollback strategy:**
```bash
# Manual rollback
kubectl rollout undo deployment/app
# Or use previous Docker tag
docker pull myapp:$PREVIOUS_COMMIT_SHA
```
**Debug checklist:**
- [ ] Health checks passing?
- [ ] Database migrations applied?
- [ ] Configuration correct?
- [ ] Network connectivity?
- [ ] Resource limits sufficient?
---
## Integration with Other Skills
### With Git Hygiene
- CI runs on every commit
- Commit messages reference issues
- CI status visible in PRs
### With Testing Strategy
- CI runs all test levels
- Coverage tracked over time
- Failed tests block merge
### With Code Review
- CI results visible in PR
- Reviewers see test results
- Automated checks complement human review
---
## Quick Reference
### CI Pipeline Checklist
- [ ] Build on every commit
- [ ] Run all tests automatically
- [ ] Lint and format checks
- [ ] Security scans
- [ ] Fast feedback (<10 min)
- [ ] Block merge on failure
### CD Pipeline Checklist
- [ ] Automated deployment to dev/staging
- [ ] Manual approval for production (or automated with safeguards)
- [ ] Rollback strategy defined
- [ ] Health checks after deployment
- [ ] Monitoring and alerts configured
---
**Remember:** CI/CD is about automation, speed, and reliability. Build once, test thoroughly, deploy confidently. Fast feedback loops catch issues early. Automate the boring stuff, focus on building features.
---
name: ci-cd-432d62ba54ac
description: Continuous Integration and Continuous Deployment best practices. Use when setting up automated build pipelines, test automation, deployment workflows, or improving release processes.
---
# CI/CD Skill
## Core Principle
**Automate everything from commit to production.**
CI/CD eliminates manual steps, catches issues early, and enables rapid, reliable releases. Every commit should automatically:
- Build
- Test
- Deploy (to appropriate environment)
---
## Continuous Integration (CI)
### What is CI?
**CI = Automatically build and test every commit**
When code is pushed:
1. Automated build runs
2. All tests execute
3. Code quality checks run
4. Team sees results immediately
### CI Pipeline Stages
```
┌─────────────────────────────────────────────────────┐
│ CI PIPELINE │
└─────────────────────────────────────────────────────┘
Commit → Build → Test → Lint → Security → Report
│ │ │ │ │ │
│ ├──✅ ├──✅ ├──✅ ├──✅ ├──✅ PASS
│ └──❌ └──❌ └──❌ └──❌ └──❌ FAIL
│
└──────► Block merge if any stage fails
```
### Essential CI Steps
1. **Checkout Code**
```yaml
- uses: actions/checkout@v3
```
2. **Setup Environment**
```yaml
- uses: actions/setup-node@v3
with:
node-version: '18'
```
3. **Install Dependencies**
```yaml
- run: npm ci # Use 'ci' not 'install' for reproducibility
```
4. **Build**
```yaml
- run: npm run build
```
5. **Test**
```yaml
- run: npm test -- --coverage
```
6. **Lint & Format Check**
```yaml
- run: npm run lint
- run: npm run format:check
```
7. **Security Scan**
```yaml
- run: npm audit
```
---
## Continuous Deployment (CD)
### What is CD?
**CD = Automatically deploy passing builds to environments**
Deployment progression:
```
Development → Staging → Production
↑ ↑ ↑
Auto Auto Manual approval
or Auto
```
### Deployment Strategies
#### 1. Blue-Green Deployment
Two identical environments (Blue = current, Green = new):
```
┌────────────┐ ┌────────────┐
│ BLUE │ │ GREEN │
│ (Current) │ │ (New) │
└─────┬──────┘ └─────┬──────┘
│ │
└────────┬─────────┘
│
┌────▼────┐
│ Router │ ← Switch traffic instantly
└─────────┘
```
**Benefits:**
- Zero downtime
- Instant rollback (switch back to Blue)
- Test Green before switching
---
#### 2. Canary Deployment
Gradual rollout to subset of users:
```
Version A (old): 90% of traffic
Version B (new): 10% of traffic
→ Monitor metrics
→ If good: increase B to 50%
→ If good: increase B to 100%
→ If bad: rollback to 100% A
```
**Benefits:**
- Limit blast radius of bugs
- Real-world testing
- Data-driven rollout decisions
---
#### 3. Rolling Deployment
Update instances one at a time:
```
Instance 1: v1.0 → v1.1 ✅
Instance 2: v1.0 → v1.1 ✅ (after 1 is healthy)
Instance 3: v1.0 → v1.1 ✅ (after 2 is healthy)
```
**Benefits:**
- No downtime
- Automatic rollback if health checks fail
- Resource efficient
---
## CI/CD Pipeline Examples
### GitHub Actions (Node.js)
```yaml
name: CI/CD Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run linter
run: npm run lint
- name: Run tests
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Upload coverage
uses: codecov/codecov-action@v3
deploy-staging:
needs: build-and-test
if: github.ref == 'refs/heads/develop'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy to staging
run: |
echo "Deploying to staging..."
# Your deployment script here
deploy-production:
needs: build-and-test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # Requires manual approval
steps:
- uses: actions/checkout@v3
- name: Deploy to production
run: |
echo "Deploying to production..."
# Your deployment script here
```
---
### GitLab CI (Python)
```yaml
stages:
- test
- build
- deploy
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
cache:
paths:
- .cache/pip
- venv/
test:
stage: test
image: python:3.11
before_script:
- python -m venv venv
- source venv/bin/activate
- pip install -r requirements.txt
script:
- pytest --cov=src --cov-report=xml
- pylint src/
coverage: '/TOTAL.*\s+(\d+%)$/'
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage.xml
build:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
deploy-staging:
stage: deploy
only:
- develop
script:
- echo "Deploy to staging"
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
deploy-production:
stage: deploy
only:
- main
when: manual # Requires approval
script:
- echo "Deploy to production"
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
```
---
## Best Practices
### 1. Fast Feedback
**Keep CI pipeline fast (<10 minutes):**
✅ **Do:**
- Parallel test execution
- Test only changed code (when possible)
- Cache dependencies
- Use faster test runners
❌ **Don't:**
- Run slow integration tests on every commit
- Rebuild everything from scratch
- Run tests sequentially
---
### 2. Fail Fast
**Stop pipeline at first failure:**
```yaml
# Good: Fail fast
- run: npm run lint
- run: npm test # Only runs if lint passes
```
**Why:** Saves CI resources and developer time
---
### 3. Reproducible Builds
**Same input = same output:**
✅ **Do:**
- Lock dependency versions (`package-lock.json`, `Pipfile.lock`)
- Use specific tool versions (`node-version: '18.0.0'`)
- Use `npm ci` not `npm install`
- Tag Docker images with commit SHA
❌ **Don't:**
- Use `latest` tags
- Use version ranges without locks
- Rely on global installations
---
### 4. Separate Build from Deploy
**Build once, deploy many times:**
```
Build artifact → Test → Deploy to dev
Deploy to staging
Deploy to production
(Same artifact everywhere)
```
**Benefits:**
- Consistent deployments
- Faster deployments (no rebuild)
- Test the actual artifact that goes to production
---
### 5. Environment Parity
**Keep environments similar:**
```
Development ≈ Staging ≈ Production
```
**Same:**
- Operating system
- Runtime versions
- Configuration structure
- Database schema
**Different:**
- Scale (production has more resources)
- Data (production has real data)
- Secrets (different credentials)
---
### 6. Infrastructure as Code
**Define infrastructure in version control:**
```yaml
# terraform/main.tf
resource "aws_instance" "app" {
ami = "ami-12345678"
instance_type = "t2.micro"
tags = {
Name = "app-server"
}
}
```
**Benefits:**
- Version controlled
- Reviewable
- Reproducible
- Self-documenting
---
## Security in CI/CD
### 1. Secrets Management
❌ **Never commit secrets:**
```yaml
# BAD - Secrets in code
- run: deploy.sh --api-key=abc123
```
✅ **Use secret management:**
```yaml
# GOOD - Secrets from vault
- run: deploy.sh --api-key=${{ secrets.API_KEY }}
```
---
### 2. Dependency Scanning
**Scan for vulnerabilities:**
```yaml
- name: Security audit
run: |
npm audit --audit-level=moderate
# Or use Snyk, Dependabot, etc.
```
---
### 3. Container Scanning
**Scan Docker images:**
```yaml
- name: Scan image
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:${{ github.sha }}'
severity: 'CRITICAL,HIGH'
```
---
### 4. Least Privilege
**CI/CD should have minimal permissions:**
- Read-only access to repos
- Deploy-only access to environments
- No admin permissions
- Scoped tokens with expiration
---
## Monitoring CI/CD
### Key Metrics
1. **Build Success Rate**
- Target: >95%
- Track: Percentage of passing builds
2. **Build Time**
- Target: <10 minutes
- Track: P50, P95, P99 build durations
3. **Deployment Frequency**
- Target: Multiple per day (for high-performing teams)
- Track: Deployments per day/week
4. **Mean Time to Recovery (MTTR)**
- Target: <1 hour
- Track: Time from incident to fix deployed
5. **Change Failure Rate**
- Target: <15%
- Track: Percentage of deployments causing issues
---
## Troubleshooting
### Build Failures
**Debug steps:**
1. **Reproduce locally**
```bash
# Use same versions as CI
nvm use 18.0.0
npm ci
npm test
```
2. **Check CI logs**
- Look for error messages
- Check environment variables
- Verify dependencies installed correctly
3. **Common issues:**
- Flaky tests (non-deterministic)
- Network timeouts
- Resource limits (memory, disk)
- Race conditions (parallel tests)
---
### Deployment Failures
**Rollback strategy:**
```bash
# Manual rollback
kubectl rollout undo deployment/app
# Or use previous Docker tag
docker pull myapp:$PREVIOUS_COMMIT_SHA
```
**Debug checklist:**
- [ ] Health checks passing?
- [ ] Database migrations applied?
- [ ] Configuration correct?
- [ ] Network connectivity?
- [ ] Resource limits sufficient?
---
## Integration with Other Skills
### With Git Hygiene
- CI runs on every commit
- Commit messages reference issues
- CI status visible in PRs
### With Testing Strategy
- CI runs all test levels
- Coverage tracked over time
- Failed tests block merge
### With Code Review
- CI results visible in PR
- Reviewers see test results
- Automated checks complement human review
---
## Quick Reference
### CI Pipeline Checklist
- [ ] Build on every commit
- [ ] Run all tests automatically
- [ ] Lint and format checks
- [ ] Security scans
- [ ] Fast feedback (<10 min)
- [ ] Block merge on failure
### CD Pipeline Checklist
- [ ] Automated deployment to dev/staging
- [ ] Manual approval for production (or automated with safeguards)
- [ ] Rollback strategy defined
- [ ] Health checks after deployment
- [ ] Monitoring and alerts configured
---
**Remember:** CI/CD is about automation, speed, and reliability. Build once, test thoroughly, deploy confidently. Fast feedback loops catch issues early. Automate the boring stuff, focus on building features.
COMPATIBILITY & REFERENCES
Platform guidance
Imported from the listed AgentSkill.sh category. Complete supplied package files and notices are retained. Required external tools and credentials are not installed. No bundled code was executed during import. Individual agent task behavior has not been tested.