@umacloud/knowledge 1.0.1

package/cicd/05-cases/case-deployment-automation.md

@@ -0,0 +1,221 @@
+---
+id: case-deployment-automation
+title: 部署自动化案例：从手动部署到 GitOps 的转型
+domain: cicd
+category: 05-cases
+difficulty: intermediate
+tags: [agent, automation, case, checklist, cicd, deployment, 关键决策回顾, 概述]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 部署自动化案例：从手动部署到 GitOps 的转型
+
+## 概述
+
+本案例记录一个 50 人研发团队将部署流程从手动 SSH + 脚本模式迁移到 GitOps 模式的
+完整过程。转型历时 3 个月，部署频率从每周 1 次提升到每天 5-8 次，部署失败率从
+15% 降至 2%，平均部署耗时从 45 分钟降至 8 分钟。
+
+## 转型前状态
+
+### 部署流程（手动模式）
+
+```
+1. 开发者在 Slack 通知运维"准备部署"
+2. 运维 SSH 登录服务器（3 台应用服务器）
+3. 手动执行 git pull
+4. 手动执行 npm install && npm run build
+5. 手动重启 PM2 进程
+6. 逐台检查日志确认无报错
+7. 在 Slack 回复"部署完成"
+```
+
+### 核心痛点
+
+| 问题 | 影响 |
+|------|------|
+| 部署耗时 45min+ | 运维被部署占满，无暇做其他工作 |
+| 环境差异 | "我本地可以跑"频繁发生 |
+| 回滚困难 | 需要手动 git revert + 重新构建 |
+| 无法审计 | 不知道谁在什么时候部署了什么版本 |
+| 部署失败率 15% | 漏装依赖、配置遗漏、顺序错误 |
+| 单点依赖运维 | 运维请假时无人可部署 |
+
+## 转型路线图
+
+### 第一阶段：容器化（第 1-4 周）
+
+**目标**: 消除环境差异，构建标准化部署单元
+
+```dockerfile
+# 多阶段构建
+FROM node:18-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --only=production
+COPY . .
+RUN npm run build
+
+FROM node:18-alpine
+RUN addgroup -S app && adduser -S app -G app
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+USER app
+EXPOSE 3000
+CMD ["node", "dist/server.js"]
+```
+
+**成果**:
+- 所有 12 个微服务完成 Docker 化
+- 本地开发使用 docker-compose 统一环境
+- 构建产物从"代码+依赖"变为"不可变镜像"
+
+### 第二阶段：CI 流水线（第 3-6 周）
+
+**目标**: 自动化构建、测试、镜像推送
+
+```yaml
+# .github/workflows/ci.yml
+name: CI
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm ci
+      - run: npm test
+      - run: npm run lint
+
+  build:
+    needs: test
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Build and push
+        run: |
+          docker build -t registry.example.com/app:${{ github.sha }} .
+          docker push registry.example.com/app:${{ github.sha }}
+
+  scan:
+    needs: build
+    runs-on: ubuntu-latest
+    steps:
+      - name: Trivy scan
+        uses: aquasecurity/trivy-action@master
+        with:
+          image-ref: registry.example.com/app:${{ github.sha }}
+          severity: CRITICAL,HIGH
+          exit-code: 1
+```
+
+**成果**:
+- 每次 PR 自动运行测试 + Lint
+- 合并到 main 自动构建镜像并推送
+- 镜像漏洞扫描集成到流水线
+
+### 第三阶段：GitOps 部署（第 5-10 周）
+
+**目标**: 声明式部署，Git 仓库作为唯一真实来源
+
+**工具选型**: ArgoCD + Kustomize
+
+```
+代码仓库（app-repo）          配置仓库（deploy-repo）
+├── src/                      ├── base/
+├── Dockerfile                │   ├── deployment.yaml
+└── .github/workflows/        │   ├── service.yaml
+    └── ci.yml                │   └── kustomization.yaml
+                              ├── overlays/
+                              │   ├── dev/
+                              │   ├── staging/
+                              │   └── prod/
+                              └── argocd/
+                                  └── application.yaml
+```
+
+**部署流程（GitOps 模式）**:
+
+```
+1. CI 构建新镜像 → 推送到 Registry
+2. CI 自动更新 deploy-repo 中的镜像 tag
+3. ArgoCD 检测到 deploy-repo 变更
+4. ArgoCD 对比集群当前状态与期望状态
+5. ArgoCD 自动同步（dev/staging）或等待审批（prod）
+6. 健康检查通过后标记部署成功
+```
+
+### 第四阶段：渐进式发布（第 9-12 周）
+
+**目标**: 灰度发布，降低部署风险
+
+- **Canary 发布**: 新版本先接收 10% 流量，监控 5 分钟无异常后逐步提升
+- **自动回滚**: 错误率 > 1% 或 P99 延迟 > 500ms 自动回滚
+- **Feature Flag**: LaunchDarkly 集成，功能开关与部署解耦
+
+```yaml
+# Argo Rollouts canary 策略
+spec:
+  strategy:
+    canary:
+      steps:
+        - setWeight: 10
+        - pause: { duration: 5m }
+        - setWeight: 30
+        - pause: { duration: 5m }
+        - setWeight: 60
+        - pause: { duration: 5m }
+        - setWeight: 100
+      analysis:
+        templates:
+          - templateName: error-rate
+        startingStep: 1
+```
+
+## 转型效果
+
+| 指标 | 转型前 | 转型后 | 提升 |
+|------|--------|--------|------|
+| 部署频率 | 1 次/周 | 5-8 次/天 | 35x-56x |
+| 部署耗时 | 45 分钟 | 8 分钟 | 5.6x |
+| 部署失败率 | 15% | 2% | 7.5x |
+| 回滚耗时 | 30 分钟 | 2 分钟 | 15x |
+| MTTR | 60 分钟 | 12 分钟 | 5x |
+| 运维人力占比 | 40% 时间做部署 | 5% | 8x |
+
+## 踩过的坑
+
+1. **镜像体积过大**: 初始镜像 1.2GB，多阶段构建后降至 180MB，部署速度提升明显
+2. **配置管理混乱**: 初期把配置硬编码在 Kubernetes YAML 中，后改用 ConfigMap + Sealed Secrets
+3. **ArgoCD 权限过大**: 初期给了 cluster-admin，后收缩到 namespace 级别
+4. **缺少 staging 验证**: 直接从 dev 到 prod 出过事故，补充 staging 环境后稳定
+5. **团队抵触**: 部分开发者不适应 PR 驱动的部署流程，通过结对演示和文档逐步解决
+
+## 关键决策回顾
+
+| 决策 | 选择 | 理由 |
+|------|------|------|
+| 编排工具 | Kubernetes | 团队已有容器基础，K8s 生态最完善 |
+| GitOps 工具 | ArgoCD | 社区活跃，UI 直观，声明式管理 |
+| 配置管理 | Kustomize | 比 Helm 轻量，适合团队规模 |
+| 密钥管理 | Sealed Secrets | 可存入 Git，运维成本低 |
+| 渐进式发布 | Argo Rollouts | 与 ArgoCD 集成好 |
+
+## Agent Checklist
+
+- [ ] 应用是否已完成容器化（Dockerfile + 多阶段构建）
+- [ ] CI 流水线是否覆盖测试/构建/扫描
+- [ ] 配置仓库是否与代码仓库分离
+- [ ] GitOps 工具是否配置环境差异化（dev/staging/prod）
+- [ ] 生产部署是否有审批机制
+- [ ] 渐进式发布（Canary/Blue-Green）是否已实施
+- [ ] 自动回滚策略是否基于业务指标
+- [ ] 密钥管理是否使用 Sealed Secrets 或外部 Vault
+- [ ] 部署审计日志是否完整可追溯
+- [ ] 团队是否完成 GitOps 工作流培训

