[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MW0QBB1JB0MV2PXZVEFTH":3,"skill-same:01M71MW0QBB1JB0MV2PXZVEFTH":85},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M71MW0QBB1JB0MV2PXZVEFTH","deployment-patterns",null,"Use when setting up CI\u002FCD and deployment for a web app: rolling, blue-green or canary rollout, Docker images, health checks, rollback and readiness checklists. Hands-on patterns; for architecting multi-stage pipelines with approval and security gates use deployment-pipeline-design.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fdeployment-patterns\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fdeployment-patterns\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"deployment","deployment patterns","patterns","for","hands-on","canary","setting","security","CI\u002FCD","rollout","when","design","ci","up","blue-green","pipeline","green","deployment-pipeline","app","images","2026-11-10 10:56:23",false,"---\nname: deployment-patterns\ndescription: \"Use when setting up CI\u002FCD and deployment for a web app: rolling, blue-green or canary rollout, Docker images, health checks, rollback and readiness checklists. Hands-on patterns; for architecting multi-stage pipelines with approval and security gates use deployment-pipeline-design.\"\ntags: [\"devops\",\"deploy\",\"docker\"]\ntools: []\nlicense: MIT\nsource: https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC\nsource_path: \"skills\u002Fdeployment-patterns\"\nsource_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735\n---\n# Deployment Patterns\n\nProduction deployment workflows and CI\u002FCD best practices.\n\n## When to Activate\n\n- Setting up CI\u002FCD pipelines\n- Dockerizing an application\n- Planning deployment strategy (blue-green, canary, rolling)\n- Implementing health checks and readiness probes\n- Preparing for a production release\n- Configuring environment-specific settings\n\n## Deployment Strategies\n\n### Rolling Deployment (Default)\n\nReplace instances gradually — old and new versions run simultaneously during rollout.\n\n```\nInstance 1: v1 → v2  (update first)\nInstance 2: v1        (still running v1)\nInstance 3: v1        (still running v1)\n\nInstance 1: v2\nInstance 2: v1 → v2  (update second)\nInstance 3: v1\n\nInstance 1: v2\nInstance 2: v2\nInstance 3: v1 → v2  (update last)\n```\n\n**Pros:** Zero downtime, gradual rollout\n**Cons:** Two versions run simultaneously — requires backward-compatible changes\n**Use when:** Standard deployments, backward-compatible changes\n\n### Blue-Green Deployment\n\nRun two identical environments. Switch traffic atomically.\n\n```\nBlue  (v1) ← traffic\nGreen (v2)   idle, running new version\n\n# After verification:\nBlue  (v1)   idle (becomes standby)\nGreen (v2) ← traffic\n```\n\n**Pros:** Instant rollback (switch back to blue), clean cutover\n**Cons:** Requires 2x infrastructure during deployment\n**Use when:** Critical services, zero-tolerance for issues\n\n### Canary Deployment\n\nRoute a small percentage of traffic to the new version first.\n\n```\nv1: 95% of traffic\nv2:  5% of traffic  (canary)\n\n# If metrics look good:\nv1: 50% of traffic\nv2: 50% of traffic\n\n# Final:\nv2: 100% of traffic\n```\n\n**Pros:** Catches issues with real traffic before full rollout\n**Cons:** Requires traffic splitting infrastructure, monitoring\n**Use when:** High-traffic services, risky changes, feature flags\n\n## Docker\n\n### Multi-Stage Dockerfile (Node.js)\n\n```dockerfile\n# Stage 1: Install dependencies\nFROM node:22-alpine AS deps\nWORKDIR \u002Fapp\nCOPY package.json package-lock.json .\u002F\nRUN npm ci --production=false\n\n# Stage 2: Build\nFROM node:22-alpine AS builder\nWORKDIR \u002Fapp\nCOPY --from=deps \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCOPY . .\nRUN npm run build\nRUN npm prune --production\n\n# Stage 3: Production image\nFROM node:22-alpine AS runner\nWORKDIR \u002Fapp\n\nRUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001\nUSER appuser\n\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fdist .\u002Fdist\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fpackage.json .\u002F\n\nENV NODE_ENV=production\nEXPOSE 3000\n\nHEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \\\n  CMD wget --no-verbose --tries=1 --spider http:\u002F\u002Flocalhost:3000\u002Fhealth || exit 1\n\nCMD [\"node\", \"dist\u002Fserver.js\"]\n```\n\n### Multi-Stage Dockerfile (Go)\n\n```dockerfile\nFROM golang:1.22-alpine AS builder\nWORKDIR \u002Fapp\nCOPY go.mod go.sum .\u002F\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 GOOS=linux go build -ldflags=\"-s -w\" -o \u002Fserver .\u002Fcmd\u002Fserver\n\nFROM alpine:3.19 AS runner\nRUN apk --no-cache add ca-certificates\nRUN adduser -D -u 1001 appuser\nUSER appuser\n\nCOPY --from=builder \u002Fserver \u002Fserver\n\nEXPOSE 8080\nHEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http:\u002F\u002Flocalhost:8080\u002Fhealth || exit 1\nCMD [\"\u002Fserver\"]\n```\n\n### Multi-Stage Dockerfile (Python\u002FDjango)\n\n```dockerfile\nFROM python:3.12-slim AS builder\nWORKDIR \u002Fapp\nRUN pip install --no-cache-dir uv\nCOPY requirements.txt .\nRUN uv pip install --system --no-cache -r requirements.txt\n\nFROM python:3.12-slim AS runner\nWORKDIR \u002Fapp\n\nRUN useradd -r -u 1001 appuser\nUSER appuser\n\nCOPY --from=builder \u002Fusr\u002Flocal\u002Flib\u002Fpython3.12\u002Fsite-packages \u002Fusr\u002Flocal\u002Flib\u002Fpython3.12\u002Fsite-packages\nCOPY --from=builder \u002Fusr\u002Flocal\u002Fbin \u002Fusr\u002Flocal\u002Fbin\nCOPY . .\n\nENV PYTHONUNBUFFERED=1\nEXPOSE 8000\n\nHEALTHCHECK --interval=30s --timeout=3s CMD python -c \"import urllib.request; urllib.request.urlopen('http:\u002F\u002Flocalhost:8000\u002Fhealth\u002F')\" || exit 1\nCMD [\"gunicorn\", \"config.wsgi:application\", \"--bind\", \"0.0.0.0:8000\", \"--workers\", \"4\"]\n```\n\n### Docker Best Practices\n\n```\n# GOOD practices\n- Use specific version tags (node:22-alpine, not node:latest)\n- Multi-stage builds to minimize image size\n- Run as non-root user\n- Copy dependency files first (layer caching)\n- Use .dockerignore to exclude node_modules, .git, tests\n- Add HEALTHCHECK instruction\n- Set resource limits in docker-compose or k8s\n\n# BAD practices\n- Running as root\n- Using :latest tags\n- Copying entire repo in one COPY layer\n- Installing dev dependencies in production image\n- Storing secrets in image (use env vars or secrets manager)\n```\n\n## CI\u002FCD Pipeline\n\n### GitHub Actions (Standard Pipeline)\n\n```yaml\nname: CI\u002FCD\n\non:\n  push:\n    branches: [main]\n  pull_request:\n    branches: [main]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: 22\n          cache: npm\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run typecheck\n      - run: npm test -- --coverage\n      - uses: actions\u002Fupload-artifact@v4\n        if: always()\n        with:\n          name: coverage\n          path: coverage\u002F\n\n  build:\n    needs: test\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: docker\u002Fsetup-buildx-action@v3\n      - uses: docker\u002Flogin-action@v3\n        with:\n          registry: ghcr.io\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n      - uses: docker\u002Fbuild-push-action@v5\n        with:\n          push: true\n          tags: ghcr.io\u002F${{ github.repository }}:${{ github.sha }}\n          cache-from: type=gha\n          cache-to: type=gha,mode=max\n\n  deploy:\n    needs: build\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: production\n    steps:\n      - name: Deploy to production\n        run: |\n          # Platform-specific deployment command\n          # Railway: railway up\n          # Vercel: vercel --prod\n          # K8s: kubectl set image deployment\u002Fapp app=ghcr.io\u002F${{ github.repository }}:${{ github.sha }}\n          echo \"Deploying ${{ github.sha }}\"\n```\n\n### Pipeline Stages\n\n```\nPR opened:\n  lint → typecheck → unit tests → integration tests → preview deploy\n\nMerged to main:\n  lint → typecheck → unit tests → integration tests → build image → deploy staging → smoke tests → deploy production\n```\n\n## Health Checks\n\n### Health Check Endpoint\n\n```typescript\n\u002F\u002F Simple health check\napp.get(\"\u002Fhealth\", (req, res) => {\n  res.status(200).json({ status: \"ok\" });\n});\n\n\u002F\u002F Detailed health check (for internal monitoring)\napp.get(\"\u002Fhealth\u002Fdetailed\", async (req, res) => {\n  const checks = {\n    database: await checkDatabase(),\n    redis: await checkRedis(),\n    externalApi: await checkExternalApi(),\n  };\n\n  const allHealthy = Object.values(checks).every(c => c.status === \"ok\");\n\n  res.status(allHealthy ? 200 : 503).json({\n    status: allHealthy ? \"ok\" : \"degraded\",\n    timestamp: new Date().toISOString(),\n    version: process.env.APP_VERSION || \"unknown\",\n    uptime: process.uptime(),\n    checks,\n  });\n});\n\nasync function checkDatabase(): Promise\u003CHealthCheck> {\n  try {\n    await db.query(\"SELECT 1\");\n    return { status: \"ok\", latency_ms: 2 };\n  } catch (err) {\n    return { status: \"error\", message: \"Database unreachable\" };\n  }\n}\n```\n\n### Kubernetes Probes\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 10\n  periodSeconds: 30\n  failureThreshold: 3\n\nreadinessProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 5\n  periodSeconds: 10\n  failureThreshold: 2\n\nstartupProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 0\n  periodSeconds: 5\n  failureThreshold: 30    # 30 * 5s = 150s max startup time\n```\n\n## Environment Configuration\n\n### Twelve-Factor App Pattern\n\n```bash\n# All config via environment variables — never in code\nDATABASE_URL=postgres:\u002F\u002Fuser:pass@host:5432\u002Fdb\nREDIS_URL=redis:\u002F\u002Fhost:6379\u002F0\nAPI_KEY=${API_KEY}           # injected by secrets manager\nLOG_LEVEL=info\nPORT=3000\n\n# Environment-specific behavior\nNODE_ENV=production          # or staging, development\nAPP_ENV=production           # explicit app environment\n```\n\n### Configuration Validation\n\n```typescript\nimport { z } from \"zod\";\n\nconst envSchema = z.object({\n  NODE_ENV: z.enum([\"development\", \"staging\", \"production\"]),\n  PORT: z.coerce.number().default(3000),\n  DATABASE_URL: z.string().url(),\n  REDIS_URL: z.string().url(),\n  JWT_SECRET: z.string().min(32),\n  LOG_LEVEL: z.enum([\"debug\", \"info\", \"warn\", \"error\"]).default(\"info\"),\n});\n\n\u002F\u002F Validate at startup — fail fast if config is wrong\nexport const env = envSchema.parse(process.env);\n```\n\n## Rollback Strategy\n\n### Instant Rollback\n\n```bash\n# Docker\u002FKubernetes: point to previous image\nkubectl rollout undo deployment\u002Fapp\n\n# Vercel: promote previous deployment\nvercel rollback\n\n# Railway: redeploy previous commit\nrailway up --commit \u003Cprevious-sha>\n\n# Database: rollback migration (if reversible)\nnpx prisma migrate resolve --rolled-back \u003Cmigration-name>\n```\n\n### Rollback Checklist\n\n- [ ] Previous image\u002Fartifact is available and tagged\n- [ ] Database migrations are backward-compatible (no destructive changes)\n- [ ] Feature flags can disable new features without deploy\n- [ ] Monitoring alerts configured for error rate spikes\n- [ ] Rollback tested in staging before production release\n\n## Production Readiness Checklist\n\nBefore any production deployment:\n\n### Application\n- [ ] All tests pass (unit, integration, E2E)\n- [ ] No hardcoded secrets in code or config files\n- [ ] Error handling covers all edge cases\n- [ ] Logging is structured (JSON) and does not contain PII\n- [ ] Health check endpoint returns meaningful status\n\n### Infrastructure\n- [ ] Docker image builds reproducibly (pinned versions)\n- [ ] Environment variables documented and validated at startup\n- [ ] Resource limits set (CPU, memory)\n- [ ] Horizontal scaling configured (min\u002Fmax instances)\n- [ ] SSL\u002FTLS enabled on all endpoints\n\n### Monitoring\n- [ ] Application metrics exported (request rate, latency, errors)\n- [ ] Alerts configured for error rate > threshold\n- [ ] Log aggregation set up (structured logs, searchable)\n- [ ] Uptime monitoring on health endpoint\n\n### Security\n- [ ] Dependencies scanned for CVEs\n- [ ] CORS configured for allowed origins only\n- [ ] Rate limiting enabled on public endpoints\n- [ ] Authentication and authorization verified\n- [ ] Security headers set (CSP, HSTS, X-Frame-Options)\n\n### Operations\n- [ ] Rollback plan documented and tested\n- [ ] Database migration tested against production-sized data\n- [ ] Runbook for common failure scenarios\n- [ ] On-call rotation and escalation path defined\n","# Deployment Patterns\n\nProduction deployment workflows and CI\u002FCD best practices.\n\n## When to Activate\n\n- Setting up CI\u002FCD pipelines\n- Dockerizing an application\n- Planning deployment strategy (blue-green, canary, rolling)\n- Implementing health checks and readiness probes\n- Preparing for a production release\n- Configuring environment-specific settings\n\n## Deployment Strategies\n\n### Rolling Deployment (Default)\n\nReplace instances gradually — old and new versions run simultaneously during rollout.\n\n```\nInstance 1: v1 → v2  (update first)\nInstance 2: v1        (still running v1)\nInstance 3: v1        (still running v1)\n\nInstance 1: v2\nInstance 2: v1 → v2  (update second)\nInstance 3: v1\n\nInstance 1: v2\nInstance 2: v2\nInstance 3: v1 → v2  (update last)\n```\n\n**Pros:** Zero downtime, gradual rollout\n**Cons:** Two versions run simultaneously — requires backward-compatible changes\n**Use when:** Standard deployments, backward-compatible changes\n\n### Blue-Green Deployment\n\nRun two identical environments. Switch traffic atomically.\n\n```\nBlue  (v1) ← traffic\nGreen (v2)   idle, running new version\n\n# After verification:\nBlue  (v1)   idle (becomes standby)\nGreen (v2) ← traffic\n```\n\n**Pros:** Instant rollback (switch back to blue), clean cutover\n**Cons:** Requires 2x infrastructure during deployment\n**Use when:** Critical services, zero-tolerance for issues\n\n### Canary Deployment\n\nRoute a small percentage of traffic to the new version first.\n\n```\nv1: 95% of traffic\nv2:  5% of traffic  (canary)\n\n# If metrics look good:\nv1: 50% of traffic\nv2: 50% of traffic\n\n# Final:\nv2: 100% of traffic\n```\n\n**Pros:** Catches issues with real traffic before full rollout\n**Cons:** Requires traffic splitting infrastructure, monitoring\n**Use when:** High-traffic services, risky changes, feature flags\n\n## Docker\n\n### Multi-Stage Dockerfile (Node.js)\n\n```dockerfile\n# Stage 1: Install dependencies\nFROM node:22-alpine AS deps\nWORKDIR \u002Fapp\nCOPY package.json package-lock.json .\u002F\nRUN npm ci --production=false\n\n# Stage 2: Build\nFROM node:22-alpine AS builder\nWORKDIR \u002Fapp\nCOPY --from=deps \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCOPY . .\nRUN npm run build\nRUN npm prune --production\n\n# Stage 3: Production image\nFROM node:22-alpine AS runner\nWORKDIR \u002Fapp\n\nRUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001\nUSER appuser\n\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fdist .\u002Fdist\nCOPY --from=builder --chown=appuser:appgroup \u002Fapp\u002Fpackage.json .\u002F\n\nENV NODE_ENV=production\nEXPOSE 3000\n\nHEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \\\n  CMD wget --no-verbose --tries=1 --spider http:\u002F\u002Flocalhost:3000\u002Fhealth || exit 1\n\nCMD [\"node\", \"dist\u002Fserver.js\"]\n```\n\n### Multi-Stage Dockerfile (Go)\n\n```dockerfile\nFROM golang:1.22-alpine AS builder\nWORKDIR \u002Fapp\nCOPY go.mod go.sum .\u002F\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 GOOS=linux go build -ldflags=\"-s -w\" -o \u002Fserver .\u002Fcmd\u002Fserver\n\nFROM alpine:3.19 AS runner\nRUN apk --no-cache add ca-certificates\nRUN adduser -D -u 1001 appuser\nUSER appuser\n\nCOPY --from=builder \u002Fserver \u002Fserver\n\nEXPOSE 8080\nHEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http:\u002F\u002Flocalhost:8080\u002Fhealth || exit 1\nCMD [\"\u002Fserver\"]\n```\n\n### Multi-Stage Dockerfile (Python\u002FDjango)\n\n```dockerfile\nFROM python:3.12-slim AS builder\nWORKDIR \u002Fapp\nRUN pip install --no-cache-dir uv\nCOPY requirements.txt .\nRUN uv pip install --system --no-cache -r requirements.txt\n\nFROM python:3.12-slim AS runner\nWORKDIR \u002Fapp\n\nRUN useradd -r -u 1001 appuser\nUSER appuser\n\nCOPY --from=builder \u002Fusr\u002Flocal\u002Flib\u002Fpython3.12\u002Fsite-packages \u002Fusr\u002Flocal\u002Flib\u002Fpython3.12\u002Fsite-packages\nCOPY --from=builder \u002Fusr\u002Flocal\u002Fbin \u002Fusr\u002Flocal\u002Fbin\nCOPY . .\n\nENV PYTHONUNBUFFERED=1\nEXPOSE 8000\n\nHEALTHCHECK --interval=30s --timeout=3s CMD python -c \"import urllib.request; urllib.request.urlopen('http:\u002F\u002Flocalhost:8000\u002Fhealth\u002F')\" || exit 1\nCMD [\"gunicorn\", \"config.wsgi:application\", \"--bind\", \"0.0.0.0:8000\", \"--workers\", \"4\"]\n```\n\n### Docker Best Practices\n\n```\n# GOOD practices\n- Use specific version tags (node:22-alpine, not node:latest)\n- Multi-stage builds to minimize image size\n- Run as non-root user\n- Copy dependency files first (layer caching)\n- Use .dockerignore to exclude node_modules, .git, tests\n- Add HEALTHCHECK instruction\n- Set resource limits in docker-compose or k8s\n\n# BAD practices\n- Running as root\n- Using :latest tags\n- Copying entire repo in one COPY layer\n- Installing dev dependencies in production image\n- Storing secrets in image (use env vars or secrets manager)\n```\n\n## CI\u002FCD Pipeline\n\n### GitHub Actions (Standard Pipeline)\n\n```yaml\nname: CI\u002FCD\n\non:\n  push:\n    branches: [main]\n  pull_request:\n    branches: [main]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: 22\n          cache: npm\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run typecheck\n      - run: npm test -- --coverage\n      - uses: actions\u002Fupload-artifact@v4\n        if: always()\n        with:\n          name: coverage\n          path: coverage\u002F\n\n  build:\n    needs: test\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: docker\u002Fsetup-buildx-action@v3\n      - uses: docker\u002Flogin-action@v3\n        with:\n          registry: ghcr.io\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n      - uses: docker\u002Fbuild-push-action@v5\n        with:\n          push: true\n          tags: ghcr.io\u002F${{ github.repository }}:${{ github.sha }}\n          cache-from: type=gha\n          cache-to: type=gha,mode=max\n\n  deploy:\n    needs: build\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: production\n    steps:\n      - name: Deploy to production\n        run: |\n          # Platform-specific deployment command\n          # Railway: railway up\n          # Vercel: vercel --prod\n          # K8s: kubectl set image deployment\u002Fapp app=ghcr.io\u002F${{ github.repository }}:${{ github.sha }}\n          echo \"Deploying ${{ github.sha }}\"\n```\n\n### Pipeline Stages\n\n```\nPR opened:\n  lint → typecheck → unit tests → integration tests → preview deploy\n\nMerged to main:\n  lint → typecheck → unit tests → integration tests → build image → deploy staging → smoke tests → deploy production\n```\n\n## Health Checks\n\n### Health Check Endpoint\n\n```typescript\n\u002F\u002F Simple health check\napp.get(\"\u002Fhealth\", (req, res) => {\n  res.status(200).json({ status: \"ok\" });\n});\n\n\u002F\u002F Detailed health check (for internal monitoring)\napp.get(\"\u002Fhealth\u002Fdetailed\", async (req, res) => {\n  const checks = {\n    database: await checkDatabase(),\n    redis: await checkRedis(),\n    externalApi: await checkExternalApi(),\n  };\n\n  const allHealthy = Object.values(checks).every(c => c.status === \"ok\");\n\n  res.status(allHealthy ? 200 : 503).json({\n    status: allHealthy ? \"ok\" : \"degraded\",\n    timestamp: new Date().toISOString(),\n    version: process.env.APP_VERSION || \"unknown\",\n    uptime: process.uptime(),\n    checks,\n  });\n});\n\nasync function checkDatabase(): Promise\u003CHealthCheck> {\n  try {\n    await db.query(\"SELECT 1\");\n    return { status: \"ok\", latency_ms: 2 };\n  } catch (err) {\n    return { status: \"error\", message: \"Database unreachable\" };\n  }\n}\n```\n\n### Kubernetes Probes\n\n```yaml\nlivenessProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 10\n  periodSeconds: 30\n  failureThreshold: 3\n\nreadinessProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 5\n  periodSeconds: 10\n  failureThreshold: 2\n\nstartupProbe:\n  httpGet:\n    path: \u002Fhealth\n    port: 3000\n  initialDelaySeconds: 0\n  periodSeconds: 5\n  failureThreshold: 30    # 30 * 5s = 150s max startup time\n```\n\n## Environment Configuration\n\n### Twelve-Factor App Pattern\n\n```bash\n# All config via environment variables — never in code\nDATABASE_URL=postgres:\u002F\u002Fuser:pass@host:5432\u002Fdb\nREDIS_URL=redis:\u002F\u002Fhost:6379\u002F0\nAPI_KEY=${API_KEY}           # injected by secrets manager\nLOG_LEVEL=info\nPORT=3000\n\n# Environment-specific behavior\nNODE_ENV=production          # or staging, development\nAPP_ENV=production           # explicit app environment\n```\n\n### Configuration Validation\n\n```typescript\nimport { z } from \"zod\";\n\nconst envSchema = z.object({\n  NODE_ENV: z.enum([\"development\", \"staging\", \"production\"]),\n  PORT: z.coerce.number().default(3000),\n  DATABASE_URL: z.string().url(),\n  REDIS_URL: z.string().url(),\n  JWT_SECRET: z.string().min(32),\n  LOG_LEVEL: z.enum([\"debug\", \"info\", \"warn\", \"error\"]).default(\"info\"),\n});\n\n\u002F\u002F Validate at startup — fail fast if config is wrong\nexport const env = envSchema.parse(process.env);\n```\n\n## Rollback Strategy\n\n### Instant Rollback\n\n```bash\n# Docker\u002FKubernetes: point to previous image\nkubectl rollout undo deployment\u002Fapp\n\n# Vercel: promote previous deployment\nvercel rollback\n\n# Railway: redeploy previous commit\nrailway up --commit \u003Cprevious-sha>\n\n# Database: rollback migration (if reversible)\nnpx prisma migrate resolve --rolled-back \u003Cmigration-name>\n```\n\n### Rollback Checklist\n\n- [ ] Previous image\u002Fartifact is available and tagged\n- [ ] Database migrations are backward-compatible (no destructive changes)\n- [ ] Feature flags can disable new features without deploy\n- [ ] Monitoring alerts configured for error rate spikes\n- [ ] Rollback tested in staging before production release\n\n## Production Readiness Checklist\n\nBefore any production deployment:\n\n### Application\n- [ ] All tests pass (unit, integration, E2E)\n- [ ] No hardcoded secrets in code or config files\n- [ ] Error handling covers all edge cases\n- [ ] Logging is structured (JSON) and does not contain PII\n- [ ] Health check endpoint returns meaningful status\n\n### Infrastructure\n- [ ] Docker image builds reproducibly (pinned versions)\n- [ ] Environment variables documented and validated at startup\n- [ ] Resource limits set (CPU, memory)\n- [ ] Horizontal scaling configured (min\u002Fmax instances)\n- [ ] SSL\u002FTLS enabled on all endpoints\n\n### Monitoring\n- [ ] Application metrics exported (request rate, latency, errors)\n- [ ] Alerts configured for error rate > threshold\n- [ ] Log aggregation set up (structured logs, searchable)\n- [ ] Uptime monitoring on health endpoint\n\n### Security\n- [ ] Dependencies scanned for CVEs\n- [ ] CORS configured for allowed origins only\n- [ ] Rate limiting enabled on public endpoints\n- [ ] Authentication and authorization verified\n- [ ] Security headers set (CSP, HSTS, X-Frame-Options)\n\n### Operations\n- [ ] Rollback plan documented and tested\n- [ ] Database migration tested against production-sized data\n- [ ] Runbook for common failure scenarios\n- [ ] On-call rotation and escalation path defined\n",{"name":5,"tags":49,"tools":53,"source":54,"license":14,"description":7,"source_path":55,"source_commit":56},[50,51,52],"devops","deploy","docker",[],"https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC","skills\u002Fdeployment-patterns","bf70150eb2df8070024e5bdf08e4aa08959e2735","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fdeployment-patterns",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-14 03:30:52",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add monoes\u002Fmonomind --skill deployment-patterns",{"tool":72,"command":73},"bunx","bunx skills add monoes\u002Fmonomind --skill deployment-patterns",{"tool":75,"command":76},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill deployment-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fdeployment-patterns\u002FSKILL.md",true,[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1071,[86,113,146,173,197,220],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":112},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[94,95,96,97,98,99,35,100,101,102,103,104,105,106,107,108,109,31,110,111],"zk","zk steward","steward","zero-knowledge","engineer","choice","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","org","blockchain","2026-11-10 13:02:02",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":117,"sourceHtmlUrl":118,"categories":119,"keywords":128,"publishedAt":112},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[129,130,131,98,132,133,34,134,102,135,136,137,138,139,140,141,142,143,144,145],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":150,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":112},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000031","产品经理",[139,157,158,159,160,100,161,34,162,163,164,138,165,166,167,168,169,170,171,172],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":177,"sourceHtmlUrl":178,"categories":179,"keywords":183,"publishedAt":112},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[180],{"categoryNo":181,"categoryName":182,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000033","数据分析师",[102,139,184,185,27,186,100,171,34,187,188,189,190,164,191,192,193,194,195,196],"write query","postgres","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":207,"publishedAt":112},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[203,204],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[208,209,210,211,27,212,36,213,214,101,215,216,217,102,105,191,218,219,50,193],"Workflow Automation","automation","workflow","parallel","actions","triggers","github actions","maintain","filters","caching","build","dependency",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":112},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[226],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},[210,228,229,230,231,232,233,27,234,235,135,236,237,238,105,191,239,240,193,241],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]