用途
deployment-patterns 是一套生产部署工作流与 CI/CD 最佳实践资料，用于指导何时以及如何配置部署流程。资料指出，在以下情况应启用它：搭建 CI/CD 流水线、将应用 Docker 化、规划部署策略（蓝绿、金丝雀、滚动）、实现健康检查与就绪探针、准备生产发布、配置环境相关设置。
部署策略
资料给出三种部署策略，并列出各自的优缺点与适用场景。
- 滚动部署（默认）：逐步替换实例，新旧版本在发布期间同时运行。资料用三段示例展示实例 1、2、3 依次从 v1 更新到 v2 的过程。优点是零停机、渐进式发布；缺点是两个版本同时运行，要求变更向后兼容。适用于标准部署和向后兼容的变更。
- 蓝绿部署：运行两套相同环境，原子切换流量。蓝环境（v1）承接流量，绿环境（v2）空闲并运行新版本；验证后蓝环境转为待机，绿环境承接流量。优点是瞬时回滚（切回蓝色）、切换干净；缺点是部署期间需要双倍基础设施。适用于关键服务、对问题零容忍的场景。
- 金丝雀部署：先把小比例流量路由到新版本，例如 v1 占 95%、v2 占 5%，指标良好后逐步调整到 50/50，最终 v2 承接 100%。优点是能在全量发布前用真实流量发现问题；缺点是需要流量切分基础设施与监控。适用于高流量服务、高风险变更、功能开关场景。
Docker 容器化
资料提供三种技术栈的多阶段 Dockerfile 示例：
- Node.js：分为 deps、builder、runner 三个阶段；runner 阶段创建非 root 用户（appgroup/appuser，UID 1001），复制 node_modules、dist 和 package.json，设置 NODE_ENV=production，暴露 3000 端口，配置 HEALTHCHECK（间隔 30s、超时 3s、启动期 5s、重试 3 次），以 node dist/server.js 启动。
- Go：builder 阶段使用 golang:1.22-alpine 下载依赖并以 CGO_ENABLED=0、-ldflags="-s -w" 编译；runner 阶段使用 alpine:3.19 安装 ca-certificates，创建非 root 用户 appuser，暴露 8080 端口，配置 HEALTHCHECK，启动 /server。
- Python/Django：builder 阶段使用 python:3.12-slim 并通过 uv 安装 requirements；runner 阶段创建非 root 用户 appuser，复制 site-packages 与 bin，设置 PYTHONUNBUFFERED=1，暴露 8000 端口，配置 HEALTHCHECK，以 gunicorn 启动并绑定 0.0.0.0:8000，4 个 worker。
Docker 最佳实践方面，资料建议：使用具体版本标签（如 node:22-alpine 而非 node:latest）、多阶段构建以缩小镜像、以非 root 用户运行、先复制依赖文件以利用层缓存、用 .dockerignore 排除 node_modules/.git/tests、添加 HEALTHCHECK 指令、在 docker-compose 或 k8s 中设置资源限制。反面实践包括：以 root 运行、使用 :latest 标签、在一个 COPY 层复制整个仓库、在生产镜像中安装开发依赖、在镜像中存储密钥（应使用环境变量或密钥管理器）。
CI/CD 流水线
资料给出一个 GitHub Actions 标准流水线示例，包含三个阶段：test、build、deploy。test 阶段在 ubuntu-latest 上检出代码、安装 Node 22 并启用 npm 缓存，执行 npm ci、lint、typecheck、带覆盖率的测试，并上传覆盖率制品。build 阶段依赖 test，仅在 main 分支运行，使用 buildx、登录 ghcr.io 并以提交 SHA 作为标签构建推送镜像，启用 gha 缓存。deploy 阶段依赖 build，仅在 main 分支运行，使用 production 环境，示例中通过注释列出平台相关命令（Railway: railway up；Vercel: vercel --prod；K8s: kubectl set image …）。
流水线阶段方面：PR 打开时执行 lint → typecheck → 单元测试 → 集成测试 → 预览部署；合并到 main 后执行 lint → typecheck → 单元测试 → 集成测试 → 构建镜像 → 部署 staging → 冒烟测试 → 部署生产。
健康检查
资料提供健康检查端点示例：简单的 /health 返回 200 与 { status: "ok" }；详细的 /health/detailed 检查数据库、Redis、外部 API，若全部正常返回 200，否则返回 503，并返回状态、时间戳、版本、运行时长与各检查项结果。示例中包含 checkDatabase 函数（执行 SELECT 1，返回状态与延迟，或错误信息）。
Kubernetes 探针方面，资料列出 livenessProbe、readinessProbe、startupProbe 的配置示例，均通过 HTTP GET /health 访问 3000 端口，并分别给出 initialDelaySeconds、periodSeconds、failureThreshold 参数，其中 startupProbe 的 30 次 × 5 秒表示最长 150 秒启动时间。
环境配置
资料引用 Twelve-Factor App 模式，强调所有配置通过环境变量提供，绝不写在代码中，示例包括 DATABASE_URL、REDIS_URL、API_KEY、LOG_LEVEL、PORT、NODE_ENV、APP_ENV。配置校验方面给出基于 zod 的 envSchema 示例，对 NODE_ENV、PORT、DATABASE_URL、REDIS_URL、JWT_SECRET、LOG_LEVEL 做类型与默认值校验，并在启动时用 envSchema.parse(process.env) 进行校验、快速失败。
回滚策略
资料列出即时回滚命令：Docker/Kubernetes 执行 kubectl rollout undo deployment/app；Vercel 执行 vercel rollback；Railway 执行 railway up --commit <previous-sha>；数据库执行 npx prisma migrate resolve --rolled-back <migration-name>（如迁移可逆）。回滚清单包括：上一版本镜像/制品可用并有标签、数据库迁移向后兼容（无破坏性变更）、功能开关可在不部署的情况下禁用新功能、已配置错误率飙升的监控告警、回滚在生产发布前已在预发环境测试。
生产就绪检查清单
在任意生产部署前，资料列出五类检查项：
- 应用：所有测试通过（单元、集成、E2E）；代码或配置文件中无硬编码密钥；错误处理覆盖所有边界情况；日志为结构化（JSON）且不含 PII；健康检查端点返回有意义的状态。
- 基础设施：Docker 镜像可重现构建（固定版本）；环境变量有文档且在启动时校验；已设置资源限制（CPU、内存）；已配置水平扩展（最小/最大实例数）；所有端点启用 SSL/TLS。
- 监控：导出应用指标（请求率、延迟、错误）；配置错误率超阈值告警；搭建日志聚合（结构化、可搜索）；对健康端点做可用性监控。
- 安全：扫描依赖的 CVE；CORS 仅对允许的来源配置；公共端点启用速率限制；验证认证与授权；设置安全响应头（CSP、HSTS、X-Frame-Options）。
- 运维：回滚方案有文档并经过测试；数据库迁移已针对生产规模数据测试；常见故障场景有 Runbook；定义值班轮换与升级路径。
限制
资料未说明该技能的安装方式、运行环境依赖或版本要求，暂未提供。