package/cicd/05-cases/case-gitops-transformation.md

@@ -0,0 +1,212 @@
+---
+id: case-gitops-transformation
+title: GitOps 转型实战案例
+domain: cicd
+category: 05-cases
+difficulty: intermediate
+tags: [agent, case, checklist, cicd, gitops, transformation, 实施步骤, 技术选型]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# GitOps 转型实战案例
+
+## 概述
+
+本案例记录一个 50 人研发团队从传统手动部署迁移到 GitOps 全自动化交付的完整过程。历时 3 个月，部署频率从每周 1 次提升到每天 10+ 次，MTTR 从 2 小时降至 8 分钟。
+
+---
+
+## 背景
+
+### 团队现状（转型前）
+- **团队规模**: 50 人，6 个微服务
+- **部署方式**: SSH 登录服务器手动执行脚本
+- **发布频率**: 每周三下午统一发布
+- **部署耗时**: 每次 2-3 小时（含协调时间）
+- **回滚方式**: 手动替换 JAR 包，重启服务
+- **问题**: 周三下午全员待命，频繁出错，回滚慢，无法追溯变更
+
+### 目标
+- 每个 PR 合并后自动部署到 staging
+- 生产部署通过 Git tag 触发，全自动
+- 回滚时间 < 5 分钟
+- 完整的变更审计追踪
+
+---
+
+## 技术选型
+
+| 工具 | 用途 | 选型理由 |
+|------|------|----------|
+| **GitHub Actions** | CI Pipeline | 团队已用 GitHub，无需额外工具 |
+| **ArgoCD** | CD (GitOps) | K8s 原生，声明式，自动同步 |
+| **Kubernetes** | 运行时 | 已有 K8s 集群 |
+| **Helm** | 包管理 | 模板化 K8s 配置 |
+| **Kustomize** | 环境差异 | Overlay 方式管理多环境 |
+
+---
+
+## 实施步骤
+
+### Phase 1: CI 标准化（第 1-2 周）
+
+```yaml
+# .github/workflows/ci.yml
+name: CI
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm ci
+      - run: npm run lint
+      - run: npm test -- --coverage
+      - run: npm run build
+
+  docker:
+    needs: test
+    if: github.ref == 'refs/heads/main'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: docker/build-push-action@v5
+        with:
+          push: true
+          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
+```
+
+### Phase 2: GitOps 仓库搭建（第 3-4 周）
+
+```
+deploy-manifests/           # 独立仓库
+├── base/                   # 基础配置
+│   ├── deployment.yaml
+│   ├── service.yaml
+│   └── kustomization.yaml
+├── overlays/
+│   ├── staging/
+│   │   ├── kustomization.yaml
+│   │   └── replicas-patch.yaml
+│   └── production/
+│       ├── kustomization.yaml
+│       ├── replicas-patch.yaml
+│       └── resources-patch.yaml
+└── argocd/
+    ├── staging-app.yaml
+    └── production-app.yaml
+```
+
+### Phase 3: ArgoCD 部署（第 5-6 周）
+
+```yaml
+# argocd/production-app.yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: myapp-production
+spec:
+  project: default
+  source:
+    repoURL: https://github.com/org/deploy-manifests
+    path: overlays/production
+    targetRevision: main
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: production
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true
+```
+
+### Phase 4: 自动化镜像更新（第 7-8 周）
+
+CI 构建完成后，自动更新 GitOps 仓库中的镜像标签：
+
+```yaml
+# CI workflow 中的最后一步
+- name: Update GitOps repo
+  run: |
+    git clone https://github.com/org/deploy-manifests
+    cd deploy-manifests
+    kustomize edit set image myapp=ghcr.io/org/myapp:${{ github.sha }}
+    git commit -am "chore: update myapp to ${{ github.sha }}"
+    git push
+```
+
+### Phase 5: 金丝雀发布（第 9-12 周）
+
+```yaml
+# Argo Rollouts 金丝雀策略
+apiVersion: argoproj.io/v1alpha1
+kind: Rollout
+spec:
+  strategy:
+    canary:
+      steps:
+        - setWeight: 10
+        - pause: { duration: 5m }
+        - setWeight: 30
+        - pause: { duration: 5m }
+        - setWeight: 60
+        - pause: { duration: 5m }
+        - setWeight: 100
+      canaryMetadata:
+        labels:
+          role: canary
+```
+
+---
+
+## 结果数据
+
+| 指标 | 转型前 | 转型后 | 改善 |
+|------|--------|--------|------|
+| 部署频率 | 1次/周 | 10+次/天 | **70x** |
+| 部署耗时 | 2-3小时 | 3分钟 | **40x** |
+| 回滚时间 | 30-60分钟 | 3分钟 (git revert) | **15x** |
+| MTTR | 2小时 | 8分钟 | **15x** |
+| 部署失败率 | 15% | 2% | **87%↓** |
+| 变更可追溯性 | 无 | 100% Git 审计 | ✅ |
+
+---
+
+## 经验教训
+
+### 做得好的
+1. **先 CI 后 CD** — 没有好的 CI，GitOps 毫无意义
+2. **独立部署仓库** — 应用代码和部署配置分离，权限清晰
+3. **渐进式推进** — staging 先行，production 跟进
+
+### 踩过的坑
+1. **Secret 管理** — 初期把 Secret 放在 Git 仓库（错误！），后改用 Sealed Secrets
+2. **ArgoCD 权限** — 初期所有人都有 production sync 权限，后收紧为 RBAC
+3. **镜像标签** — 初期用 `latest` 标签（错误！），后改用 Git SHA
+
+---
+
+## Agent Checklist
+
+Agent 在设计 CI/CD 流程时必须检查:
+
+- [ ] CI 是否覆盖 lint/test/build/scan 全流程？
+- [ ] 镜像标签是否使用 Git SHA（非 latest）？
+- [ ] 部署配置是否与应用代码分离？
+- [ ] Secret 是否加密存储（Sealed Secrets/Vault）？
+- [ ] 是否有金丝雀/蓝绿发布策略？
+- [ ] 回滚是否可以通过 git revert 完成？
+- [ ] 是否有变更审计追踪？
+- [ ] 生产部署是否需要审批？
+
+---
+
+**文档版本**: v1.0
+**最后更新**: 2026-03-28
+**质量评分**: 88/100

