ci-cd-pipelinelisted

# CI/CD 流水线 ## 何时用 - 新建或修改任何 CI/CD 配置文件（GitHub Actions、GitLab CI、Jenkinsfile 等）。 - 流水线频繁失败、构建结果不一致、部署不可回滚时。 - 接入新项目或新环境时设计部署策略。 - 发现流水线中存在硬编码密钥或依赖隐式环境时。 ## 核心规则 ### 1. 阶段清晰，前序失败即停 **规则：** 流水线按 `lint → test → build → deploy` 顺序分阶段，每个阶段只做一件事；前序阶段失败，后续阶段不执行。 **为什么：** AI 生成的 CI 配置最常见的问题是把 lint、测试、构建、部署全塞进一个 job，或者测试失败后继续往生产部署。曾见过真实事故：测试报告里明确有失败用例，因为 YAML 里 `continue-on-error: true` 被随手加上，部署仍然执行，问题代码上了生产。 **怎么做：** ```yaml # GitHub Actions 示例 jobs: lint: runs-on: ubuntu-latest steps: [...] test: needs: lint # ✅ 显式依赖，lint 失败即停 runs-on: ubuntu-latest steps: [...] build: needs: test # ✅ 测试通过才构建 steps: [...] deploy: needs: build if: github.ref == 'refs/heads/main' # ✅ 只部署 main 分支 steps: [...] ``` - 不加 `continue-on-error: true`，除非确实需要收集所有失败报告再决策。 --- ### 2. 构建可重复：锁版本 + 缓存 + 产物带标识 **规则：** 锁定所有工具和依赖的版本；缓存依赖目录加速重复构建；构建产物打上版本标识（commit SHA 或语义版本），使每次构建可追溯。 **为什么：** AI 配置 CI 时倾向于用 `npm install`（不加 `--frozen-lockfile`）、不固定 Action 版本（`uses: actions/checkout@main`）、不给镜像打 tag。结果：同一份代码在不同时间构建出不同产物，线上出问题却无法精确定位是哪个版本，依赖每次都重新下载让构建平均耗时从 30 秒变成 5 分钟。 **怎么做：** ```yaml - uses: actions/setup-node@v4 # ✅ 固定 Action 版本 with: node-version: '20' cache: 'npm' # ✅ 启用依赖缓存 - run: npm ci # ✅ 使用 lockfile，拒绝版本漂移 - name: Build & tag image run: | IMAGE_TAG="${{ github.sha }}" # ✅ 用 commit SHA 作镜像标签 docker build -t myapp:${IMAGE_TAG} . docker push myapp: