企业官网建设流程全解析

ECC 部署模式（Deployment Patterns）实战指南：CI/CD、Docker 容器化、健康检查与生产就绪

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC

本文以 ECC 仓库内置的 deployment-patterns 技能文档（技能原文，英语基准版见 skills/deployment-patterns/SKILL.md）为核心骨架，系统梳理 Web 应用从"代码合并"到"生产运行"全链条的部署工程实践：三种主流的发布策略（滚动/蓝绿/金丝雀）、面向 Node.js / Go / Python 的多阶段 Dockerfile 写法、GitHub Actions CI/CD 流水线编排、健康检查与 Kubernetes 探针设计、Twelve-Factor 环境配置、回滚策略以及一份可直接照抄的生产就绪检查清单。读完你可以直接为团队搭建一套"测试 → 构建镜像 → 灰度 → 上线 → 可回滚"的标准化发布流程，并用健康检查与监控守好最后一公里。

文档定位说明：deployment-patterns 是 ECC（package.json 中描述为 "Harness-native agent operating system"）内置的 Skill 技能之一，frontmatter 声明origin: ECC，其"何时激活（When to Activate）"场景与源码目录skills/deployment-patterns/一一对应；本文引用仓库其余内容（Dockerfile、CI workflow、服务端健康检查实现）仅用于佐证，部署方法论本身以该技能文档为准。

何时使用这套部署模式

技能文档在Cuándo Activar（何时激活）一节给出了明确的触发场景，适合在任何出现以下需求的时刻唤起：

• 搭建 CI/CD 流水线（Setting up CI/CD pipelines）
• 用 Docker 容器化一个应用（Dockerizing an application）
• 规划部署策略——蓝绿、金丝雀、滚动（Planning deployment strategy: blue-green, canary, rolling）
• 实现 health checks 与 readiness probes（Implementing health checks and readiness probes）
• 为生产发布做准备（Preparing for a production release）
• 配置按环境区分的参数（Configuring environment-specific settings）

换言之，这套模式横跨"发布前（策略与配置）、发布中（流水线与容器化）、发布后（健康检查与回滚）、常驻（生产就绪度审计）"四个阶段，既适合独立小团队一次上线，也适合在 ECC 这类多技能协同的项目里把"交付质量门禁"沉淀成可复用知识。

部署策略（Deployment Strategies）

先选对策略，再谈工具。技能文档给出三种经典策略及其取舍，核心评判维度是：是否允许新旧版本短暂共存、是否要求基础设施翻倍、是否具备瞬时回滚能力。

滚动发布（Rolling Deployment，默认策略）

滚动发布按实例逐个替换，发布过程中新旧版本同时运行：

实例 1：v1 → v2 （先更新） 实例 2：v1 （仍在运行 v1） 实例 3：v1 （仍在运行 v1） 实例 1：v2 实例 2：v1 → v2 （第二个更新） 实例 3：v1 实例 1：v2 实例 2：v2 实例 3：v1 → v2 （最后更新）

滚动发布的天然约束是"兼容窗口"：由于第 2、3 个实例可能仍被旧代码服务，数据库 schema、接口契约都必须同时兼容 v1 与 v2。这也是技能文档把"向后兼容"列为唯一硬性前提的原因。

蓝绿发布（Blue-Green Deployment）

维护 Blue、Green 两套完全相同的环境，通过切换流量完成原子式换版：

Blue (v1) ← 流量 Green (v2) 空闲，运行新版本 # 验证通过之后： Blue (v1) 空闲（转为备用/standby） Green (v2) ← 流量

蓝绿模式里"环境"通常是完整的服务栈（含数据库方案，实践中常配合可回滚的迁移策略处理共享存储）。若 Green 验证失败，只需把流量指回 Blue，不需要重新发布任何东西，因此它天然拥有"clean cutover + instant rollback"两项能力。

金丝雀发布（Canary Deployment）

先把小比例真实流量路由到新版本，用真实业务验证质量后再逐步放大：

