ccjk 14.2.2 → 15.1.0

package/dist/templates/common/workflow/continuousDelivery/en/continuous-delivery.md

@@ -1,628 +0,0 @@
----
-description: Continuous Delivery Pipeline - Automated build, test, and deploy for software ready to release anytime
-allowed-tools: Read(**), Write(**), Exec(npm run build, npm test, docker build, docker push, kubectl apply)
-argument-hint: [--env <staging|production>] [--skip-tests] [--rollback] [--canary]
-# examples:
-#   - /continuous-delivery                      # Deploy to staging
-#   - /continuous-delivery --env production     # Deploy to production
-#   - /continuous-delivery --canary             # Canary release
-#   - /continuous-delivery --rollback           # Rollback to previous version
----
-
-# Continuous Delivery Pipeline
-
-Based on Jez Humble and David Farley's *Continuous Delivery* and modern DevOps practices for automated delivery pipeline.
-
----
-
-## Core Philosophy
-
-**Continuous Delivery (CD)**:
-- Code is always in a releasable state
-- Automated build, test, and deployment process
-- Fast, reliable, repeatable releases
-- Reduce release risk, increase delivery frequency
-
-**Key Principles**:
-1. **Automate Everything**: From code commit to production deployment
-2. **Fast Feedback**: Every commit triggers complete validation
-3. **Small Batch Releases**: Frequent small changes reduce risk
-4. **Environment Consistency**: Dev, test, prod configs are identical
-5. **Observability**: Full-stack monitoring and log tracing
-
----
-
-## Pipeline Stages
-
-### Stage 1: Source Control
-
-**Triggers**:
-- Git push to main branch
-- Pull Request merge
-- Scheduled builds (nightly)
-
-```yaml
-# .github/workflows/cd-pipeline.yml
-name: Continuous Delivery Pipeline
-
-on:
-  push:
-    branches: [main, develop]
-  pull_request:
-    branches: [main]
-  schedule:
-    - cron: '0 2 * * *'  # Daily at 2 AM
-```
-
-**Checks**:
-- ✅ Code committed to version control
-- ✅ Commit message follows convention
-- ✅ Branch protection rules configured
-
----
-
-### Stage 2: Build
-
-**Goal**: Compile source code into deployable artifacts
-
-```bash
-# 1. Install dependencies
-npm ci  # Use ci instead of install for consistent versions
-
-# 2. Code checks
-npm run lint
-npm run type-check
-
-# 3. Build
-npm run build
-
-# 4. Generate version
-VERSION=$(git describe --tags --always)
-echo "Building version: $VERSION"
-```
-
-**Build Optimization**:
-```dockerfile
-# Dockerfile - Multi-stage build
-FROM node:20-alpine AS builder
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci --only=production
-COPY . .
-RUN npm run build
-
-FROM node:20-alpine AS runtime
-WORKDIR /app
-COPY --from=builder /app/dist ./dist
-COPY --from=builder /app/node_modules ./node_modules
-EXPOSE 3000
-CMD ["node", "dist/index.js"]
-```
-
-**Checks**:
-- ✅ Build succeeds without errors
-- ✅ Artifact size reasonable (< 500MB)
-- ✅ Version tagged
-- ✅ Build time < 10 minutes
-
----
-
-### Stage 3: Test
-
-**Goal**: Automated validation of code quality and functionality
-
-#### 3.1 Unit Tests
-
-```bash
-npm run test:unit -- --coverage --ci
-
-# Coverage requirements
-# Statements   : 80%
-# Branches     : 75%
-# Functions    : 80%
-# Lines        : 80%
-```
-
-#### 3.2 Integration Tests
-
-```bash
-# Start test database
-docker-compose -f docker-compose.test.yml up -d
-
-# Run integration tests
-npm run test:integration
-
-# Cleanup
-docker-compose -f docker-compose.test.yml down
-```
-
-#### 3.3 E2E Tests
-
-```bash
-# Start application
-npm run start:test &
-APP_PID=$!
-
-# Wait for app ready
-wait-on http://localhost:3000/health
-
-# Run E2E tests
-npm run test:e2e
-
-# Cleanup
-kill $APP_PID
-```
-
-#### 3.4 Performance Tests
-
-```bash
-# Load testing with k6
-k6 run --vus 100 --duration 30s tests/load/api-test.js
-
-# Performance benchmarks
-# - P95 latency < 200ms
-# - Throughput > 1000 req/s
-# - Error rate < 0.1%
-```
-
-#### 3.5 Security Scan
-
-```bash
-# Dependency vulnerability scan
-npm audit --audit-level=moderate
-
-# Container image scan
-trivy image myapp:$VERSION
-
-# SAST static analysis
-sonar-scanner
-```
-
-**Checks**:
-- ✅ All tests pass
-- ✅ Coverage meets threshold
-- ✅ No high-severity vulnerabilities
-- ✅ Performance metrics meet requirements
-
----
-
-### Stage 4: Package
-
-**Goal**: Create immutable deployment artifacts
-
-```bash
-# 1. Build Docker image
-docker build -t myapp:$VERSION .
-
-# 2. Tag image
-docker tag myapp:$VERSION registry.example.com/myapp:$VERSION
-docker tag myapp:$VERSION registry.example.com/myapp:latest
-
-# 3. Push to registry
-docker push registry.example.com/myapp:$VERSION
-docker push registry.example.com/myapp:latest
-
-# 4. Generate SBOM (Software Bill of Materials)
-syft registry.example.com/myapp:$VERSION -o spdx-json > sbom.json
-
-# 5. Sign image
-cosign sign registry.example.com/myapp:$VERSION
-```
-
-**Artifact Metadata**:
-```json
-{
-  "artifact": {
-    "name": "myapp",
-    "version": "v1.2.3",
-    "commit": "abc123",
-    "buildTime": "2025-02-04T10:30:00Z",
-    "registry": "registry.example.com",
-    "digest": "sha256:...",
-    "size": "245MB"
-  }
-}
-```
-
-**Checks**:
-- ✅ Image built successfully
-- ✅ Image pushed to registry
-- ✅ Image signed and verified
-- ✅ SBOM generated
-
----
-
-### Stage 5: Deploy
-
-**Goal**: Deploy artifacts to target environment
-
-#### 5.1 Staging Deployment
-
-```bash
-# 1. Update Kubernetes config
-kubectl set image deployment/myapp \
-  myapp=registry.example.com/myapp:$VERSION \
-  -n staging
-
-# 2. Wait for rollout
-kubectl rollout status deployment/myapp -n staging
-
-# 3. Health check
-kubectl get pods -n staging -l app=myapp
-curl https://staging.example.com/health
-
-# 4. Smoke tests
-npm run test:smoke -- --env staging
-```
-
-#### 5.2 Production Deployment
-
-**Blue-Green Deployment**:
-
-```bash
-# 1. Deploy new version to Green environment
-kubectl apply -f k8s/deployment-green.yml
-
-# 2. Wait for Green ready
-kubectl wait --for=condition=available deployment/myapp-green
-
-# 3. Run validation tests
-npm run test:smoke -- --env green
-
-# 4. Switch traffic to Green
-kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'
-
-# 5. Monitor for 5 minutes
-sleep 300
-
-# 6. If healthy, delete Blue
-kubectl delete deployment myapp-blue
-```
-
-**Canary Deployment**:
-
-```bash
-# 1. Deploy canary version (5% traffic)
-kubectl apply -f k8s/canary.yml
-
-# 2. Monitor key metrics
-while true; do
-  ERROR_RATE=$(prometheus-query 'rate(http_errors[5m])')
-  if [ $ERROR_RATE -gt 0.01 ]; then
-    echo "Error rate too high, rolling back"
-    kubectl delete -f k8s/canary.yml
-    exit 1
-  fi
-  sleep 60
-done
-
-# 3. Gradually increase traffic: 5% -> 25% -> 50% -> 100%
-kubectl patch deployment myapp-canary -p '{"spec":{"replicas":5}}'
-```
-
-**Checks**:
-- ✅ Deployment successful
-- ✅ Health checks pass
-- ✅ Smoke tests pass
-- ✅ Key metrics normal
-
----
-
-### Stage 6: Monitor
-
-**Goal**: Real-time monitoring of application health and business metrics
-
-#### 6.1 Infrastructure Monitoring
-
-```yaml
-# Prometheus metrics
-metrics:
-  - name: http_requests_total
-    type: counter
-    help: Total HTTP requests
-
-  - name: http_request_duration_seconds
-    type: histogram
-    help: HTTP request latency
-
-  - name: app_errors_total
-    type: counter
-    help: Total application errors
-
-  - name: db_connections_active
-    type: gauge
-    help: Active database connections
-```
-
-#### 6.2 Log Aggregation
-
-```json
-// Structured logging
-{
-  "timestamp": "2025-02-04T10:30:00Z",
-  "level": "info",
-  "service": "myapp",
-  "version": "v1.2.3",
-  "traceId": "abc123",
-  "message": "User login successful",
-  "userId": "user-456",
-  "duration": 120
-}
-```
-
-#### 6.3 Alert Rules
-
-```yaml
-# Alertmanager configuration
-alerts:
-  - name: HighErrorRate
-    expr: rate(http_errors[5m]) > 0.05
-    severity: critical
-    message: "Error rate > 5% for 5 minutes"
-
-  - name: HighLatency
-    expr: histogram_quantile(0.95, http_request_duration_seconds) > 1
-    severity: warning
-    message: "P95 latency > 1s"
-
-  - name: LowAvailability
-    expr: up{job="myapp"} < 0.99
-    severity: critical
-    message: "Service availability < 99%"
-```
-
-#### 6.4 Business Metrics
-
-```typescript
-// Key business metrics
-const businessMetrics = {
-  dailyActiveUsers: 12500,
-  conversionRate: 0.032,
-  averageOrderValue: 89.50,
-  customerSatisfaction: 4.7
-}
-```
-
----
-
-### Stage 7: Rollback
-
-**Goal**: Quickly rollback to previous stable version
-
-```bash
-# 1. View deployment history
-kubectl rollout history deployment/myapp
-
-# 2. Rollback to previous version
-kubectl rollout undo deployment/myapp
-
-# 3. Rollback to specific version
-kubectl rollout undo deployment/myapp --to-revision=3
-
-# 4. Verify rollback
-kubectl rollout status deployment/myapp
-curl https://api.example.com/health
-
-# 5. Notify team
-slack-notify "🔄 Rolled back myapp to v1.2.2 due to high error rate"
-```
-
-**Auto-rollback Conditions**:
-- Error rate > 5%
-- P95 latency > 2 seconds
-- Health check failures
-- Critical business metric anomalies
-
----
-
-## Deployment Strategies
-
-### 1. Rolling Update
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: myapp
-spec:
-  replicas: 10
-  strategy:
-    type: RollingUpdate
-    rollingUpdate:
-      maxSurge: 2        # Max 2 extra pods
-      maxUnavailable: 1  # Max 1 pod unavailable
-```
-
-**Pros**:
-- Zero downtime
-- High resource efficiency
-- Simple implementation
-
-**Cons**:
-- Mixed versions coexist
-- Slower rollback
-
----
-
-### 2. Blue-Green Deployment
-
-```
-[Blue v1.0]  ← 100% traffic
-[Green v1.1] ← 0% traffic
-
-After switch:
-[Blue v1.0]  ← 0% traffic (kept for rollback)
-[Green v1.1] ← 100% traffic
-```
-
-**Pros**:
-- Instant switch
-- Fast rollback
-- Thorough testing
-
-**Cons**:
-- Requires double resources
-- Complex database migrations
-
----
-
-### 3. Canary Release
-
-```
-Phase 1: [v1.0: 95%] [v1.1: 5%]
-Phase 2: [v1.0: 75%] [v1.1: 25%]
-Phase 3: [v1.0: 50%] [v1.1: 50%]
-Phase 4: [v1.0: 0%]  [v1.1: 100%]
-```
-
-**Pros**:
-- Progressive rollout
-- Controlled risk
-- Real traffic validation
-
-**Cons**:
-- Complex implementation
-- Longer release time
-
----
-
-## Pipeline Configuration
-
-### Environment Configuration
-
-```yaml
-# config/environments.yml
-environments:
-  development:
-    url: http://localhost:3000
-    database: dev-db
-    replicas: 1
-
-  staging:
-    url: https://staging.example.com
-    database: staging-db
-    replicas: 3
-
-  production:
-    url: https://api.example.com
-    database: prod-db
-    replicas: 10
-    autoScale:
-      min: 10
-      max: 50
-      targetCPU: 70
-```
-
-### Quality Gates
-
-```yaml
-# Pre-deployment requirements
-quality-gates:
-  - name: test-coverage
-    threshold: 80
-    blocking: true
-
-  - name: code-quality
-    sonarqube:
-      bugs: 0
-      vulnerabilities: 0
-      code-smells: < 10
-    blocking: true
-
-  - name: performance
-    p95-latency: < 200ms
-    throughput: > 1000 rps
-    blocking: false
-```
-
----
-
-## Best Practices
-
-### 1. Version Management
-
-```bash
-# Semantic versioning
-MAJOR.MINOR.PATCH
-
-# Example
-v1.2.3
-  │ │ └─ Patch (bug fixes)
-  │ └─── Minor (new features, backward compatible)
-  └───── Major (breaking changes)
-```
-
-### 2. Configuration Management
-
-```typescript
-// ✅ Good: Externalized config
-const config = {
-  database: process.env.DATABASE_URL,
-  apiKey: process.env.API_KEY,
-  logLevel: process.env.LOG_LEVEL || 'info'
-}
-
-// ❌ Bad: Hardcoded config
-const config = {
-  database: 'postgres://localhost:5432/mydb',
-  apiKey: 'sk-1234567890'
-}
-```
-
-### 3. Database Migrations
-
-```bash
-# Backward-compatible migration strategy
-# Phase 1: Add new column (nullable)
-ALTER TABLE users ADD COLUMN email_verified BOOLEAN;
-
-# Phase 2: Deploy new code (supports both old and new columns)
-# Phase 3: Data migration
-UPDATE users SET email_verified = true WHERE email IS NOT NULL;
-
-# Phase 4: Add constraint
-ALTER TABLE users ALTER COLUMN email_verified SET NOT NULL;
-
-# Phase 5: Drop old column (next release)
-ALTER TABLE users DROP COLUMN old_email_field;
-```
-
-### 4. Feature Flags
-
-```typescript
-// Use feature flags to control new feature rollout
-if (featureFlags.isEnabled('new-checkout-flow', user)) {
-  return newCheckoutFlow()
-} else {
-  return legacyCheckoutFlow()
-}
-```
-
----
-
-## Command Options
-
-- `--env <staging|production>`: Specify deployment environment
-- `--skip-tests`: Skip test phase (emergency fixes only)
-- `--rollback`: Rollback to previous version
-- `--canary`: Use canary release strategy
-- `--dry-run`: Simulate deployment without executing
-
----
-
-## Success Metrics
-
-- ✅ Deployment frequency: Multiple times per day
-- ✅ Lead time for changes: < 1 hour
-- ✅ Change failure rate: < 15%
-- ✅ Mean time to recovery (MTTR): < 1 hour
-- ✅ Service availability: > 99.9%
-
----
-
-## References
-
-- Jez Humble & David Farley - *Continuous Delivery*
-- Gene Kim - *The DevOps Handbook*
-- Nicole Forsgren - *Accelerate*
-- Martin Fowler - *Continuous Integration*