package/cicd/06-glossary/cicd-glossary.md

@@ -0,0 +1,114 @@
+---
+id: cicd-glossary
+title: CI/CD 术语表 (CI/CD Glossary)
+domain: cicd
+category: 06-glossary
+difficulty: intermediate
+tags: [agent, checklist, cicd, glossary, 分支模型, 构建策略, 流水线基础, 版本管理]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# CI/CD 术语表 (CI/CD Glossary)
+
+> 收录 40+ 核心 CI/CD 术语，覆盖流水线基础、构建策略、部署策略、分支模型和版本管理等领域。
+> 适用于 DevOps 评审、Pipeline 设计、团队培训等场景。
+
+---
+
+## 流水线基础
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Pipeline | Pipeline / 流水线 | 将代码从提交到部署的完整自动化流程。由多个 Stage 组成，按顺序或并行执行。Pipeline 的设计质量直接决定团队交付效率和发布可靠性。 |
+| Stage | Stage / 阶段 | Pipeline 中的逻辑分组，如 build、test、deploy。同一 Stage 内的 Job 可并行执行，Stage 之间按顺序执行。典型 Stage 链：lint → build → test → security → deploy。 |
+| Job | Job / 任务 | Pipeline 中最小的可执行单元，在一个 Runner 上运行。每个 Job 包含一组 Step/Script。Job 可以设置依赖关系、条件触发和超时策略。 |
+| Step | Step / 步骤 | Job 内部的单个命令或 Action。Step 按顺序执行，任一 Step 失败会导致 Job 失败（除非标记为 `continue-on-error`）。 |
+| Runner | Runner / 执行器 | 执行 Pipeline Job 的计算环境。可以是 CI 平台提供的云端 Runner，也可以是用户自建的 Self-Hosted Runner。Runner 的性能直接影响构建速度。 |
+| Trigger | Trigger / 触发器 | 启动 Pipeline 的事件源。常见触发器：push、pull_request、schedule（定时）、manual（手动）、API 调用、上游 Pipeline 完成。 |
+| Artifact | Artifact / 制品 | 构建过程产生的输出文件（二进制包、Docker 镜像、测试报告等）。制品可在 Job 之间传递，也可上传到制品仓库供部署使用。 |
+| Cache | Cache / 缓存 | 在 Pipeline 运行之间持久化的文件（如 `node_modules`、`.m2` 目录），用于加速后续构建。与 Artifact 的区别：Cache 用于加速，Artifact 用于传递产出物。 |
+
+---
+
+## 构建策略
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Matrix Build | Matrix Build / 矩阵构建 | 使用参数组合自动生成多个 Job 实例的构建策略。例如：`os: [ubuntu, macos]` × `node: [18, 20]` 生成 4 个 Job，确保在多种环境下通过测试。 |
+| Incremental Build | Incremental Build / 增量构建 | 仅编译和测试受代码变更影响的部分，而非全量构建。通过依赖图分析（如 Nx、Turborepo、Bazel）实现，可将构建时间减少 50-90%。 |
+| Reusable Workflow | Reusable Workflow / 可复用工作流 | 可被其他 Pipeline 调用的模板化工作流（GitHub Actions 的 `workflow_call`、GitLab 的 `include`）。避免在多个仓库中重复相同的 CI 配置。 |
+| Composite Action | Composite Action / 组合 Action | GitHub Actions 中将多个 Step 封装为一个可复用 Action 的方式。比 Reusable Workflow 更轻量，适合封装常见的构建/测试/部署片段。 |
+| Self-Hosted Runner | Self-Hosted Runner / 自建执行器 | 用户自行部署和管理的 Pipeline 执行器。优势：可访问内网资源、更大的计算资源、持久化缓存。劣势：需自行维护安全性和可用性。 |
+| Build Cache | Build Cache / 构建缓存 | 存储构建中间产物（编译结果、依赖包）以加速后续构建的技术。包括 Docker Layer Cache、npm/pip 缓存、编译器增量编译缓存等。 |
+
+---
+
+## 部署策略
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Blue-Green Deployment | Blue-Green Deployment / 蓝绿部署 | 维护两套完全相同的生产环境（Blue 和 Green），新版本部署到非活跃环境，验证通过后通过流量切换（如负载均衡器）将用户导向新环境。优势：零停机、秒级回滚。劣势：资源成本翻倍。 |
+| Canary Deployment | Canary Deployment / 金丝雀部署 | 先将新版本部署到一小部分实例（如 5%），观察关键指标（错误率、延迟、业务指标）无异常后逐步扩大比例（5% → 25% → 50% → 100%）。比蓝绿部署更节省资源，但实现更复杂。 |
+| Rolling Update | Rolling Update / 滚动更新 | 逐步用新版本实例替换旧版本实例，过程中新旧版本共存。Kubernetes 的默认部署策略。通过 `maxSurge` 和 `maxUnavailable` 参数控制更新速度和可用性。 |
+| A/B Testing Deployment | A/B Testing / A/B 测试部署 | 基于用户特征（地区、设备、用户分群）将流量路由到不同版本，用于验证功能效果。与 Canary 的区别：A/B 是按用户特征分流，Canary 是按比例随机分流。 |
+| Feature Flag | Feature Flag / 功能开关 | 通过配置（非代码部署）控制功能的开启和关闭。允许代码已部署但功能未对用户可见，实现部署与发布解耦。常用平台：LaunchDarkly、Unleash、Flagsmith。 |
+| GitOps | GitOps | 以 Git 仓库为单一可信源管理基础设施和应用部署的实践。变更通过 PR 提交到 Git，自动化工具（ArgoCD、Flux）监听并同步到集群。核心原则：声明式、版本化、自动化、自愈。 |
+| Immutable Deployment | Immutable Deployment / 不可变部署 | 每次部署创建全新的基础设施实例而非原地更新。部署后的实例不可修改，需要变更时创建新实例并销毁旧实例。消除配置漂移和"雪花服务器"问题。 |
+
+---
+
+## 分支模型
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Trunk-Based Development | Trunk-Based Development / 主干开发 | 所有开发者直接在 main/trunk 分支提交（或使用极短生命周期的 feature 分支），保持主干始终可发布。要求高质量的自动化测试和 Feature Flag 支持。适合持续部署场景。 |
+| Git Flow | Git Flow | Vincent Driessen 提出的分支模型：`main`（生产）、`develop`（开发主线）、`feature/*`（功能分支）、`release/*`（发布准备）、`hotfix/*`（紧急修复）。适合有固定发布周期的项目，但分支管理复杂度较高。 |
+| GitHub Flow | GitHub Flow | 简化的分支模型：只有 `main` 分支和 feature 分支。开发在 feature 分支进行，通过 PR 合并到 main，合并后立即部署。比 Git Flow 简单，适合持续交付团队。 |
+| Release Branch | Release Branch / 发布分支 | 从主干切出的专用分支，用于发布前的最终测试和 Bug 修复。发布完成后合并回主干并打 Tag。在需要支持多版本并行维护的场景中使用。 |
+| Hotfix Branch | Hotfix Branch / 热修复分支 | 从生产分支直接切出的紧急修复分支，用于快速修复生产事故。修复完成后同时合并到生产分支和开发主线，确保修复不丢失。 |
+
+---
+
+## 版本管理
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| SemVer | Semantic Versioning / 语义化版本 | 版本号格式：`MAJOR.MINOR.PATCH`。MAJOR = 不兼容的 API 变更，MINOR = 向后兼容的功能新增，PATCH = 向后兼容的 Bug 修复。预发布版本附加 `-alpha.1`、`-beta.2` 等后缀。 |
+| CalVer | Calendar Versioning / 日历版本 | 基于日期的版本号格式，如 `2024.03.15` 或 `24.3`。适合发布周期固定、不需要表达 API 兼容性的项目（如 Ubuntu: 24.04）。 |
+| Changelog | Changelog / 变更日志 | 记录每个版本的变更内容，按版本号倒序排列。遵循 Keep a Changelog 格式：Added / Changed / Deprecated / Removed / Fixed / Security。自动化工具：Conventional Commits + standard-version。 |
+| Tag | Tag / 标签 | Git 中标记特定提交的引用，通常用于标记发布版本（如 `v1.2.3`）。分为轻量标签（仅指针）和注释标签（包含作者、日期、消息）。发布版本应使用注释标签。 |
+| Conventional Commits | Conventional Commits / 约定式提交 | 提交信息格式规范：`type(scope): description`。type 包括 feat、fix、docs、style、refactor、test、chore 等。支持自动生成 Changelog 和版本号。 |
+
+---
+
+## 质量与安全
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Quality Gate | Quality Gate / 质量门禁 | Pipeline 中的自动化检查点，代码必须通过指定阈值才能继续。常见门禁：测试覆盖率 ≥ 80%、零 Critical 漏洞、Lint 零错误、代码 Review 至少一人 Approve。 |
+| SAST | Static Application Security Testing | 在不运行程序的情况下分析源代码中的安全漏洞。工具：CodeQL、Semgrep、SonarQube。优势：覆盖面广，开发阶段即可发现。劣势：误报率较高。 |
+| SCA | Software Composition Analysis | 分析项目依赖中的已知漏洞。工具：Snyk、Trivy、Dependabot。检查范围包括直接依赖和传递依赖，对照 CVE 数据库匹配漏洞。 |
+| DAST | Dynamic Application Security Testing | 在运行状态下通过模拟攻击检测应用漏洞。工具：OWASP ZAP、Burp Suite。需要可访问的部署环境，通常在 staging 阶段执行。 |
+
+---
+
+## 运行时与环境
+
+| 术语 | 英文全称 | 定义 |
+|------|---------|------|
+| Environment Promotion | Environment Promotion / 环境晋级 | 制品从低环境逐步推进到高环境的过程：dev → staging → production。每次晋级前需通过对应环境的质量门禁。核心原则：同一制品跨环境部署，仅配置不同。 |
+| Infrastructure as Code | IaC / 基础设施即代码 | 用代码（Terraform、Pulumi、CloudFormation）定义和管理基础设施的实践。IaC 确保环境配置可版本化、可审计、可复现。是 CI/CD 中环境一致性的基础保障。 |
+| Container Registry | Container Registry / 容器镜像仓库 | 存储和分发 Docker/OCI 镜像的服务。常用方案：Docker Hub、GitHub Container Registry（ghcr.io）、Harbor（自建）、AWS ECR、Google GCR。CI 构建的镜像推送到 Registry，部署时从 Registry 拉取。 |
+| Deployment Slot | Deployment Slot / 部署槽 | Azure App Service 提供的零停机部署机制。新版本部署到预热槽（Staging Slot），验证通过后与生产槽（Production Slot）交换流量。概念类似蓝绿部署但由平台原生支持。 |
+| Pipeline as Code | Pipeline as Code / 流水线即代码 | 将 CI/CD Pipeline 定义为代码文件（如 `.github/workflows/*.yml`、`Jenkinsfile`、`.gitlab-ci.yml`）并纳入版本控制的实践。确保 Pipeline 变更可审计、可回滚、可测试。 |
+
+---
+
+## Agent Checklist
+
+- [ ] 术语覆盖所有要求的关键词：Pipeline/Stage/Job/Runner/Artifact/Cache/Matrix Build/Reusable Workflow/Self-Hosted Runner/Blue-Green/Canary/Rolling Update/Feature Flag/Trunk-Based/Git Flow/SemVer/Changelog
+- [ ] 每个术语包含英文全称和中文定义
+- [ ] 术语按领域分组（流水线基础、构建策略、部署策略、分支模型、版本管理、质量与安全）
+- [ ] 使用统一的表格格式
+- [ ] 定义准确、专业，包含使用场景和工具推荐
+- [ ] 文件超过 100 行