v1：95% 的流量 v2： 5% 的流量 （金丝雀） # 若指标良好： v1：50% 的流量 v2：50% 的流量 # 最终： v2：100% 的流量

金丝雀的放大/回退决策必须依赖指标，因此技能文档强调其前提是"可切分流量的基础设施 + 监控"。放大节奏（5% → 50% → 100%）只是示意，实际应根据错误率、延迟分位值等指标自动或人工推进。

Docker 容器化：三份可直接复用的多阶段 Dockerfile

多阶段构建（multi-stage build）的目的单一而明确：把"编译环境"与"运行环境"解耦，让最终镜像只携带运行时产物与依赖，体积更小、攻击面更小。技能文档分别给出了 Node.js、Go、Python/Django 三种主流的实现。

Node.js：deps → builder → runner 三阶段

# 阶段 1：安装依赖 FROM node:22-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --production=false # 阶段 2：构建 FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN npm run build RUN npm prune --production # 阶段 3：生产镜像 FROM node:22-alpine AS runner WORKDIR /app RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 USER appuser COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules COPY --from=builder --chown=appuser:appgroup /app/dist ./dist COPY --from=builder --chown=appuser:appgroup /app/package.json ./ ENV NODE_ENV=production EXPOSE 3000 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1 CMD ["node", "dist/server.js"]

逐行要点：

• npm ci而非npm install：npm ci依据package-lock.json做确定性安装，保证可复现构建；--production=false让 deps 阶段装齐构建期依赖。
• 利用层缓存：先COPY package.json package-lock.json再RUN npm ci，只要锁文件不变，这一层就不会失效，能显著加快 CI。
• npm prune --production：在 builder 阶段构建完后剔除 devDependencies，让后续拷贝进 runner 的node_modules不含开发依赖（技能文档"坏实践"清单明确反对把开发依赖装进生产镜像）。
• 非 root 用户：addgroup/adduser创建 gid/uid 均为 1001 的普通用户并USER appuser，配合COPY --chown=...保证产物归属正确。
• HEALTHCHECK 指令：Docker 层面的存活探活，--interval=30s --timeout=3s --start-period=5s --retries=3表示每 30s 探测一次、超时 3s、应用启动宽限期 5s、连续失败 3 次判定不健康；这里使用wget --spider发起不下载内容的 HEAD 探测。

Go：静态编译 + 精简运行时

FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server FROM alpine:3.19 AS runner RUN apk --no-cache add ca-certificates RUN adduser -D -u 1001 appuser USER appuser COPY --from=builder /server /server EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:8080/health || exit 1 CMD ["/server"]

要点：

• CGO_ENABLED=0 GOOS=linux：禁用 CGO 做纯静态编译，二进制不依赖 glibc，可以放进极小的alpine运行时；-ldflags="-s -w"剥离符号表与调试信息以缩小体积。
• apk --no-cache add ca-certificates：静态二进制不带系统根证书，访问外部 HTTPS 服务必须自行安装 CA。
• 同样先COPY go.mod go.sum再go mod download，利用依赖层缓存。
• Go 阶段只有"编译 → 拷贝单文件"，生产镜像里没有编译器，是最能体现多阶段收益的范式之一。

Python/Django：uv 安装 + gunicorn 启动

FROM python:3.12-slim AS builder WORKDIR /app RUN pip install --no-cache-dir uv COPY requirements.txt . RUN uv pip install --system --no-cache -r requirements.txt FROM python:3.12-slim AS runner WORKDIR /app RUN useradd -r -u 1001 appuser USER appuser COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages COPY --from=builder /usr/local/bin /usr/local/bin COPY . . ENV PYTHONUNBUFFERED=1 EXPOSE 8000 HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health/')" || exit 1 CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "4"]

要点：

