藍綠部署與 Canary Release：
零 Downtime 上線策略

# 傳統部署（In-place deployment）
ssh production-server
git pull origin main
npm run build
pm2 restart app    # 這段時間：服務中斷！

# 問題：
# 1. 部署期間有 downtime（可能幾秒到幾分鐘）
# 2. 新版有 bug → 回滾需要重新部署（又是 downtime）
# 3. 用戶可能在操作到一半時遭遇中斷

# .github/workflows/blue-green-deploy.yml
name: Blue-Green Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build new image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push registry.example.com/myapp:${{ github.sha }}

      - name: Deploy to Green environment
        run: |
          kubectl set image deployment/myapp-green \
            web=registry.example.com/myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp-green

      - name: Run smoke tests on Green
        run: |
          GREEN_URL=$(kubectl get service myapp-green -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
          curl -f "$GREEN_URL/health" || exit 1
          ./scripts/smoke-test.sh "$GREEN_URL"

      - name: Switch traffic to Green
        run: |
          # 更新 Ingress 指向 Green service
          kubectl patch ingress myapp-ingress \
            --type='json' \
            -p='[{"op": "replace", "path": "/spec/rules/0/http/paths/0/backend/service/name", "value": "myapp-green"}]'

      - name: Monitor for 5 minutes
        run: sleep 300

      - name: Rename Green to Blue (for next deployment)
        run: |
          # 更新 label，讓下次部署知道哪個是「穩定版」
          kubectl label deployment myapp-green role=blue --overwrite
          kubectl label deployment myapp-blue role=green --overwrite

# stable-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
  labels:
    app: myapp
    version: stable
spec:
  replicas: 9        # 90% 流量
  template:
    metadata:
      labels:
        app: myapp
        version: stable
    spec:
      containers:
        - name: web
          image: myapp:1.0.0

---
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
  labels:
    app: myapp
    version: canary
spec:
  replicas: 1        # 10% 流量（1 out of 10 total pods）
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
        - name: web
          image: myapp:1.1.0

---
# service.yaml（同一個 Service 路由到兩個 Deployment）
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp         # 同時選中 stable 和 canary（pod 比例決定流量比例）
  ports:
    - port: 80
      targetPort: 3000

// lib/featureFlags.ts
type FeatureFlag = {
  enabled: boolean;
  rolloutPercentage: number;  // 0-100，向多少 % 用戶開放
  allowList?: string[];       // 特定用戶 ID 白名單
};

const flags: Record<string, FeatureFlag> = {
  'new-checkout-flow': {
    enabled: true,
    rolloutPercentage: 10,    // 先開 10% 用戶
    allowList: ['admin@example.com'],
  },
  'ai-recommendations': {
    enabled: false,           // 還沒準備好
    rolloutPercentage: 0,
  },
};

export function isFeatureEnabled(flagName: string, userId: string): boolean {
  const flag = flags[flagName];
  if (!flag || !flag.enabled) return false;

  // 白名單用戶永遠開啟
  if (flag.allowList?.includes(userId)) return true;

  // 根據 userId 的 hash 決定（確保同一個用戶永遠看到同樣結果）
  const hash = userId.split('').reduce((acc, char) => acc + char.charCodeAt(0), 0);
  return (hash % 100) < flag.rolloutPercentage;
}

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%        # 最多比 replicas 多 25% 的 Pod（新版）
    maxUnavailable: 0    # 零 downtime：不允許任何 Pod 不可用

# 10 個 Pod 的滾動過程：
# Step 1: 啟動 3 個新版 Pod → 共 13 個（10+3）
# Step 2: 關閉 3 個舊版 Pod → 共 10 個（7+3）
# Step 3: 啟動 3 個新版 Pod → 共 13 個（7+6）
# ...直到全部換完