package/cicd/cicd-blueprint-deep-dive.md

@@ -0,0 +1,38 @@
+---
+id: cicd-blueprint-deep-dive
+title: cicd-blueprint-deep-dive
+domain: cicd
+category: cicd-blueprint-deep-dive.md
+difficulty: intermediate
+tags: [blueprint, cicd, deep, dive, 环节深度知识库]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## CI/CD 环节深度知识库
+
+### 目标
+- 让每次发布都具备可重复、可审计、可回滚能力。
+
+### 流水线蓝图
+- 代码阶段：格式、静态检查、类型检查。
+- 测试阶段：单元、集成、关键链路回归。
+- 安全阶段：依赖漏洞、镜像扫描、配置风险检测。
+- 交付阶段：构建制品、签名验签、版本追踪。
+- 发布阶段：灰度放量、健康检查、自动回滚。
+
+### 发布策略
+- 标准发布：小步快跑，单次变更控制。
+- 金丝雀发布：核心指标稳定后再扩容。
+- 蓝绿发布：高风险版本优先采用。
+- 失败回退：明确回滚触发条件与自动化脚本。
+
+### 门禁规则
+- 未通过任何关键门禁不得进入发布阶段。
+- 发布后必须自动检查错误率、延迟、关键交易成功率。
+- 失败自动回滚并通知责任人。
+
+### 常见失败模式
+- 把 CI 当构建工具，不把 CI 当质量门禁系统。
+- 发布成功但缺少可观测验证步骤。

package/cicd/release-readiness-gate.md

@@ -0,0 +1,37 @@
+---
+id: release-readiness-gate
+title: release-readiness-gate
+domain: cicd
+category: release-readiness-gate.md
+difficulty: intermediate
+tags: [cicd, gate, readiness, release, 发布就绪门禁清单]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 发布就绪门禁清单
+
+### 目标
+- 用统一发布门禁阻断高风险变更，保证发布可控。
+
+### 必过门禁
+- 代码质量：lint、类型检查、静态分析通过。
+- 测试质量：核心回归通过、阻断缺陷清零。
+- 安全质量：高危漏洞清零，密钥泄露检查通过。
+- 构建质量：制品可追溯、版本标签一致。
+- 运维质量：发布与回滚脚本可执行。
+
+### 发布前检查
+- 是否完成变更影响评估与回滚预案。
+- 是否完成灰度策略与阈值配置。
+- 是否完成关键指标基线确认。
+
+### 发布后检查
+- 错误率、时延、成功率是否在阈值内。
+- 告警是否异常增加。
+- 关键业务链路是否连续成功。
+
+### 常见失败模式
+- 只检查构建成功，不检查运行质量。
+- 门禁定义存在但未强制执行。