• uv pip install --system：用 uv 把requirements.txt安装进系统 site-packages，随后在 runner 阶段直接整体拷贝site-packages与/usr/local/bin，运行镜像内不需要 pip/uv。
• PYTHONUNBUFFERED=1：保证 stdout/stderr 无缓冲输出，日志可被容器运行时与日志采集端实时捕获——这正对应技能文档生产清单里"结构化、可检索日志"的要求。
• gunicorn 参数：--bind 0.0.0.0:8000 --workers 4中 workers 数通常按2 × CPU 核数 + 1的经验值设置，生产环境应由环境变量注入而非写死。
• wget/urllib两种健康探测写法对应 Alpine（无 wget 需另装）与基于 python 镜像时的通用做法。

Docker 最佳实践对照

技能文档用一份"好/坏"对照清单总结了容器化的纪律，可直接作为 Dockerfile review 的 checklist：

# 良好实践 - 使用具体的版本标签（node:22-alpine，而非 node:latest） - 用多阶段构建压缩镜像体积 - 以非 root 用户运行 - 先 COPY 依赖清单文件（利用层缓存） - 使用 .dockerignore 排除 node_modules、.git、tests - 添加 HEALTHCHECK 指令 - 在 docker-compose 或 k8s 中设置资源限制 # 坏实践 - 以 root 运行 - 使用 :latest 标签 - 用一层 COPY 拷贝整个仓库 - 在生产镜像中安装开发依赖 - 把密钥烧进镜像（应使用环境变量或密钥管理服务）

这些原则在本仓库有真实落地证据：ECC 的 docker/plugin-setup/Dockerfile 把基础镜像固定到 sha256 摘要级（node:22-bookworm-slim@sha256:6c74…），安装依赖后执行npm cache clean --force清理缓存，并以 uid/gid 1000 的非 root 用户（USER 1000:1000）运行——与"固定版本、最小镜像、非 root、无残留缓存"的纪律完全一致。

CI/CD 流水线：GitHub Actions 标准范式

技能文档给出了一个贯穿 test → build → deploy 三个 job 的完整 GitHub Actions 示例，可作为多数 Node + Docker 项目的起点模板。

标准流水线工作流

name: CI/CD on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 cache: npm - run: npm ci - run: npm run lint - run: npm run typecheck - run: npm test -- --coverage - uses: actions/upload-artifact@v4 if: always() with: name: coverage path: coverage/ build: needs: test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - uses: actions/checkout@v4 - uses: docker/setup-buildx-action@v3 - uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - uses: docker/build-push-action@v5 with: push: true tags: ghcr.io/${{ github.repository }}:${{ github.sha }} cache-from: type=gha cache-to: type=gha,mode=max deploy: needs: build runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' environment: production steps: - name: Deploy to production run: | # 平台相关的部署命令 # Railway: railway up # Vercel: vercel --prod # K8s: kubectl set image deployment/app app=ghcr.io/${{ github.repository }}:${{ github.sha }} echo "Deploying ${{ github.sha }}"

流水线设计的几个关键决策点：

1. 触发矩阵（on）：push到 main 与pull_request到 main 都会触发。PR 场景天然只应跑"验证"，合并后才跑"构建 + 发布"。
2. 质量门禁前置：lint → typecheck → test全部通过，build job 才允许启动（needs: test）。
3. 发布条件与镜像标签：if: github.ref == 'refs/heads/main'把 build/deploy 限定在主干；镜像用commit SHA 打标签（tags: ghcr.io/${{ github.repository }}:${{ github.sha }}），实现"每个 commit 有唯一不可变制品"，这正是回滚清单里"previous image is available and tagged"的前提。
4. GitHub 容器仓库（ghcr.io）：通过docker/login-action使用secrets.GITHUB_TOKEN鉴权，免去另存凭证。
5. 构建缓存：cache-from: type=gha / cache-to: type=gha,mode=max利用 GitHub Actions 缓存层加速多阶段构建。
6. environment: production：GitHub 的 environment 保护可附加人工审批与机密隔离，是"production 与普通分支不同待遇"的声明式表达。

流水线阶段划分（Pipeline Stages）

技能文档对"PR 阶段"与"主干阶段"给出了两套严格不同的质量路径：

PR 打开时： lint → typecheck → 单元测试 → 集成测试 → preview 环境部署 合并到 main 后： lint → typecheck → 单元测试 → 集成测试 → 构建镜像 → 部署 staging → 冒烟测试 → 部署生产

