wehub/davila7--claude-code-templates
1
0
Fork 0
Code Issues Pull Requests Actions Deployments Models Agent Notes Packages Projects Releases Wiki Activity

chore: import upstream snapshot with attribution
Component Security Validation / Security Audit (push) Has been cancelled
Details
Deploy to Cloudflare Pages / deploy (push) Has been cancelled
Details

Browse Source
This commit is contained in:
wehub-resource-sync
2026-07-13 12:38:58 +08:00
commit bb5c75ce05
8824 changed files with 1946442 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cli-tool/components/commands/deployment/add-changelog.md
+91
View File
@@ -0,0 +1,91 @@
---
allowed-tools: Read, Edit, Write, Bash
argument-hint: [version] | [entry-type] [description]
description: Generate and maintain project changelog with Keep a Changelog format
---
# Add Changelog Entry
Generate and maintain project changelog: $ARGUMENTS
## Current State
- Existing changelog: @CHANGELOG.md (if exists)
- Recent commits: !`git log --oneline -10`
- Current version: !`git describe --tags --abbrev=0 2>/dev/null || echo "No tags found"`
- Package version: @package.json (if exists)
## Task
1. **Changelog Format (Keep a Changelog)**
```markdown
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
### Added
- New features
### Changed
- Changes in existing functionality
### Deprecated
- Soon-to-be removed features
### Removed
- Removed features
### Fixed
- Bug fixes
### Security
- Security improvements
```
2. **Version Entries**
```markdown
## [1.2.3] - 2024-01-15
### Added
- User authentication system
- Dark mode toggle
- Export functionality for reports
### Fixed
- Memory leak in background tasks
- Timezone handling issues
```
3. **Automation Tools**
```bash
# Generate changelog from git commits
npm install -D conventional-changelog-cli
npx conventional-changelog -p angular -i CHANGELOG.md -s
# Auto-changelog
npm install -D auto-changelog
npx auto-changelog
```
4. **Commit Convention**
```bash
# Conventional commits for auto-generation
feat: add user authentication
fix: resolve memory leak in tasks
docs: update API documentation
style: format code with prettier
refactor: reorganize user service
test: add unit tests for auth
chore: update dependencies
```
5. **Integration with Releases**
- Update changelog before each release
- Include in release notes
- Link to GitHub releases
- Tag versions consistently
Remember to keep entries clear, categorized, and focused on user-facing changes.
cli-tool/components/commands/deployment/blue-green-deployment.md
+823
View File
@@ -0,0 +1,823 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [strategy] | setup | deploy | switch | rollback | status
description: Implement blue-green deployment strategy with zero-downtime switching, health validation, and automatic rollback
---
# Blue-Green Deployment Strategy
Implement blue-green deployment: $ARGUMENTS
## Current Infrastructure State
- Load balancer config: @nginx.conf or @haproxy.cfg or cloud LB configuration
- Current deployment: !`curl -s https://api.example.com/version 2>/dev/null || echo "Version endpoint needed"`
- Container orchestration: !`kubectl get deployments 2>/dev/null || docker service ls 2>/dev/null || echo "Container platform detection needed"`
- Health endpoints: !`curl -s https://api.example.com/health 2>/dev/null | jq -r '.status // "Unknown"' || echo "Health check setup needed"`
- DNS configuration: Check for DNS management capabilities
## Task
Implement production-grade blue-green deployment with comprehensive validation and monitoring.
## Blue-Green Architecture Components
### 1. **Infrastructure Setup**
#### Load Balancer Configuration (NGINX)
```nginx
upstream blue {
server blue-app-1:3000;
server blue-app-2:3000;
server blue-app-3:3000;
}
upstream green {
server green-app-1:3000;
server green-app-2:3000;
server green-app-3:3000;
}
# Current active environment
upstream active {
server blue-app-1:3000;
server blue-app-2:3000;
server blue-app-3:3000;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://active;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Environment $environment;
# Health check configuration
proxy_connect_timeout 5s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
# Retry configuration
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
proxy_next_upstream_tries 2;
}
# Health check endpoint
location /health {
access_log off;
proxy_pass http://active/health;
proxy_connect_timeout 1s;
proxy_send_timeout 1s;
proxy_read_timeout 1s;
}
# Environment indicator
location /environment {
access_log off;
return 200 $environment;
add_header Content-Type text/plain;
}
}
```
#### HAProxy Configuration
```haproxy
global
daemon
log 127.0.0.1:514 local0
stats socket /var/run/haproxy.sock mode 600 level admin
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
option httplog
option dontlognull
# Blue environment
backend blue_backend
balance roundrobin
option httpchk GET /health
http-check expect status 200
server blue1 blue-app-1:3000 check
server blue2 blue-app-2:3000 check
server blue3 blue-app-3:3000 check
# Green environment
backend green_backend
balance roundrobin
option httpchk GET /health
http-check expect status 200
server green1 green-app-1:3000 check
server green2 green-app-2:3000 check
server green3 green-app-3:3000 check
# Frontend with switching logic
frontend main_frontend
bind *:80
# Environment switching via ACL
use_backend blue_backend if { var(txn.environment) -m str blue }
use_backend green_backend if { var(txn.environment) -m str green }
default_backend blue_backend # Default to blue
# Stats interface
frontend stats
bind *:8404
stats enable
stats uri /stats
stats refresh 5s
```
### 2. **Kubernetes Blue-Green Implementation**
#### Blue-Green Service Management
```yaml
# blue-service.yaml
apiVersion: v1
kind: Service
metadata:
name: app-service-blue
labels:
app: myapp
environment: blue
spec:
selector:
app: myapp
environment: blue
ports:
- port: 80
targetPort: 3000
type: ClusterIP
---
# green-service.yaml
apiVersion: v1
kind: Service
metadata:
name: app-service-green
labels:
app: myapp
environment: green
spec:
selector:
app: myapp
environment: green
ports:
- port: 80
targetPort: 3000
type: ClusterIP
---
# active-service.yaml (points to current active environment)
apiVersion: v1
kind: Service
metadata:
name: app-service-active
labels:
app: myapp
environment: active
spec:
selector:
app: myapp
environment: blue # Switch this to 'green' during deployment
ports:
- port: 80
targetPort: 3000
type: LoadBalancer
```
#### Blue-Green Deployments
```yaml
# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
labels:
app: myapp
environment: blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
environment: blue
template:
metadata:
labels:
app: myapp
environment: blue
spec:
containers:
- name: app
image: myapp:v1.0.0
ports:
- containerPort: 3000
env:
- name: ENVIRONMENT
value: "blue"
- name: VERSION
value: "v1.0.0"
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
labels:
app: myapp
environment: green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
environment: green
template:
metadata:
labels:
app: myapp
environment: green
spec:
containers:
- name: app
image: myapp:v1.1.0 # New version
ports:
- containerPort: 3000
env:
- name: ENVIRONMENT
value: "green"
- name: VERSION
value: "v1.1.0"
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
```
### 3. **Deployment Automation Scripts**
#### Blue-Green Deployment Script
```bash
#!/bin/bash
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "$SCRIPT_DIR/config.sh"
# Configuration
BLUE_ENV="blue"
GREEN_ENV="green"
HEALTH_CHECK_URL="${APP_URL}/health"
READY_CHECK_URL="${APP_URL}/ready"
VERSION_URL="${APP_URL}/version"
# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
log() {
echo -e "${GREEN}[$(date '+%Y-%m-%d %H:%M:%S')] $1${NC}"
}
warn() {
echo -e "${YELLOW}[WARNING] $1${NC}"
}
error() {
echo -e "${RED}[ERROR] $1${NC}"
exit 1
}
# Get current active environment
get_current_env() {
if kubectl get service app-service-active &>/dev/null; then
kubectl get service app-service-active -o jsonpath='{.spec.selector.environment}'
else
echo "blue" # Default to blue if service doesn't exist
fi
}
# Get inactive environment (opposite of current)
get_inactive_env() {
local current_env=$1
if [ "$current_env" = "blue" ]; then
echo "green"
else
echo "blue"
fi
}
# Deploy to inactive environment
deploy_to_inactive() {
local version=$1
local current_env=$(get_current_env)
local inactive_env=$(get_inactive_env "$current_env")
log "Current active environment: $current_env"
log "Deploying version $version to $inactive_env environment"
# Update deployment with new image
kubectl set image deployment/app-$inactive_env app=myapp:$version
# Wait for rollout to complete
log "Waiting for deployment rollout to complete..."
kubectl rollout status deployment/app-$inactive_env --timeout=600s
# Verify pods are running
log "Verifying pods are running..."
kubectl wait --for=condition=ready pod -l app=myapp,environment=$inactive_env --timeout=300s
log "Deployment to $inactive_env environment completed successfully"
}
# Health check function
health_check() {
local env=$1
local service_url="http://app-service-$env.$NAMESPACE.svc.cluster.local"
log "Performing health check for $env environment..."
# Use kubectl port-forward for internal testing
kubectl port-forward service/app-service-$env 8080:80 &
local port_forward_pid=$!
sleep 5 # Wait for port-forward to establish
local health_status=1
local attempts=0
local max_attempts=10
while [ $attempts -lt $max_attempts ]; do
if curl -f -s http://localhost:8080/health > /dev/null; then
health_status=0
break
fi
attempts=$((attempts + 1))
log "Health check attempt $attempts/$max_attempts failed, retrying..."
sleep 10
done
# Clean up port-forward
kill $port_forward_pid 2>/dev/null || true
if [ $health_status -eq 0 ]; then
log "Health check passed for $env environment"
return 0
else
error "Health check failed for $env environment after $max_attempts attempts"
fi
}
# Smoke tests
run_smoke_tests() {
local env=$1
log "Running smoke tests for $env environment..."
# Port-forward for testing
kubectl port-forward service/app-service-$env 8080:80 &
local port_forward_pid=$!
sleep 5
local test_results=()
# Test 1: Health endpoint
if curl -f -s http://localhost:8080/health | jq -e '.status == "healthy"' > /dev/null; then
test_results+=("✅ Health endpoint")
else
test_results+=("❌ Health endpoint")
fi
# Test 2: Version endpoint
if curl -f -s http://localhost:8080/version > /dev/null; then
test_results+=("✅ Version endpoint")
else
test_results+=("❌ Version endpoint")
fi
# Test 3: Main application endpoint
if curl -f -s http://localhost:8080/ > /dev/null; then
test_results+=("✅ Main endpoint")
else
test_results+=("❌ Main endpoint")
fi
# Test 4: Database connectivity (if applicable)
if curl -f -s http://localhost:8080/db-health 2>/dev/null | jq -e '.connected == true' > /dev/null; then
test_results+=("✅ Database connectivity")
else
test_results+=("⚠️ Database connectivity (not tested)")
fi
# Clean up port-forward
kill $port_forward_pid 2>/dev/null || true
# Display results
log "Smoke test results for $env:"
printf '%s\n' "${test_results[@]}"
# Check if all critical tests passed
local failed_tests=$(printf '%s\n' "${test_results[@]}" | grep -c "❌" || true)
if [ "$failed_tests" -gt 0 ]; then
error "Smoke tests failed with $failed_tests failures"
fi
log "All smoke tests passed for $env environment"
}
# Switch traffic to new environment
switch_traffic() {
local target_env=$1
local current_env=$(get_current_env)
if [ "$target_env" = "$current_env" ]; then
warn "Target environment ($target_env) is already active"
return 0
fi
log "Switching traffic from $current_env to $target_env"
# Create backup of current service configuration
kubectl get service app-service-active -o yaml > "/tmp/service-backup-$(date +%Y%m%d-%H%M%S).yaml"
# Update service selector to point to new environment
kubectl patch service app-service-active -p '{"spec":{"selector":{"environment":"'$target_env'"}}}'
# Verify the switch
sleep 10
local new_active_env=$(get_current_env)
if [ "$new_active_env" = "$target_env" ]; then
log "Traffic successfully switched to $target_env environment"
else
error "Failed to switch traffic to $target_env environment"
fi
# Wait for load balancer to propagate changes
log "Waiting for load balancer to propagate changes (30 seconds)..."
sleep 30
# Verify external traffic is flowing to new environment
local attempts=0
local max_attempts=5
while [ $attempts -lt $max_attempts ]; do
local version=$(curl -s $VERSION_URL | jq -r '.version // "unknown"' 2>/dev/null || echo "unknown")
if [ "$version" != "unknown" ]; then
log "External traffic verification successful - Version: $version"
break
fi
attempts=$((attempts + 1))
sleep 10
done
}
# Rollback to previous environment
rollback() {
local current_env=$(get_current_env)
local previous_env=$(get_inactive_env "$current_env")
warn "Initiating rollback from $current_env to $previous_env"
# Verify previous environment is healthy
health_check "$previous_env"
# Switch traffic back
switch_traffic "$previous_env"
log "Rollback completed successfully"
}
# Monitor deployment
monitor_deployment() {
local duration=${1:-300} # Default 5 minutes
local start_time=$(date +%s)
local end_time=$((start_time + duration))
log "Monitoring deployment for ${duration} seconds..."
while [ $(date +%s) -lt $end_time ]; do
local health_status=$(curl -s $HEALTH_CHECK_URL | jq -r '.status // "unknown"' 2>/dev/null || echo "unknown")
local version=$(curl -s $VERSION_URL | jq -r '.version // "unknown"' 2>/dev/null || echo "unknown")
echo "$(date '+%H:%M:%S') - Health: $health_status, Version: $version"
# Check for critical issues
if [ "$health_status" = "unhealthy" ]; then
error "Application became unhealthy during monitoring period"
fi
sleep 30
done
log "Monitoring completed successfully"
}
# Full blue-green deployment process
deploy() {
local version=$1
if [ -z "$version" ]; then
error "Version parameter is required"
fi
log "Starting blue-green deployment for version $version"
# Step 1: Deploy to inactive environment
deploy_to_inactive "$version"
# Step 2: Health check inactive environment
local current_env=$(get_current_env)
local inactive_env=$(get_inactive_env "$current_env")
health_check "$inactive_env"
# Step 3: Run smoke tests
run_smoke_tests "$inactive_env"
# Step 4: Switch traffic
switch_traffic "$inactive_env"
# Step 5: Monitor new deployment
monitor_deployment 300
log "Blue-green deployment completed successfully"
log "New active environment: $inactive_env"
log "Version deployed: $version"
}
# Main script logic
case "${1:-deploy}" in
"setup")
log "Setting up blue-green deployment infrastructure..."
kubectl apply -f k8s/blue-green/
log "Blue-green infrastructure setup completed"
;;
"deploy")
deploy "${2:-latest}"
;;
"switch")
local target_env="${2:-$(get_inactive_env $(get_current_env))}"
switch_traffic "$target_env"
;;
"rollback")
rollback
;;
"status")
local current_env=$(get_current_env)
local inactive_env=$(get_inactive_env "$current_env")
echo "=== Blue-Green Deployment Status ==="
echo "Current active environment: $current_env"
echo "Inactive environment: $inactive_env"
echo ""
echo "=== Environment Details ==="
kubectl get deployments -l app=myapp
echo ""
kubectl get services -l app=myapp
echo ""
echo "=== Health Status ==="
curl -s $HEALTH_CHECK_URL 2>/dev/null | jq . || echo "Health check unavailable"
;;
"monitor")
monitor_deployment "${2:-300}"
;;
*)
echo "Usage: $0 {setup|deploy|switch|rollback|status|monitor}"
echo ""
echo "Commands:"
echo " setup - Initialize blue-green infrastructure"
echo " deploy <version> - Deploy new version using blue-green strategy"
echo " switch [environment] - Switch traffic between environments"
echo " rollback - Rollback to previous environment"
echo " status - Show current deployment status"
echo " monitor [duration] - Monitor deployment for specified duration"
exit 1
;;
esac
```
### 4. **Configuration Management**
#### Environment Configuration
```bash
# config.sh
#!/bin/bash
# Application configuration
APP_NAME="myapp"
APP_URL="https://api.example.com"
NAMESPACE="default"
# Container registry
REGISTRY="your-registry.com"
REPOSITORY="myapp"
# Health check configuration
HEALTH_CHECK_TIMEOUT=30
READY_CHECK_TIMEOUT=10
DEPLOYMENT_TIMEOUT=600
# Monitoring configuration
MONITORING_DURATION=300
SMOKE_TEST_TIMEOUT=60
# Notification configuration
SLACK_WEBHOOK_URL="${SLACK_WEBHOOK_URL:-}"
EMAIL_NOTIFICATIONS="${EMAIL_NOTIFICATIONS:-false}"
# Database configuration (if applicable)
DB_MIGRATION_STRATEGY="${DB_MIGRATION_STRATEGY:-forward-only}"
DB_BACKUP_BEFORE_DEPLOY="${DB_BACKUP_BEFORE_DEPLOY:-true}"
```
### 5. **Advanced Features**
#### Canary Integration
```yaml
# canary-service.yaml - For canary releases within blue-green
apiVersion: v1
kind: Service
metadata:
name: app-service-canary
labels:
app: myapp
environment: canary
spec:
selector:
app: myapp
environment: green # Route small percentage to green
ports:
- port: 80
targetPort: 3000
type: ClusterIP
---
# Ingress with traffic splitting
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10" # 10% to canary
nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service-canary
port:
number: 80
```
#### Database Migration Strategy
```bash
#!/bin/bash
# db-migration-strategy.sh
handle_database_migrations() {
local version=$1
local target_env=$2
log "Handling database migrations for version $version"
case "$DB_MIGRATION_STRATEGY" in
"forward-only")
# Only run forward migrations, safe for blue-green
run_forward_migrations "$version"
;;
"blue-green-safe")
# Use database views/aliases for backward compatibility
setup_db_compatibility_layer "$version"
run_forward_migrations "$version"
;;
"separate-db")
# Each environment has its own database
migrate_environment_database "$target_env" "$version"
;;
"shared-compatible")
# Ensure migrations are backward compatible
validate_migration_compatibility "$version"
run_forward_migrations "$version"
;;
*)
warn "Unknown database migration strategy: $DB_MIGRATION_STRATEGY"
;;
esac
}
run_forward_migrations() {
local version=$1
# Backup database before migrations
if [ "$DB_BACKUP_BEFORE_DEPLOY" = "true" ]; then
backup_database "pre-migration-$version-$(date +%Y%m%d-%H%M%S)"
fi
# Run migrations
kubectl run migration-job-$version \
--image=myapp:$version \
--restart=Never \
--command -- /bin/sh -c "npm run migrate"
# Wait for migration to complete
kubectl wait --for=condition=complete job/migration-job-$version --timeout=300s
# Verify migration success
local exit_code=$(kubectl get job migration-job-$version -o jsonpath='{.status.conditions[?(@.type=="Complete")].status}')
if [ "$exit_code" != "True" ]; then
error "Database migration failed"
fi
log "Database migrations completed successfully"
}
```
#### Monitoring Integration
```yaml
# monitoring/prometheus-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: blue-green-deployment-rules
spec:
groups:
- name: blue-green-deployment
rules:
- alert: BlueGreenEnvironmentDown
expr: up{job="myapp", environment=~"blue|green"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Blue-green environment {{ $labels.environment }} is down"
description: "Environment {{ $labels.environment }} has been down for more than 1 minute"
- alert: BlueGreenHighErrorRate
expr: rate(http_requests_total{job="myapp", status=~"5.."}[5m]) > 0.1
for: 2m
labels:
severity: warning
annotations:
summary: "High error rate detected during blue-green deployment"
description: "Error rate is {{ $value }} errors per second"
- alert: BlueGreenDeploymentStuck
expr: time() - kube_deployment_status_observed_generation{deployment=~"app-blue|app-green"} > 600
for: 5m
labels:
severity: warning
annotations:
summary: "Blue-green deployment appears stuck"
description: "Deployment {{ $labels.deployment }} hasn't updated in over 10 minutes"
```
This blue-green deployment system provides zero-downtime deployments with comprehensive validation, monitoring, and rollback capabilities. The implementation supports multiple platforms (Kubernetes, Docker Swarm, traditional deployments) and includes advanced features like database migration handling and canary releases.
cli-tool/components/commands/deployment/changelog-demo-command.md
+42
View File
@@ -0,0 +1,42 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [format] | --generate | --validate | --demo
description: Demonstrate changelog automation features with real examples and validation
---
# Changelog Automation Demo
Demonstrate changelog automation features: $ARGUMENTS
## Current Project State
- Existing changelog: @CHANGELOG.md (if exists)
- Package version: @package.json or @pyproject.toml or @Cargo.toml (if exists)
- Recent commits: !`git log --oneline -10`
- Git tags: !`git tag -l | tail -5`
## Demo Features
### 1. **Changelog Generation Demo**
- Generate sample changelog entries from git commits
- Show different changelog formats (Keep a Changelog, conventional-changelog)
- Demonstrate automatic categorization of changes
- Show version numbering and semantic versioning
### 2. **Format Validation Demo**
- Validate existing changelog format compliance
- Show format inconsistencies and suggestions
- Demonstrate automated formatting fixes
- Show integration with release automation
### 3. **Integration Testing**
- Test changelog automation without affecting main workflow
- Validate changelog generation pipeline
- Test different commit message patterns
- Show error handling and recovery
### 4. **Performance Benchmarking**
- Measure changelog generation speed
- Test with large commit histories
- Show memory usage and optimization
- Benchmark different parsing strategies
cli-tool/components/commands/deployment/ci-setup.md
+322
View File
@@ -0,0 +1,322 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [platform] | --github-actions | --gitlab-ci | --jenkins | --full-setup
description: Setup comprehensive CI/CD pipeline with automated testing, building, and deployment
---
# CI/CD Pipeline Setup
Setup continuous integration pipeline: $ARGUMENTS
## Current Project Analysis
- Project type: @package.json or @setup.py or @go.mod or @pom.xml (detect language/framework)
- Existing workflows: !`find .github/workflows -name "*.yml" 2>/dev/null | head -3`
- Git branches: !`git branch -r | head -5`
- Dependencies: @package-lock.json or @requirements.txt or @go.sum (if exists)
- Build scripts: Check for build commands in package.json or Makefile
## Task
Implement comprehensive CI/CD following best practices: $ARGUMENTS
1. **Project Analysis**
- Identify the technology stack and deployment requirements
- Review existing build and test processes
- Understand deployment environments (dev, staging, prod)
- Assess current version control and branching strategy
2. **CI/CD Platform Selection**
- Choose appropriate CI/CD platform based on requirements:
- **GitHub Actions**: Native GitHub integration, extensive marketplace
- **GitLab CI**: Built-in GitLab, comprehensive DevOps platform
- **Jenkins**: Self-hosted, highly customizable, extensive plugins
- **CircleCI**: Cloud-based, optimized for speed
- **Azure DevOps**: Microsoft ecosystem integration
- **AWS CodePipeline**: AWS-native solution
3. **Repository Setup**
- Ensure proper `.gitignore` configuration
- Set up branch protection rules
- Configure merge requirements and reviews
- Establish semantic versioning strategy
4. **Build Pipeline Configuration**
**GitHub Actions Example:**
```yaml
name: CI/CD Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
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'
- run: npm ci
- run: npm run test
- run: npm run build
```
**GitLab CI Example:**
```yaml
stages:
- test
- build
- deploy
test:
stage: test
script:
- npm ci
- npm run test
cache:
paths:
- node_modules/
```
5. **Environment Configuration**
- Set up environment variables and secrets
- Configure different environments (dev, staging, prod)
- Implement environment-specific configurations
- Set up secure secret management
6. **Automated Testing Integration**
- Configure unit test execution
- Set up integration test running
- Implement E2E test execution
- Configure test reporting and coverage
**Multi-stage Testing:**
```yaml
test:
strategy:
matrix:
node-version: [16, 18, 20]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm test
```
7. **Code Quality Gates**
- Integrate linting and formatting checks
- Set up static code analysis (SonarQube, CodeClimate)
- Configure security vulnerability scanning
- Implement code coverage thresholds
8. **Build Optimization**
- Configure build caching strategies
- Implement parallel job execution
- Optimize Docker image builds
- Set up artifact management
**Caching Example:**
```yaml
- name: Cache node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
```
9. **Docker Integration**
- Create optimized Dockerfiles
- Set up multi-stage builds
- Configure container registry integration
- Implement security scanning for images
**Multi-stage Dockerfile:**
```dockerfile
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
FROM node:18-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
```
10. **Deployment Strategies**
- Implement blue-green deployment
- Set up canary releases
- Configure rolling updates
- Implement feature flags integration
11. **Infrastructure as Code**
- Use Terraform, CloudFormation, or similar tools
- Version control infrastructure definitions
- Implement infrastructure testing
- Set up automated infrastructure provisioning
12. **Monitoring and Observability**
- Set up application performance monitoring
- Configure log aggregation and analysis
- Implement health checks and alerting
- Set up deployment notifications
13. **Security Integration**
- Implement dependency vulnerability scanning
- Set up container security scanning
- Configure SAST (Static Application Security Testing)
- Implement secrets scanning
**Security Scanning Example:**
```yaml
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Snyk to check for vulnerabilities
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
```
14. **Database Migration Handling**
- Automate database schema migrations
- Implement rollback strategies
- Set up database seeding for testing
- Configure backup and recovery procedures
15. **Performance Testing Integration**
- Set up load testing in pipeline
- Configure performance benchmarks
- Implement performance regression detection
- Set up performance monitoring
16. **Multi-Environment Deployment**
- Configure staging environment deployment
- Set up production deployment with approvals
- Implement environment promotion workflow
- Configure environment-specific configurations
**Environment Deployment:**
```yaml
deploy-staging:
needs: test
if: github.ref == 'refs/heads/develop'
runs-on: ubuntu-latest
steps:
- name: Deploy to staging
run: |
# Deploy to staging environment
deploy-production:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- name: Deploy to production
run: |
# Deploy to production environment
```
17. **Rollback and Recovery**
- Implement automated rollback procedures
- Set up deployment verification tests
- Configure failure detection and alerts
- Document manual recovery procedures
18. **Notification and Reporting**
- Set up Slack/Teams integration for notifications
- Configure email alerts for failures
- Implement deployment status reporting
- Set up metrics dashboards
19. **Compliance and Auditing**
- Implement deployment audit trails
- Set up compliance checks (SOC 2, HIPAA, etc.)
- Configure approval workflows for sensitive deployments
- Document change management processes
20. **Pipeline Optimization**
- Monitor pipeline performance and costs
- Implement pipeline parallelization
- Optimize resource allocation
- Set up pipeline analytics and reporting
**Best Practices:**
1. **Fail Fast**: Implement early failure detection
2. **Parallel Execution**: Run independent jobs in parallel
3. **Caching**: Cache dependencies and build artifacts
4. **Security**: Never expose secrets in logs
5. **Documentation**: Document pipeline processes and procedures
6. **Monitoring**: Monitor pipeline health and performance
7. **Testing**: Test pipeline changes in feature branches
8. **Rollback**: Always have a rollback strategy
**Sample Complete Pipeline:**
```yaml
name: Full CI/CD Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
lint-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run test:coverage
- run: npm run build
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Security scan
run: npm audit --audit-level=high
deploy-staging:
needs: [lint-and-test, security-scan]
if: github.ref == 'refs/heads/develop'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy to staging
run: echo "Deploying to staging"
deploy-production:
needs: [lint-and-test, security-scan]
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v3
- name: Deploy to production
run: echo "Deploying to production"
```
Start with basic CI and gradually add more sophisticated features as your team and project mature.
cli-tool/components/commands/deployment/containerize-application.md
+92
View File
@@ -0,0 +1,92 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [application-type] | --node | --python | --java | --go | --multi-stage
description: Containerize application with optimized Docker configuration, security, and multi-stage builds
---
# Application Containerization
Containerize application for deployment: $ARGUMENTS
## Current Application Analysis
- Application type: @package.json or @setup.py or @go.mod or @pom.xml (detect runtime)
- Existing Docker: @Dockerfile or @docker-compose.yml (if exists)
- Dependencies: !`find . -name "*requirements*.txt" -o -name "package*.json" -o -name "go.mod" | head -3`
- Port configuration: !`grep -r "PORT\|listen\|bind" src/ 2>/dev/null | head -3 || echo "Port detection needed"`
- Build tools: @Makefile or build scripts detection
## Task
Implement production-ready containerization strategy:
1. **Application Analysis and Containerization Strategy**
- Analyze application architecture and runtime requirements
- Identify application dependencies and external services
- Determine optimal base image and runtime environment
- Plan multi-stage build strategy for optimization
- Assess security requirements and compliance needs
2. **Dockerfile Creation and Optimization**
- Create comprehensive Dockerfile with multi-stage builds
- Select minimal base images (Alpine, distroless, or slim variants)
- Configure proper layer caching and build optimization
- Implement security best practices (non-root user, minimal attack surface)
- Set up proper file permissions and ownership
3. **Build Process Configuration**
- Configure .dockerignore file to exclude unnecessary files
- Set up build arguments and environment variables
- Implement build-time dependency installation and cleanup
- Configure application bundling and asset optimization
- Set up proper build context and file structure
4. **Runtime Configuration**
- Configure application startup and health checks
- Set up proper signal handling and graceful shutdown
- Configure logging and output redirection
- Set up environment-specific configuration management
- Configure resource limits and performance tuning
5. **Security Hardening**
- Run application as non-root user with minimal privileges
- Configure security scanning and vulnerability assessment
- Implement secrets management and secure credential handling
- Set up network security and firewall rules
- Configure security policies and access controls
6. **Docker Compose Configuration**
- Create docker-compose.yml for local development
- Configure service dependencies and networking
- Set up volume mounting and data persistence
- Configure environment variables and secrets
- Set up development vs production configurations
7. **Container Orchestration Preparation**
- Prepare configurations for Kubernetes deployment
- Create deployment manifests and service definitions
- Configure ingress and load balancing
- Set up persistent volumes and storage classes
- Configure auto-scaling and resource management
8. **Monitoring and Observability**
- Configure application metrics and health endpoints
- Set up logging aggregation and centralized logging
- Configure distributed tracing and monitoring
- Set up alerting and notification systems
- Configure performance monitoring and profiling
9. **CI/CD Integration**
- Configure automated Docker image building
- Set up image scanning and security validation
- Configure image registry and artifact management
- Set up automated deployment pipelines
- Configure rollback and blue-green deployment strategies
10. **Testing and Validation**
- Test container builds and functionality
- Validate security configurations and compliance
- Test deployment in different environments
- Validate performance and resource utilization
- Test backup and disaster recovery procedures
- Create documentation for container deployment and management
cli-tool/components/commands/deployment/deployment-monitoring.md
+1227
View File
File diff suppressed because it is too large Load Diff
cli-tool/components/commands/deployment/hotfix-deploy.md
+282
View File
@@ -0,0 +1,282 @@
---
allowed-tools: Read, Edit, Bash
argument-hint: [hotfix-type] | --security | --critical | --rollback-ready | --emergency
description: Deploy critical hotfixes with emergency procedures, validation, and rollback capabilities
---
# Emergency Hotfix Deployment
Deploy critical hotfix: $ARGUMENTS
## Current Production State
- Current version: !`git describe --tags --abbrev=0 2>/dev/null || echo "No tags found"`
- Production branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -5`
- Deployment status: !`curl -s https://api.example.com/health 2>/dev/null | jq -r '.version // "Unknown"' || echo "Health check failed"`
- Staging environment: Check for staging deployment capabilities
## Emergency Response Protocol
Execute emergency hotfix deployment: $ARGUMENTS
1. **Emergency Assessment and Triage**
- Assess the severity and impact of the issue
- Determine if a hotfix is necessary or if it can wait
- Identify affected systems and user impact
- Estimate time sensitivity and business impact
- Document the incident and decision rationale
2. **Incident Response Setup**
- Create incident tracking in your incident management system
- Set up war room or communication channel
- Notify stakeholders and on-call team members
- Establish clear communication protocols
- Document initial incident details and timeline
3. **Branch and Environment Setup**
```bash
# Create hotfix branch from production tag
git fetch --tags
git checkout tags/v1.2.3 # Latest production version
git checkout -b hotfix/critical-auth-fix
# Alternative: Branch from main if using trunk-based development
git checkout main
git pull origin main
git checkout -b hotfix/critical-auth-fix
```
4. **Rapid Development Process**
- Keep changes minimal and focused on the critical issue only
- Avoid refactoring, optimization, or unrelated improvements
- Use well-tested patterns and established approaches
- Add minimal logging for troubleshooting purposes
- Follow existing code conventions and patterns
5. **Accelerated Testing**
```bash
# Run focused tests related to the fix
npm test -- --testPathPattern=auth
npm run test:security
# Manual testing checklist
# [ ] Core functionality works correctly
# [ ] Hotfix resolves the critical issue
# [ ] No new issues introduced
# [ ] Critical user flows remain functional
```
6. **Fast-Track Code Review**
- Get expedited review from senior team member
- Focus review on security and correctness
- Use pair programming if available and time permits
- Document review decisions and rationale quickly
- Ensure proper approval process even under time pressure
7. **Version and Tagging**
```bash
# Update version for hotfix
# 1.2.3 -> 1.2.4 (patch version)
# or 1.2.3 -> 1.2.3-hotfix.1 (hotfix identifier)
# Commit with detailed message
git add .
git commit -m "hotfix: fix critical authentication vulnerability
- Fix password validation logic
- Resolve security issue allowing bypass
- Minimal change to reduce deployment risk
Fixes: #1234"
# Tag the hotfix version
git tag -a v1.2.4 -m "Hotfix v1.2.4: Critical auth security fix"
git push origin hotfix/critical-auth-fix
git push origin v1.2.4
```
8. **Staging Deployment and Validation**
```bash
# Deploy to staging environment for final validation
./deploy-staging.sh v1.2.4
# Critical path testing
curl -X POST staging.example.com/api/auth/login \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","password":"testpass"}'
# Run smoke tests
npm run test:smoke:staging
```
9. **Production Deployment Strategy**
**Blue-Green Deployment:**
```bash
# Deploy to blue environment
./deploy-blue.sh v1.2.4
# Validate blue environment health
./health-check-blue.sh
# Switch traffic to blue environment
./switch-to-blue.sh
# Monitor deployment metrics
./monitor-deployment.sh
```
**Rolling Deployment:**
```bash
# Deploy to subset of servers first
./deploy-rolling.sh v1.2.4 --batch-size 1
# Monitor each batch deployment
./monitor-batch.sh
# Continue with next batch if healthy
./deploy-next-batch.sh
```
10. **Pre-Deployment Checklist**
```bash
# Verify all prerequisites are met
# [ ] Database backup completed successfully
# [ ] Rollback plan documented and ready
# [ ] Monitoring alerts configured and active
# [ ] Team members standing by for support
# [ ] Communication channels established
# Execute production deployment
./deploy-production.sh v1.2.4
# Run immediate post-deployment validation
./validate-hotfix.sh
```
11. **Real-Time Monitoring**
```bash
# Monitor key application metrics
watch -n 10 'curl -s https://api.example.com/health | jq .'
# Monitor error rates and logs
tail -f /var/log/app/error.log | grep -i "auth"
# Track critical metrics:
# - Response times and latency
# - Error rates and exception counts
# - User authentication success rates
# - System resource usage (CPU, memory)
```
12. **Post-Deployment Validation**
```bash
# Run comprehensive validation tests
./test-critical-paths.sh
# Test user authentication functionality
curl -X POST https://api.example.com/auth/login \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","password":"testpass"}'
# Validate security fix effectiveness
./security-validation.sh
# Check overall system performance
./performance-check.sh
```
13. **Communication and Status Updates**
- Provide regular status updates to stakeholders
- Use consistent communication channels
- Document deployment progress and results
- Update incident tracking systems
- Notify relevant teams of deployment completion
14. **Rollback Procedures**
```bash
# Automated rollback script
#!/bin/bash
PREVIOUS_VERSION="v1.2.3"
if [ "$1" = "rollback" ]; then
echo "Rolling back to $PREVIOUS_VERSION"
./deploy-production.sh $PREVIOUS_VERSION
./validate-rollback.sh
echo "Rollback completed successfully"
fi
# Manual rollback steps if automation fails:
# 1. Switch load balancer back to previous version
# 2. Validate previous version health and functionality
# 3. Monitor system stability after rollback
# 4. Communicate rollback status to team
```
15. **Post-Deployment Monitoring Period**
- Monitor system for 2-4 hours after deployment
- Watch error rates and performance metrics closely
- Check user feedback and support ticket volume
- Validate that the hotfix resolves the original issue
- Document any issues or unexpected behaviors
16. **Documentation and Incident Reporting**
- Document the complete hotfix process and timeline
- Record lessons learned and process improvements
- Update incident management systems with resolution
- Create post-incident review materials
- Share knowledge with team for future reference
17. **Merge Back to Main Branch**
```bash
# After successful hotfix deployment and validation
git checkout main
git pull origin main
git merge hotfix/critical-auth-fix
git push origin main
# Clean up hotfix branch
git branch -d hotfix/critical-auth-fix
git push origin --delete hotfix/critical-auth-fix
```
18. **Post-Incident Activities**
- Schedule and conduct post-incident review meeting
- Update runbooks and emergency procedures
- Identify and implement process improvements
- Update monitoring and alerting configurations
- Plan preventive measures to avoid similar issues
**Hotfix Best Practices:**
- **Keep It Simple:** Make minimal changes focused only on the critical issue
- **Test Thoroughly:** Maintain testing standards even under time pressure
- **Communicate Clearly:** Keep all stakeholders informed throughout the process
- **Monitor Closely:** Watch the fix carefully in production environment
- **Document Everything:** Record all decisions and actions for post-incident review
- **Plan for Rollback:** Always have a tested way to revert changes quickly
- **Learn and Improve:** Use each incident to strengthen processes and procedures
**Emergency Escalation Guidelines:**
```bash
# Emergency contact information
ON_CALL_ENGINEER="+1-555-0123"
SENIOR_ENGINEER="+1-555-0124"
ENGINEERING_MANAGER="+1-555-0125"
INCIDENT_COMMANDER="+1-555-0126"
# Escalation timeline thresholds:
# 15 minutes: Escalate to senior engineer
# 30 minutes: Escalate to engineering manager
# 60 minutes: Escalate to incident commander
```
**Important Reminders:**
- Hotfixes should only be used for genuine production emergencies
- When in doubt about severity, follow the normal release process
- Always prioritize system stability over speed of deployment
- Maintain clear audit trails for all emergency changes
- Regular drills help ensure team readiness for real emergencies
cli-tool/components/commands/deployment/prepare-release.md
+356
View File
@@ -0,0 +1,356 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [version-type] | patch | minor | major | --pre-release | --hotfix
description: Prepare and validate release packages with comprehensive testing, documentation, and automation
---
# Release Preparation
Prepare and validate release: $ARGUMENTS
## Current Release Context
- Current version: !`git describe --tags --abbrev=0 2>/dev/null || echo "No previous releases"`
- Package version: @package.json or @setup.py or @pyproject.toml or @go.mod (if exists)
- Unreleased changes: !`git log $(git describe --tags --abbrev=0)..HEAD --oneline 2>/dev/null | wc -l || echo "All commits"`
- Branch status: !`git status --porcelain | wc -l || echo "0"` uncommitted changes
- Build status: !`npm test 2>/dev/null || python -m pytest 2>/dev/null || go test ./... 2>/dev/null || echo "Test framework detection needed"`
## Task
Systematic release preparation: $ARGUMENTS
1. **Release Planning and Validation**
- Determine release version number (semantic versioning)
- Review and validate all features included in release
- Check that all planned issues and features are complete
- Verify release criteria and acceptance requirements
2. **Pre-Release Checklist**
- Ensure all tests are passing (unit, integration, E2E)
- Verify code coverage meets project standards
- Complete security vulnerability scanning
- Perform performance testing and validation
- Review and approve all pending pull requests
3. **Version Management**
```bash
# Check current version
git describe --tags --abbrev=0
# Determine next version (semantic versioning)
# MAJOR.MINOR.PATCH
# MAJOR: Breaking changes
# MINOR: New features (backward compatible)
# PATCH: Bug fixes (backward compatible)
# Example version updates
# 1.2.3 -> 1.2.4 (patch)
# 1.2.3 -> 1.3.0 (minor)
# 1.2.3 -> 2.0.0 (major)
```
4. **Code Freeze and Branch Management**
```bash
# Create release branch from main
git checkout main
git pull origin main
git checkout -b release/v1.2.3
# Alternative: Use main branch directly for smaller releases
# Ensure no new features are merged during release process
```
5. **Version Number Updates**
- Update package.json, setup.py, or equivalent version files
- Update version in application configuration
- Update version in documentation and README
- Update API version if applicable
```bash
# Node.js projects
npm version patch # or minor, major
# Python projects
# Update version in setup.py, __init__.py, or pyproject.toml
# Manual version update
sed -i 's/"version": "1.2.2"/"version": "1.2.3"/' package.json
```
6. **Changelog Generation**
```markdown
# CHANGELOG.md
## [1.2.3] - 2024-01-15
### Added
- New user authentication system
- Dark mode support for UI
- API rate limiting functionality
### Changed
- Improved database query performance
- Updated user interface design
- Enhanced error handling
### Fixed
- Fixed memory leak in background tasks
- Resolved issue with file upload validation
- Fixed timezone handling in date calculations
### Security
- Updated dependencies with security patches
- Improved input validation and sanitization
```
7. **Documentation Updates**
- Update API documentation with new endpoints
- Revise user documentation and guides
- Update installation and deployment instructions
- Review and update README.md
- Update migration guides if needed
8. **Dependency Management**
```bash
# Update and audit dependencies
npm audit fix
npm update
# Python
pip-audit
pip freeze > requirements.txt
# Review security vulnerabilities
npm audit
snyk test
```
9. **Build and Artifact Generation**
```bash
# Clean build environment
npm run clean
rm -rf dist/ build/
# Build production artifacts
npm run build
# Verify build artifacts
ls -la dist/
# Test built artifacts
npm run test:build
```
10. **Testing and Quality Assurance**
- Run comprehensive test suite
- Perform manual testing of critical features
- Execute regression testing
- Conduct user acceptance testing
- Validate in staging environment
```bash
# Run all tests
npm test
npm run test:integration
npm run test:e2e
# Check code coverage
npm run test:coverage
# Performance testing
npm run test:performance
```
11. **Security and Compliance Verification**
- Run security scans and penetration testing
- Verify compliance with security standards
- Check for exposed secrets or credentials
- Validate data protection and privacy measures
12. **Release Notes Preparation**
```markdown
# Release Notes v1.2.3
## 🎉 What's New
- **Dark Mode**: Users can now switch to dark mode in settings
- **Enhanced Security**: Improved authentication with 2FA support
- **Performance**: 40% faster page load times
## 🔧 Improvements
- Better error messages for form validation
- Improved mobile responsiveness
- Enhanced accessibility features
## 🐛 Bug Fixes
- Fixed issue with file downloads in Safari
- Resolved memory leak in background tasks
- Fixed timezone display issues
## 📚 Documentation
- Updated API documentation
- New user onboarding guide
- Enhanced troubleshooting section
## 🔄 Migration Guide
- No breaking changes in this release
- Automatic database migrations included
- See [Migration Guide](link) for details
```
13. **Release Tagging and Versioning**
```bash
# Create annotated tag
git add .
git commit -m "chore: prepare release v1.2.3"
git tag -a v1.2.3 -m "Release version 1.2.3
Features:
- Dark mode support
- Enhanced authentication
Bug fixes:
- Fixed file upload issues
- Resolved memory leaks"
# Push tag to remote
git push origin v1.2.3
git push origin release/v1.2.3
```
14. **Deployment Preparation**
- Prepare deployment scripts and configurations
- Update environment variables and secrets
- Plan deployment strategy (blue-green, rolling, canary)
- Set up monitoring and alerting for release
- Prepare rollback procedures
15. **Staging Environment Validation**
```bash
# Deploy to staging
./deploy-staging.sh v1.2.3
# Run smoke tests
npm run test:smoke:staging
# Manual validation checklist
# [ ] User login/logout
# [ ] Core functionality
# [ ] New features
# [ ] Performance metrics
# [ ] Security checks
```
16. **Production Deployment Planning**
- Schedule deployment window
- Notify stakeholders and users
- Prepare maintenance mode if needed
- Set up deployment monitoring
- Plan communication strategy
17. **Release Automation Setup**
```yaml
# GitHub Actions Release Workflow
name: Release
on:
push:
tags:
- 'v*'
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run build
- name: Create Release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: Release ${{ github.ref }}
draft: false
prerelease: false
```
18. **Communication and Announcements**
- Prepare release announcement
- Update status page and documentation
- Notify customers and users
- Share on relevant communication channels
- Update social media and marketing materials
19. **Post-Release Monitoring**
- Monitor application performance and errors
- Track user adoption of new features
- Monitor system metrics and alerts
- Collect user feedback and issues
- Prepare hotfix procedures if needed
20. **Release Retrospective**
- Document lessons learned
- Review release process effectiveness
- Identify improvement opportunities
- Update release procedures
- Plan for next release cycle
**Release Types and Considerations:**
**Patch Release (1.2.3 → 1.2.4):**
- Bug fixes only
- No new features
- Minimal testing required
- Quick deployment
**Minor Release (1.2.3 → 1.3.0):**
- New features (backward compatible)
- Enhanced functionality
- Comprehensive testing
- User communication needed
**Major Release (1.2.3 → 2.0.0):**
- Breaking changes
- Significant new features
- Migration guide required
- Extended testing period
- User training and support
**Hotfix Release:**
```bash
# Emergency hotfix process
git checkout main
git pull origin main
git checkout -b hotfix/critical-bug-fix
# Make minimal fix
git add .
git commit -m "hotfix: fix critical security vulnerability"
# Fast-track testing and deployment
npm test
git tag -a v1.2.4-hotfix.1 -m "Hotfix for critical security issue"
git push origin hotfix/critical-bug-fix
git push origin v1.2.4-hotfix.1
```
Remember to:
- Test everything thoroughly before release
- Communicate clearly with all stakeholders
- Have rollback procedures ready
- Monitor the release closely after deployment
- Document everything for future releases
cli-tool/components/commands/deployment/rollback-deploy.md
+144
View File
File diff suppressed because one or more lines are too long
cli-tool/components/commands/deployment/setup-automated-releases.md
+142
View File
@@ -0,0 +1,142 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [release-type] | --semantic | --conventional-commits | --github-actions | --full-automation
description: Setup automated release workflows with semantic versioning, conventional commits, and comprehensive automation
---
# Automated Release System
Setup automated release workflows: $ARGUMENTS
## Current Project Analysis
- Project structure: @package.json or @setup.py or @go.mod (detect project type)
- Existing workflows: !`find .github/workflows -name "*.yml" 2>/dev/null | head -3`
- Current versioning: @package.json version or git tags analysis
- Commit patterns: !`git log --oneline -20 | grep -E "^(feat|fix|docs|style|refactor|test|chore)" | wc -l || echo "0"` conventional commits
- Release history: !`git tag -l | wc -l || echo "0"` existing releases
## Task
Implement comprehensive automated release system:
1. **Analyze Repository Structure**
- Detect project type (Node.js, Python, Go, etc.)
- Check for existing CI/CD workflows
- Identify current versioning approach
- Review existing release processes
2. **Create Version Tracking**
- For Node.js: Use package.json version field
- For Python: Use __version__ in __init__.py or pyproject.toml
- For Go: Use version in go.mod
- For others: Create version.txt file
- Ensure version follows semantic versioning (MAJOR.MINOR.PATCH)
3. **Set Up Conventional Commits**
- Create CONTRIBUTING.md with commit conventions:
- `feat:` for new features (minor bump)
- `fix:` for bug fixes (patch bump)
- `feat!:` or `BREAKING CHANGE:` for breaking changes (major bump)
- `docs:`, `chore:`, `style:`, `refactor:`, `test:` for non-releasing changes
- Include examples and guidelines for each type
4. **Create Pull Request Template**
- Add `.github/pull_request_template.md`
- Include conventional commit reminder
- Add checklist for common requirements
- Reference contributing guidelines
5. **Create Release Workflow**
- Add `.github/workflows/release.yml`:
- Trigger on push to main branch
- Analyze commits since last release
- Determine version bump type
- Update version in appropriate file(s)
- Generate release notes from commits
- Update CHANGELOG.md
- Create git tag
- Create GitHub Release
- Attach distribution artifacts
- Include manual trigger option for forced releases
6. **Create PR Validation Workflow**
- Add `.github/workflows/pr-check.yml`:
- Validate PR title follows conventional format
- Check commit messages
- Provide feedback on version impact
- Run tests and quality checks
7. **Configure GitHub Release Notes**
- Create `.github/release.yml`
- Define categories for different change types
- Configure changelog exclusions
- Set up contributor recognition
8. **Update Documentation**
- Add release badges to README:
- Current version badge
- Latest release badge
- Build status badge
- Document release process
- Add link to CONTRIBUTING.md
- Explain version bump rules
9. **Set Up Changelog Management**
- Ensure CHANGELOG.md follows Keep a Changelog format
- Add [Unreleased] section for upcoming changes
- Configure automatic changelog updates
- Set up changelog categories
10. **Configure Branch Protection**
- Recommend branch protection rules:
- Require PR reviews
- Require status checks
- Require conventional PR titles
- Dismiss stale reviews
- Document recommended settings
11. **Add Security Scanning**
- Set up Dependabot for dependency updates
- Configure security alerts
- Add security policy if needed
12. **Test the System**
- Create example PR with conventional title
- Verify PR checks work correctly
- Test manual release trigger
- Validate changelog generation
Arguments: $ARGUMENTS
### Additional Considerations
**For Monorepos:**
- Set up independent versioning per package
- Configure changelog per package
- Use conventional commits scopes
**For Libraries:**
- Include API compatibility checks
- Generate API documentation
- Add upgrade guides for breaking changes
**For Applications:**
- Include Docker image versioning
- Set up deployment triggers
- Add rollback procedures
**Best Practices:**
- Always create release branches for hotfixes
- Use release candidates for major versions
- Maintain upgrade guides
- Keep releases small and frequent
- Document rollback procedures
This automated release system provides:
- ✅ Consistent versioning
- ✅ Automatic changelog generation
- ✅ Clear contribution guidelines
- ✅ Professional release notes
- ✅ Reduced manual work
- ✅ Better project maintainability
cli-tool/components/commands/deployment/setup-kubernetes-deployment.md
+92
View File
@@ -0,0 +1,92 @@
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: [deployment-type] | --microservices | --monolith | --stateful | --full-stack | --production-ready
description: Configure comprehensive Kubernetes deployment with manifests, security, scaling, and production best practices
---
# Kubernetes Deployment Configuration
Configure Kubernetes deployment: $ARGUMENTS
## Current Environment Analysis
- Application type: @package.json or @Dockerfile (detect containerization readiness)
- Existing K8s config: !`find . -name "*.yaml" -o -name "*.yml" | grep -E "(k8s|kubernetes|deployment|service)" | head -3`
- Cluster access: !`kubectl cluster-info 2>/dev/null | head -2 || echo "No cluster access"`
- Container registry: @docker-compose.yml or check for registry configuration
- Resource requirements: Analysis needed based on application type
## Task
Implement production-ready Kubernetes deployment:
1. **Kubernetes Architecture Planning**
- Analyze application architecture and deployment requirements
- Define resource requirements (CPU, memory, storage, network)
- Plan namespace organization and multi-tenancy strategy
- Assess high availability and disaster recovery requirements
- Define scaling strategies and performance requirements
2. **Cluster Setup and Configuration**
- Set up Kubernetes cluster (managed or self-hosted)
- Configure cluster networking and CNI plugin
- Set up cluster storage classes and persistent volumes
- Configure cluster security policies and RBAC
- Set up cluster monitoring and logging infrastructure
3. **Application Containerization**
- Ensure application is properly containerized
- Optimize container images for Kubernetes deployment
- Configure multi-stage builds and security scanning
- Set up container registry and image management
- Configure image pull policies and secrets
4. **Kubernetes Manifest Creation**
- Create Deployment manifests with proper resource limits
- Set up Service manifests for internal and external communication
- Configure ConfigMaps and Secrets for configuration management
- Create PersistentVolumeClaims for data storage
- Set up NetworkPolicies for security and isolation
5. **Load Balancing and Ingress**
- Configure Ingress controllers and routing rules
- Set up SSL/TLS termination and certificate management
- Configure load balancing strategies and session affinity
- Set up external DNS and domain management
- Configure traffic management and canary deployments
6. **Auto-scaling Configuration**
- Set up Horizontal Pod Autoscaler (HPA) based on metrics
- Configure Vertical Pod Autoscaler (VPA) for resource optimization
- Set up Cluster Autoscaler for node scaling
- Configure custom metrics and scaling policies
- Set up resource quotas and limits
7. **Health Checks and Monitoring**
- Configure liveness and readiness probes
- Set up startup probes for slow-starting applications
- Configure health check endpoints and monitoring
- Set up application metrics collection
- Configure alerting and notification systems
8. **Security and Compliance**
- Configure Pod Security Standards and policies
- Set up network segmentation and security policies
- Configure service accounts and RBAC permissions
- Set up secret management and rotation
- Configure security scanning and compliance monitoring
9. **CI/CD Integration**
- Set up automated Kubernetes deployment pipelines
- Configure GitOps workflows with ArgoCD or Flux
- Set up automated testing in Kubernetes environments
- Configure blue-green and canary deployment strategies
- Set up rollback and disaster recovery procedures
10. **Operations and Maintenance**
- Set up cluster maintenance and update procedures
- Configure backup and disaster recovery strategies
- Set up cost optimization and resource management
- Create operational runbooks and troubleshooting guides
- Train team on Kubernetes operations and best practices
- Set up cluster lifecycle management and governance