对比可见，进入 main 的路径在"构建镜像"之后补上了staging 部署 + 冒烟测试两个环节，才允许触碰生产。这是"发布频率高但事故少"的关键：所有高风险操作先在 staging 以生产等价方式演练一遍。

ECC 仓库自身的 .github/workflows/ci.yml 即体现了同类工程化：对main/release/**分支与v*标签触发，用concurrency分组防止重复运行、用最小权限permissions: contents: read收敛令牌，并利用strategy.matrix在ubuntu/windows/macos × Node 18/20/22 × npm/pnpm/yarn/bun上并行跑测试——这与文档中的"测试前置、构建产物可追溯、多环境验证"思路相互印证。

Health Checks：让平台知道"你还活着且可用"

健康检查要区分两种语义：存活（alive）与就绪（ready）。技能文档分别给出了应用侧实现与 Kubernetes 探针配置。

应用侧：/health与/health/detailed

// 简单健康检查 app.get("/health", (req, res) => { res.status(200).json({ status: "ok" }); }); // 详细健康检查（供内部监控使用） app.get("/health/detailed", async (req, res) => { const checks = { database: await checkDatabase(), redis: await checkRedis(), externalApi: await checkExternalApi(), }; const allHealthy = Object.values(checks).every(c => c.status === "ok"); res.status(allHealthy ? 200 : 503).json({ status: allHealthy ? "ok" : "degraded", timestamp: new Date().toISOString(), version: process.env.APP_VERSION || "unknown", uptime: process.uptime(), checks, }); }); async function checkDatabase(): Promise<HealthCheck> { try { await db.query("SELECT 1"); return { status: "ok", latency_ms: 2 }; } catch (err) { return { status: "error", message: "Database unreachable" }; } }

设计要点：

• 两个端点分工：/health只回答"进程活着"，给负载均衡/外部 uptime 监控用；/health/detailed深入探测 DB、Redis、外部 API 等下游依赖，给内部告警与排障用。把慢速依赖探测从公开探活路径剥离开，避免外部探测被内部依赖抖动拖慢。
• 状态码即语义：全部依赖健康返回200；任一依赖异常返回503，并附status: "degraded"。平台（负载均衡、K8s、Docker HEALTHCHECK）只看状态码就能决定流量进出。
• 响应内容自描述：带timestamp、version（取自APP_VERSION环境变量）、uptime，方便定位"哪个版本的实例在报错、已运行多久"。
• 探活语句用SELECT 1：这是数据库连通性探测的标准最小查询，避免业务表权限/锁影响探活准确性；可额外返回latency_ms做性能基线。

从仓库源码结构看，ECC 自身也贯彻了"内部服务带/health端点"的约定：scripts/lib/control-pane/server.js、scripts/lib/plan-canvas/server.js等多个本地控制面/仪表盘模块的源码中均存在/health相关实现，说明该模式既适合对外 Web 服务，也适用于 Agent 工具链里各内置服务节点的健康上报。

Kubernetes 探针（Probes）

livenessProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 10 periodSeconds: 30 failureThreshold: 3 readinessProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 2 startupProbe: httpGet: path: /health port: 3000 initialDelaySeconds: 0 periodSeconds: 5 failureThreshold: 30 # 30 * 5s = 150s 最大启动时间

三类探针的分工与参数语义：

• livenessProbe（存活）：判定容器是否死锁/卡死，失败超过failureThreshold即被 kubelet 重启。initialDelaySeconds: 10是启动宽限，periodSeconds: 30拉长探测频率以降低开销。探活必须轻量，不能依赖本进程的后台任务完成。
• readinessProbe（就绪）：决定 Pod 是否进入 Service 的 Endpoints。失败即摘流量、不重启——这与文档健康检查对"就绪 = 可接收流量"的定义严格对应。periodSeconds: 10更快地感知可用性变化。
• startupProbe（启动）：解决"慢启动应用被 liveness 误杀"的经典问题。failureThreshold: 30 × periodSeconds: 5 = 150s，即允许应用最长 150 秒完成启动；启动探针通过后，liveness 才接管，因此 liveness 的initialDelaySeconds无需为最坏启动时间预留。
• 三者探同一条路径但用途不同：/health同时作为 liveness 与 readiness 目标是常见且合理的起点；若应用存在"已存活但尚不能服务"的窗口，应把 readiness 指向更严格的/health/detailed或独立就绪端点。

环境配置：Twelve-Factor 与启动即校验

配置外置（Twelve-Factor App）

技能文档要求"所有配置经环境变量注入，绝不硬编码进代码"：

# 所有配置通过环境变量——绝不写入代码 DATABASE_URL=postgres://user:pass@host:5432/db REDIS_URL=redis://host:6379/0 API_KEY=${API_KEY} # 由密钥管理器注入 LOG_LEVEL=info PORT=3000 # 按环境区分的行为 NODE_ENV=production # 或 staging、development APP_ENV=production # 显式的应用环境标识

要点：

• NODE_ENV驱动框架/依赖的行为差异（压缩、缓存、告警文案），而APP_ENV是应用自定义的部署环境标识；两者职责不同，文档建议分开设置而不是互相替代。
• API_KEY=${API_KEY}的写法表示：本地开发可用.env兜底，但生产环境的值必须由密钥管理器（如 Vault、云厂商 Secret Manager、CI secrets）在运行时注入，避免任何密钥出现在镜像层里——这条与上文 Docker "坏实践：把密钥烧进镜像"一脉相承。
• 连接串、端口、日志级别这类"换环境就变"的值全部走环境变量后，同一个镜像可以做到"构建一次、处处运行"（build once, run anywhere），这是支撑滚动/蓝绿/金丝雀多环境复用的前提。

配置校验：fail fast

import { z } from "zod"; const envSchema = z.object({ NODE_ENV: z.enum(["development", "staging", "production"]), PORT: z.coerce.number().default(3000), DATABASE_URL: z.string().url(), REDIS_URL: z.string().url(), JWT_SECRET: z.string().min(32), LOG_LEVEL: z.enum(["debug", "info", "warn", "error"]).default("info"), }); // 启动时校验——配置有误立即失败 export const env = envSchema.parse(process.env);

逐字段说明：

• z.enum([...])限定取值范围：NODE_ENV只接受三个合法环境；LOG_LEVEL限定debug/info/warn/error，默认info。
• z.coerce.number().default(3000)：允许环境变量是字符串"3000"，自动转数字并在缺省时落到 3000。
• z.string().url()：DATABASE_URL/REDIS_URL若格式非法，进程直接抛错。
• z.string().min(32)：JWT_SECRET强制最短 32 字符，从长度上拒绝弱密钥。
• envSchema.parse(process.env)的哲学是 fail fast：配置错误是最廉价的错误，绝不该带着错误配置启动半个集群后再连环报错。schema 本身就是"环境变量文档"——哪个变量必需、取值范围是什么、默认值是多少，读代码即知。这与技能文档生产清单中"环境变量已文档化并在启动时校验"的条目精确对应。

回滚策略（Rollback Strategy）

发布必须配套回滚预案。技能文档把回滚按"应用/容器、平台、数据库"分别给出命令范式：

即时回滚命令

# Docker/Kubernetes：指回上一个镜像 kubectl rollout undo deployment/app # Vercel：提升上一个部署 vercel rollback # Railway：重新部署上一个 commit railway up --commit <previous-sha> # 数据库：回滚迁移（若可逆） npx prisma migrate resolve --rolled-back <migration-name>

要点：

• kubectl rollout undo：回滚 Deployment 到上一个 ReplicaSet，是把滚动发布的"实例逐个替换"过程反向执行一次；前提是上一个镜像仍可拉取（印证镜像需按 SHA/commit 打标签留档）。
• vercel rollback与railway up --commit是托管平台的"一键回到上一版本"入口，同样要求历史构建物未被清理。
• 数据库是回滚的真正难点：npx prisma migrate resolve --rolled-back <migration-name>只能把"已执行迁移"标记为回滚，本质要求迁移本身向前兼容——破坏性变更（删列、改类型）往往无法靠回滚命令复原。所以文档强调迁移策略必须"无破坏性改动、向后兼容"，且"Rollback tested in staging"先行验证。

回滚检查清单

在任何一次上线前，按下述清单自检可显著降低"回不去"的风险：

• 上一个镜像/制品仍可用且已打标签
• 数据库迁移向后兼容（无破坏性改动）
• feature flags 能在不发布的情况下禁用新功能
• 已为错误率突增配置监控告警
• 回滚方案已在 staging 环境于生产发布前演练过

其中"feature flags 可不发布即关停新功能"尤其关键：它把"代码上线"与"功能对用户可见"解耦，使金丝雀放大到 100% 后仍保留一条不依赖重新部署的逃生通道。

生产就绪检查清单（Production Readiness Checklist）

这是技能文档的收尾章节，也是可操作性最强的部分——任何生产发布前按下表逐项核对即可形成可审计的发布门禁：

应用（Application）

• 全部测试通过（单元、集成、E2E）
• 代码与配置文件中无硬编码密钥
• 错误处理覆盖所有边界情况
• 日志为结构化输出（JSON）且不含 PII
• health check 端点返回有意义的健康状态

基础设施（Infrastructure）

• Docker 镜像可复现构建（版本已固定/锁定）
• 环境变量已文档化并在启动时校验
• 已设置资源限制（CPU、内存）
• 已配置水平伸缩（最小/最大实例数）
• 所有端点已启用 SSL/TLS

监控（Monitoring）

• 已导出应用指标（请求速率、延迟、错误数）
• 已为"错误率超阈值"配置告警
• 已配置日志聚合（结构化、可检索）
• 已在 health 端点上配置 uptime 监控

安全（Security）

• 依赖已扫描 CVE
• CORS 仅对允许的来源开放
• 公共端点已启用 rate limiting
• 认证与授权已验证
• 已设置安全响应头（CSP、HSTS、X-Frame-Options）

运维（Operations）

• 回滚计划已文档化并测试过
• 数据库迁移已用生产规模数据验证
• 常见故障场景已有 runbook
• 已定义 on-call 轮值与升级路径（escalation path）

这份清单的实用价值在于"分层可增量落地"：前三项（应用、基础设施）决定系统本身是否可靠；监控与安全决定你是否"看得见故障、挡得住入侵"；运维则保证故障出现时有人、有文档、有路径能响应。ECC 的 CI 设计同样体现了这种"门禁"思想——package.json的test脚本串联了validate-agents、validate-commands、validate-rules、validate-skills、validate-hooks等一系列校验器后才执行tests/run-all.js，相当于把"发布前必须全绿"的纪律下沉成了可重复执行的默认动作。

小结：把部署模式沉淀为团队默认动作

回到 deployment-patterns 技能的本质：它把分散在无数事故复盘里的工程经验——策略选型看兼容性、镜像构建看可复现、流水线看门禁前置、健康检查看语义分型、配置看外置与 fail fast、回滚看制品留档与迁移兼容——固化成了一份任何人（包括 Agent 与 LLM）都可调取的技能文档。配合本仓库的 英语基准版、中文版 与 西班牙语版 多语言分发的形式，团队可以让 Claude Code、Codex、Opencode 等 Agent 在"搭建 CI/CD、容器化应用、准备生产发布"等场景中自动唤起这套标准流程，从而把"正确发布"从个人经验变成组织的可复用资产。

实际落地时，建议按三条主线推进：先用本仓库的 docker/plugin-setup/Dockerfile 印证的多阶段 + 固定版本基座改写现有 Dockerfile；再以 .github/workflows/ci.yml 的多环境矩阵 CI 为参照补齐 test → build → staging → smoke → production 流水线；最后把文末生产就绪清单转成发布 PR 的勾选项模板，让每次上线都自带一份可审计的"就绪证据"。

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC