CI/CD 与发布速查
流水线设计与缓存、构建与制品管理、多环境配置与密钥、蓝绿/金丝雀/滚动发布、质量门禁与回滚：持续交付速查。
流水线设计54 条
阶段划分、触发策略与并行缓存
CI、持续交付与持续部署的区别热门
CI 强调频繁集成与自动验证；持续交付要求提交处于可发布状态、发布由业务决定；持续部署把上生产也自动化。
流水线阶段划分（Stages）
把交付过程拆成构建、测试、打包、部署等有序阶段：默认阶段间串行、阶段内作业并行，既表达流程约束也决定整体时长。
一次构建、多环境部署（Build Once, Deploy Many）
同一份不可变制品从测试环境一路晋级到生产，避免「每环境重新构建」带来的行为漂移与不可回滚。
流水线即代码（Pipeline as Code）
把流水线定义写成仓库里的版本化文件（.gitlab-ci.yml / workflow yaml / Jenkinsfile），随代码评审、回滚与审计。
合并请求流水线（MR/PR Pipeline）
以「合并后的结果」为准验证变更：GitLab 合并请求事件管道、GitHub pull_request 事件，通过后合并按钮才可点。
流水线触发方式总览
推送、合并请求、标签、定时、手动与 API 触发各有适用场景，组合使用才能覆盖「日常验证 + 按需发布」。
手动门与人工审批作业
把「上生产」「删数据」等敏感动作设为手动触发或需审批：自动化负责准备，由人按下最后一步。
缓存与制品的区别（Cache vs Artifacts）
缓存是「可再生的加速物料」，制品是「作业间交付物并对用户可见」：混用会导致产物丢失或缓存污染。
标签发布流水线（Tag Pipeline）
以版本标签作为发布入口：标签不可移动，天然适合绑定制品与发布记录，配合保护标签限制创建权限。
DAG 依赖加速（needs）
用依赖图替代「整阶段等待」：作业只等自己真正需要的上游，关键路径缩短，反馈更快。
分支流水线（Branch Pipeline）
针对分支推送的常规验证流水线：工作分支跑测试与静态检查，默认分支额外构建可发布制品。
缓存键设计（Cache Key）
缓存键决定命中率与正确性：按依赖锁文件哈希生成键，依赖变更自动失效，避免用错缓存。
主干开发（Trunk-Based Development）
短生命周期分支、频繁合入主干，未完成功能用特性开关隐藏；直接减少合并冲突与集成风险。
定时流水线（Scheduled Pipeline）
按 cron 计划运行：夜间全量回归、依赖巡检、安全扫描、环境清理，把长耗时与非紧急任务移出提交路径。
矩阵构建（Matrix）
一个定义展开成多组参数组合（多版本、多平台、多配置），天然并行，适合跨语言版本与跨操作系统验证。
并发控制与部署互斥（resource_group / concurrency）
对同一环境的部署加互斥锁：同一时刻只允许一个流水线操作该环境，避免两个版本相互覆盖。
流水线内置安全扫描
把 SAST、依赖、密钥、容器与 IaC 扫描挂在流水线上，问题尽量在合并前拦截；结果并入报告与门禁。
并行作业与测试分片
把一套测试切成多片并发执行：GitLab parallel:N 自动分配分片序号，Jest/Pytest 等按分片参数取子集。
执行器类型与隔离级别
执行器决定作业跑在什么环境里：shell 复用宿主机（快但隔离弱）、docker 提供镜像隔离、Kubernetes 按 Pod 弹性调度。
快速失败设计（Fail Fast）
把便宜、致命的检查放最前（编译、lint、单测），失败立即终止后续昂贵环节，节省时间与算力。
环境晋级链（Environment Promotion）
同一制品按 dev → staging → prod 逐级晋级：每级记录部署结果，敏感环境用审批与保护规则控制。
流水线提速清单
从等待结构上压缩时长：并行化、缓存、DAG、增量与预构建镜像，逐项测量收益再推广。
Runner 标签与作业分发
用标签把作业精确调度到合适执行器：Linux 构建机、macOS 打包机、GPU 节点各取所需。
自动取消冗余流水线
同一分支连续推送时取消未跑的旧流水线：省资源、缩短反馈，避免「旧提交的结果淹没新提交」。
路径过滤触发（Paths / changes）
只对改动的目录或文件类型触发对应流水线：文档改动不跑构建，后端改动不跑前端包。
可复用流水线模板
把通用片段抽成模板：GitLab include/extends 与 CI 组件、GitHub 可复用工作流、Jenkins 共享库，避免复制粘贴漂移。
软件供应链安全（SLSA 视角）
从源码、构建到分发逐段加固：来源可信、构建可证明、制品可签名、分发可校验——SLSA 框架把这些目标分级。
发布就绪检查清单
发布前逐项勾选：变更内容、验证证据、回滚方案、观察指标、值守安排——把「能不能发」变成清单问题。
缓存策略与失效控制（policy）
通过 pull / push / pull-push 控制缓存读写角色：由受信任的作业负责写缓存，其余只读，降低污染面。
失败重试策略（Retry）
只对基础设施类抖动做有限重试：Runner 掉线、拉取超时等；业务失败不重试，避免掩盖缺陷。
超时控制（Timeout）
为作业与流水线设置超时：挂死构建不会无限占用资源，排队与告警也更可靠。
单仓多项目流水线（Monorepo）
按受影响项目拆分流水线：只构建改动目录及其依赖方，主流程用路径条件与目录级子管道组织。
依赖漏洞扫描（SCA）接入
对第三方依赖清单做已知漏洞比对：npm audit、pip-audit、OSV 等工具可离线接入 CI，按严重级决定阻断。
保持主干可发布（Green Build）
主干任何时刻处于绿色可发布状态：它是持续交付的前提，也是回滚与热修都依赖的基线。
流水线权限最小化
CI 令牌按最小权限发放：默认只读起步，按作业申请写入范围，避免单个作业被利用后横向扩散。
Runner 弹性伸缩
按队列水位自动增减构建机：GitLab Runner Autoscaler（docker-autoscaler / instance 执行器）与云上自托管 Runner 均支持按需扩容。
允许失败作业（allow_failure / continue-on-error）
把「实验结果」「非阻塞扫描」标记为允许失败：不阻断主流程，但结果仍可在页面上查阅。
流水线变量分层
变量来自多处（平台配置、作业级、触发时注入、下游传递），同名覆盖按优先级生效：合并规则必须在团队内说清。
流水线生成 SBOM
构建时生成软件物料清单（SPDX/CycloneDX）并与制品同存：满足安全审计、许可证盘点与供应链溯源需求。
部署流水线模型
经典的阶段化模型：提交 → 自动化验收 → 用户验收 → 发布，每个阶段可自动晋级或人工门控（Humble & Farley）。
合并列车（Merge Train）
合并请求按队列串行合入并验证「合并后」组合结果，保持主干始终可发布；冲突或失败自动回退队列。
父子流水线（Child Pipeline）
父管道按条件触发子管道（独立配置文件、独立复杂度）：单仓多项目或动态生成场景的常用组织方式。
评审预览环境（Review App）
为每个合并请求部署临时全栈预览：评审人点开链接即可验证 UI 与接口，发布前发现集成问题。
构建来源证明（Artifact Attestation）
为制品生成签名的构建来源证明：说明「谁在什么环境用什么源码构建」，部署侧可校验后放行。
小批量变更（Small Batch）
同时发布的变更越少，定位与回滚越容易：DORA 研究显示批量大小与变更失败率相关，小步提交是前置条件。
合并队列（GitHub Merge Queue）
按队列把多个 PR 合成临时分支验证后再合入主干：解决「各自全绿、合起来红」的语义冲突问题。
流水线时长预算
为不同级别流水线设定时长目标（如分支级 10 分钟内、主干级 30 分钟内），超预算触发专项治理。
外部贡献者 PR 的安全处理
来自 fork 的代码默认不可信：不要给它机密与写权限；需要验证时用无密环境，并谨慎处理特殊触发事件。
可复现构建（Reproducible Build）
相同源码、相同工具链、相同环境下构建出逐字节一致的产物：让「验证过的内容」可被第三方独立复算。
构建失败处理策略
约定失败后的响应：谁修、多久内修、能否继续合并；配合「停止线」机制避免问题顺流到发布环节。
流水线度量指标
用数据治理流水线：成功率、时长、排队、重跑率、缓存命中与失败分类，按月复盘形成改进循环。
封闭构建（Hermetic Build）
构建过程不访问网络、依赖全部预先声明并冻结：可复现性、可缓存性与供应链安全的共同基础。
流水线通知与告警
把流水线状态推到人所在的地方（群机器人、邮件、MR 评论），按「需要行动」分级避免噪声淹没信号。
缓存投毒的防护
共享缓存可被写坏：限制不受信代码写缓存，隔离分支缓存作用域，对关键制品保留校验。
构建与制品管理58 条
构建产物、版本号与制品库
语义化版本（SemVer）
MAJOR.MINOR.PATCH 三段含义明确：不兼容变更升主版本、向下兼容新增加次版本、修复加修订号；预发布与构建元数据有专门语法。
构建制品（Artifact）的定义与形态
构建输出中需要被保存、传递与部署的那部分：二进制、容器镜像、包文件、前端静态资源或归档文件。
容器镜像标签策略
组合使用多种标签：语义版本用于追溯、SHA 标签用于精确定位、环境标签（可选）用于指向当前部署；避免只依赖浮动标签。
latest 标签的坑
latest 只是「最近推送」的别名：不表达版本、可被覆盖、容易造成环境漂移，生产部署应避免依赖它。
Docker 多阶段构建
在同一个 Dockerfile 中区分构建阶段与运行阶段：编译依赖留在构建层，运行镜像只带产物，体积与攻击面同步缩小。
不可变制品原则
制品一经发布即冻结：内容、标签、校验和不再修改，修复通过发布新版本完成。
镜像摘要固定（Digest Pinning）
用 image@sha256:… 引用镜像：内容寻址、不受标签重推影响，是「引用即事实」的部署方式。
预发布版本号（alpha / beta / rc）
用预发布后缀标记未定稿版本，按字典序比较且低于同段正式版：alpha < beta < rc < 正式版。
锁文件原则（跨生态共通）
锁文件把「这次用的确切版本」固化下来：提交入库、CI 按锁安装、升级以变更单形式评审，是构建可复现的前提。
提交散列作为版本标识
用 commit SHA（常取前 7-12 位）标识构建来源：全球唯一、不可追溯伪造，适合内部构建与镜像标签。
制品晋级（Promotion）
把验证过的制品从快照区复制/提升到发布区：晋级是「移动引用」而不是重新构建，保留完整校验链路。
GitLab Container Registry
项目自带的镜像仓库：镜像路径与项目对应，作业内用 CI_JOB_TOKEN 即可登录推送，支持清理策略控制空间。
BuildKit 缓存导出与复用
把构建缓存导出到镜像仓库或共享后端（--cache-to/--cache-from）：换机器、换流水线也能吃到缓存，构建显著提速。
制品库类型与布局
制品库按用途分层：代理缓存（proxy）、私有托管（hosted）、聚合组（group/虚拟仓库），配合快照与发布两条通道。
npm ci 与锁文件
npm ci 严格按 package-lock.json 安装（会先删除 node_modules）：CI 中用于保证依赖可复现，快于 npm install。
依赖更新机器人（Dependabot / Renovate）
自动提交依赖升级 PR：按兼容级别分组、限定频率与并发，配合 CI 门禁评审后合并，让升级从「大工程」变成「小节奏」。
基础镜像选择与维护
选官方或可信镜像、固定到具体版本（或 digest），建立定期更新通道：基础镜像的漏洞会传导到所有上层镜像。
制品漏洞扫描
对镜像/包扫描已知漏洞并输出结构化结果：构建后扫描、入库扫描与准入扫描多点位配合，高危按策略阻断。
git describe 生成版本描述
基于最近标签生成可读描述（如 v1.8.0-12-gabc1234）：表明距离上个版本多少个提交、当前提交是什么。
多架构镜像（Manifest List / OCI Index）
一个标签对应多架构镜像清单：拉取时按节点架构自动选择，ARM 与 x86 混合集群无需分开维护标签。
Nexus Repository 要点
多格式制品仓库：支持 Maven、npm、PyPI、Docker（含代理）等格式，proxy/hosted/group 三类仓库覆盖代理缓存与私有托管。
Harbor 要点
CNCF 毕业的容器镜像仓库：项目级多租户、镜像复制、漏洞扫描（Trivy）、签名与不可变标签策略，适合自建生产镜像库。
镜像与制品清理策略
按「保留最近 N 个 + 指定标签模式」清理历史版本：先审计引用关系，再让规则逐步收紧，避免误删可回滚版本。
Go Modules 与 GOPROXY
go.mod 声明依赖与版本、go.sum 记录校验和；通过 GOPROXY 控制下载来源，私有模块用 GOPRIVATE 排除公共代理与校验库。
镜像瘦身要点
在保证可调试的前提下压缩镜像：清理包缓存、多阶段构建、选择更小的基础镜像，并用工具量化体积变化。
镜像签名（cosign / Sigstore）
对镜像摘要签名并支持后续校验：keyless 模式用 OIDC 身份签名，签名与证书进透明日志（Rekor），降低密钥托管负担。
构建号与流水线序号
单调递增的构建编号（CI_PIPELINE_IID / GITHUB_RUN_NUMBER / BUILD_NUMBER）用于区分同名版本的多次构建，方便追溯与排序。
GitHub Packages 与 GHCR
GitHub 生态的包与容器镜像托管（ghcr.io）：与仓库权限打通，GITHUB_TOKEN 可认证，支持包级可见性与继承仓库权限。
构建缓存挂载（cache mounts）
把包管理器与编译缓存目录挂进 RUN 步骤：加速重复构建且不进入镜像层，避免把缓存体积带进产物。
Dockerfile 层顺序与缓存命中
按变化频率排序：低频的依赖声明在前、易变的源码在后，使代码改动不触发依赖重装，构建缓存持续命中。
日历版本（CalVer）
用发布年月日构造版本（如 2026.10、26.10.0），让「新旧」一眼可见；兼容性语义需另配规则或搭配 semver 补丁位。
OCI 制品与 ORAS
OCI registry 不只能存镜像：Helm Chart、SBOM、签名、安装包都可以作为 OCI 制品存放，复用同一套仓库与权限。
Artifactory 要点
企业级制品平台：多格式支持、虚拟仓库聚合、基于元数据的检索与提升（promotion），以及跨站点复制。
Maven SNAPSHOT 语义
SNAPSHOT 表示开发中的快照版本：同一坐标可发布多次、带时间戳解析，不应用于正式发布与长期依赖。
npm 包发布要点
发布到 registry 的最小流程：名称与版本唯一、权限与双因素认证、dist-tag 管理发布通道，可附加 provenance 声明来源。
Python 依赖锁定
用 pip-tools / Poetry / uv 等生成含全部传递依赖与哈希的锁文件；CI 按锁安装，升级走显式产物变更。
distroless 镜像
只含运行时与应用依赖、没有包管理器与 shell：缩小攻击面与体积，代价是排查手段受限（需借助旁路调试）。
依赖固定策略（版本与摘要）
按风险选择固定级别：精确版本 > 范围约束 > 浮动版本；容器基础镜像与关键依赖可固定到内容摘要。
制品保留与归档策略
按用途分层保留：发布版长期（覆盖回滚与合规期）、预发布短期、构建缓存可弃；归档走冷存储并保留检索入口。
AWS ECR 要点
托管容器镜像仓库：IAM 控制访问、生命周期策略自动清理、支持跨区域与跨账号复制，常用命令围绕 get-login-password 展开。
镜像仓库垃圾回收
删除 manifest/标签后，底层 blob 仍占用存储：需要执行仓库自己的垃圾回收流程（必要时停写或只读模式）。
Gradle 构建缓存
任务级缓存：相同输入的任务直接复用结果（本地与远程两类），配合配置缓存进一步减少配置阶段开销。
go.sum 校验和机制
go.sum 记录模块内容的哈希：下载内容与记录不一致时构建失败，抵御依赖内容被替换。
Alpine 与 glibc 兼容性
Alpine 使用 musl libc：体积小，但与依赖 glibc 的预编译二进制不兼容；DNS 解析等行为也可能与常见发行版不同。
构建上下文与 .dockerignore
构建上下文会先传给 Build 守护进程：用 .dockerignore 排除 .git、node_modules、密钥与临时文件，减少传输与被误拷风险。
GPG 签名发布物
为发布包与标签提供加密签名：校验来源与完整性（非加密机密），密钥应离线保存并配合轮换策略。
校验和文件（Checksums）
发布制品附带 SHA-256 校验和并说明验证方式：传输损坏与内容替换都能被下游发现，是发布页的基础配套。
SLSA 构建等级（L1-L3）
SLSA v1.0 以轨道与等级描述供应链保障：构建轨道 L1 过程自动化可追溯、L2 托管构建并生成签名证明、L3 强化隔离构建。
标签不可变策略（仓库侧）
在仓库开启标签不可变（如 ECR tag immutability、Harbor 标签规则）：从制度层面阻止「同标签覆盖」，保证引用可信。
制品库认证方式
登录凭据的安全管理：密码走 stdin 或 credential helper，不用命令行明文；CI 用机器人账号、作业令牌或云联邦身份。
Python 分发形态（wheel 与 sdist）
wheel（.whl）是预构建分发、安装快；sdist（.tar.gz）需要目标环境本地构建，易受系统依赖影响。
SBOM 之 SPDX 格式
SPDX 是 Linux 基金会发起的软件物料清单规范：以包、许可证、关系为核心组织信息，广泛用于合规与供应链审计。
SBOM 之 CycloneDX 格式
OWASP 发起的轻量 SBOM 规范：以组件与依赖关系为主，扩展到漏洞（VEX）与服务模型，工具生态活跃。
构建证明（Attestation）实践
把「谁、用什么、怎么构建的」写成可验证声明（in-toto/证明规范），随制品发布并可被部署侧校验。
单仓构建工具概览（Nx / Turborepo / Bazel）
用依赖图驱动「只构建受影响目标」：affected 概念配合远程缓存，把 monorepo 的全量构建变成增量构建。
构建确定性技巧（SOURCE_DATE_EPOCH 等）
消除构建中的非确定性来源：时间戳用 SOURCE_DATE_EPOCH、排序稳定、路径规范化，让「同输入同输出」可测量。
Maven 发布流程（release plugin）
用 maven-release-plugin 完成版本切换、打标签与发布：prepare 改版本提交，perform 检出标签构建并部署到发布仓库。
Bazel 远程缓存与远程执行
把动作结果缓存到共享后端（--remote_cache），团队与 CI 复用构建结果；大规模场景可接远程执行分摊负载。
环境与配置管理60 条
多环境、配置注入与密钥管理
12-Factor 的配置原则
配置与代码严格分离：环境相关的一切（连接串、凭据、外部地址）都从环境注入，代码在任意环境按同一方式运行。
环境变量配置方式
以环境变量传递配置：语言无关、容器友好、平台原生支持；注意命名规范、类型转换与长度限制等边界。
Kubernetes Secret 的边界
Secret 默认只是 base64 编码，不等同加密：需要开启 etcd 静态加密（KMS）、收紧 RBAC，并控制挂载与读取范围。
Kubernetes ConfigMap
存放非敏感配置的对象：可整体挂载为文件、按键注入环境变量；更新后注意生效方式（卷内最终一致、环境变量需重启）。
CI 与云的 OIDC 联邦（免长期密钥）
CI 平台签发带身份的短时令牌，云侧按信任策略换取临时凭据：仓库里不再存放云 Access Key。
发布中的数据库迁移
应用发布与库结构变更分开管理：迁移脚本版本化可重放，上线顺序与兼容窗口设计清楚，避免「代码与表结构互相等」。
特性开关作为配置（Feature Flags）
用开关把「部署」与「发布」解耦：代码先上、功能默认关，按人群或比例开启；开关本身要纳管与清理。
Terraform 基础流程与锁定
基础设施即代码的常用工具：init/plan/apply 三段式，provider 版本锁定（lock 文件），变更先看 plan 再执行。
配置文件与环境变量的取舍
少量标量开关走环境变量，复杂结构化配置走挂载文件；密钥单独用密钥管理方案处理，不与普通配置混放。
CI 凭据最小权限
流水线令牌按作业需要发放：默认只读、写权限逐项声明、发布凭据只在发布作业可见，降低单点被利用的波及面。
扩展-收缩迁移（Expand/Contract）
把破坏性结构变更拆成安全序列：加新结构 → 双写/回填 → 切换读 → 移除旧结构，每一步都可独立回滚。
预发环境（Staging）的定位
发布前最后一道真实环境验证：与生产同源的基础设施模板与配置、脱敏或合成数据，验证集成、迁移与性能抽检。
HashiCorp Vault 要点
集中式密钥管理：动态凭据、租约回收、审计日志与加密即服务；部署与运维复杂度较高，需明确职责边界。
提交与历史中的密钥扫描
对仓库内容与历史做密钥检测：平台内置扫描（GitHub secret scanning / GitLab secret detection）叠加预提交钩子，发现即轮换。
凭据轮换（Rotation）
按周期与事件双轨轮换：常规按计划，泄露/人员变动即刻执行；轮换方案要支持双凭据并存切换，避免停机。
受保护变量与环境保护
把高权限凭据限定在受信场景可用：GitLab 受保护变量只在保护分支/标签管道可用；GitHub 用 environment secrets 加审批。
GitHub Environments 与保护规则
为部署目标建模环境：配置必需审批人、等待计时器与允许部署的分支，密钥与变量挂在环境上按需可见。
向后兼容变更
接口演进遵守兼容规则：只增字段、不删不改语义；客户端按「兼容近 N 个版本」设计，升级与服务解耦。
Terraform 状态管理
状态文件记录资源映射：必须放远程后端（带锁与版本化），视为敏感数据（可能含明文属性），做好加密与访问控制。
SOPS 加密配置文件
对 YAML/JSON/ENV 等结构化文件做字段级加密：值加密、结构与键可见，diff 友好，适配配置入库与 GitOps。
变量掩码（Masked Variables）
把敏感变量在日志中替换为掩码：它是兜底而不是保密手段，注意掩码条件的限制与变形输出绕过。
发布审批门设计
审批要让人「看得懂、判得动」：附变更摘要与验证结果，允许在流水线内直接审批或跳转评审；避免流于盖章。
生产环境访问控制
生产访问按角色最小化：SSO 统一身份、区分只读与变更权限、临时授权到期回收，动作全程审计。
配置版本化与审计
配置进版本库、走评审、可回滚：配合 GitOps 时，集群状态与仓库声明有明确的同步关系与责任人。
Helm values 分环境
同一 chart 用多份 values 描述环境差异：命令行上的多个 --values 按顺序覆盖（后者优先），--set 仅用于少量临时覆盖。
Sealed Secrets（集群内解密）
用集群控制器公钥加密（SealedSecret 资源），密文可安全入库；控制器用私钥解密为普通 Secret，适合 GitOps 流程。
External Secrets Operator
把外部密钥库（Vault/AWS/GCP/Azure 等）中的密钥同步为 K8s Secret：集中管理、按需下发，避免密钥散落集群。
变量按环境作用域
同名变量按环境取值：同一作业定义在 dev/staging/prod 指向不同配置，避免为每个环境复制作业。
GitLab Environments 与部署审批
环境对象记录每次部署（谁、什么版本、何时）：受保护环境限制可部署角色，部署作业可配手动手动门与变更记录。
Kustomize 环境叠加
base 描述通用资源、overlays 按环境打补丁：同一份声明派生多环境差异，diff 清晰可评审。
环境一致性（Dev/Prod Parity）
让开发、测试、生产尽量同构：同一容器、同一依赖版本、同类中间件，减少「只在我的环境发生」类问题。
命名空间与隔离
用命名空间（或云账号/项目）隔离环境与团队：权限、配额、网络策略按边界收口，降低误操作与横向影响。
策略即代码（Policy as Code）
把组织规则写成可测试、可版本化的策略：镜像来源、资源上限、必填标签、禁止特权容器——自动在流水线与准入层执行。
构建与环境配置分离
制品不携带环境配置：同一镜像部署到所有环境，环境差异在运行时注入；构建期需要凭据时用挂载而非固化。
动态密钥（Dynamic Secrets）
按需为每个应用实例生成短期凭据（数据库账号、云 STS 等）：用完即回收，泄露窗口从「永久」压缩到「TTL 内」。
配置漂移（Drift）
实际运行状态与声明配置不一致：手工热修、临时扩容、紧急改配置都会产生漂移，需要检测与收敛机制。
CI 中的 terraform plan 门禁
把 plan 作为变更评审的核心证据：-detailed-exitcode 区分「无变化/有变化/错误」，有变化时评审计划再执行。
环境独立凭据
每个环境一套独立凭据：测试凭据无法访问生产数据与服务，边界之外的操作默认失败。
连接串管理
数据库/中间件连接信息的标准表达（URL 形式）：主机、端口、库、参数与凭据的组合，注意转义与注入方式。
配置校验（Schema Validation）
在加载与流水线阶段校验配置结构与取值：必填项、类型、范围、互斥条件——让配置错误在启动时暴露。
日志脱敏
让日志可用于排障但不出卖凭据：结构化字段过滤、正则脱敏、敏感键名单，前后端与网关统一处理。
gitleaks 用法
开源密钥扫描工具：支持全历史检测、规则可扩展、输出脱敏；常用于 CI 流水线与本地 pre-commit。
工作负载身份联合（Workload Identity）
云侧用联邦把外部身份（K8s ServiceAccount、CI OIDC 等）映射为可扮演角色：静态密钥进一步退场。
.env 文件的使用边界
.env 适合本地开发便利：不放版本库、不同步生产；提交模板（.env.example），生产环境由平台注入。
OPA Gatekeeper
Kubernetes 准入控制侧的 OPA 集成：ConstraintTemplate 定义规则模板，Constraint 声明适用范围与动作（deny/dryrun）。
配置备份
配置的恢复能力：IaC 仓库、集群 etcd、平台设置各自有备份手段，并且要演练恢复而非只备份。
缓存与制品中的凭据泄漏
构建缓存、镜像层、制品归档都可能夹带凭据：用短时凭据与 secret 挂载替代「写进构建环境」，并定期扫描制品。
初始密钥问题（Secret Zero）
「保护密钥的密钥从哪来」：自举信任要从外部锚点获得——云 KMS、硬件令牌、CI 的平台身份，避免无限套娃。
Helmfile 管理多环境多 release
用声明式文件组织「多个 release × 多个环境」：helmfile diff 预览、apply 收敛，环境矩阵集中可读。
临时环境（Ephemeral Environment）
按需创建、用完销毁的环境：为集成测试、演示与评审提供隔离空间，创建与销毁都应自动化。
清单校验工具（kubeconform / kubeval）
对 Kubernetes YAML 做离线 schema 校验：在 CI 里拦住字段拼写、类型与版本不兼容问题，避免「提交后才发现」。
imagePullSecrets 与私有仓库拉取
私有镜像拉取凭据：把 docker-registry 类型 Secret 挂到工作负载或 ServiceAccount 上，跨命名空间需显式复制。
配置相关的测试
为「配置正确性」建立测试：渲染校验、启动自检、生产同构的集成冒烟，把配置错误挡在发布前。
age 文件加密
现代文件加密工具：命令行简洁、密钥短、无配置负担，常作为 SOPS 或脚本化加密场景的默认选择。
环境清单（Inventory）
维护环境台账：名称、用途、负责人、入口 URL、依赖系统、发布与回滚方式——故障与交接时的参照地图。
Kyverno 策略引擎
Kubernetes 原生策略工具：策略用 YAML 表达，支持校验（validate）、变更（mutate）、生成（generate）与清理，输出策略报告。
ServiceAccount 令牌管理
应用访问 K8s API 的身份：优先使用投射令牌（绑定 audience 与过期时间），避免长期有效的静态令牌。
漂移检测工具组合
组合三种视角做漂移巡检：IaC 视角（refresh）、集群/GitOps 视角（diff）、云厂商合规视角（配置审计服务）。
TruffleHog 概览
密钥扫描与验证工具：支持对发现结果做活跃性验证（verify），降噪后更接近「真凭据泄露」的处置队列。
git-crypt 透明加解密
按 .gitattributes 规则让指定文件在提交时自动加密：本地检出可透明使用，适合中小团队的敏感配置仓。
发布策略60 条
蓝绿、金丝雀、滚动与灰度发布
K8s 滚动更新（RollingUpdate）热门
Kubernetes Deployment 的默认发布策略：控制器新建 ReplicaSet 逐步扩容新版本 Pod、缩容旧版本 Pod，过程中两版本共存，发布节奏由 maxSurge 与 maxUnavailable 控制。
金丝雀发布（Canary Release）热门
先把少量流量导入新版本，对错误率、延迟与业务指标做对照观测，逐步放大比例；异常时把流量切回旧版本，把影响面限制在子集用户内。
蓝绿发布（Blue-Green）
维护两套同构环境，新版本在非生产槽位验证通过后将流量整体切过来；出问题切回旧槽位即完成回滚，代价是双倍资源与数据库兼容约束。
就绪探针与发布门禁
Readiness 探针决定 Pod 是否加入 Service 后端；滚动更新只有在新 Pod 就绪后才继续，因此探针配置直接决定发布期的流量安全与更新能否推进。
maxSurge 与 maxUnavailable 调参
两个字段决定滚动更新的并发度与可用容量下限：加大 maxSurge 更新更快但多占资源，maxUnavailable 决定更新期间可以损失多少容量。
渐进式交付（Progressive Delivery）
在持续交付之上叠加「控制暴露范围」：发布不再等价于全量上线，而是结合流量切分、功能开关与自动分析，把变更逐步、可观测地暴露给用户。
部署与发布的解耦
把「代码进入环境（deploy）」和「用户可见行为变化（release）」拆成两件事：先部署默认关闭的功能，再用开关或流量规则决定何时对谁生效。
存活探针与发布稳定性
Liveness 探针决定容器是否重启：连续失败即触发 kubelet 重启；发布期间误配会让新版本实例反复重启、更新无法收敛。
金丝雀与蓝绿的选择对比
两种渐进发布思路的取舍：金丝雀按比例逐步放量、影响面小但观测周期长；蓝绿一次性切换、回滚快但资源占用高。
发布开关（Release Toggle）的生命周期
为一次发布而设的开关：上线前打开、全量后退役；管好命名、归属与到期时间，避免开关沉积成永久分支。
应用优雅退出（SIGTERM 处理）
应用对 SIGTERM 的处理决定退出质量：停止接收新请求、处理完在途请求、释放资源后以正常状态退出；配合探针与 preStop 可降低发布期的 5xx。
原生 K8s 双 Deployment 金丝雀
不引入额外组件的最小可用方案：新旧版本各一个 Deployment、共享标签由同一 Service 承接，用副本数近似控制流量比例。
紧急修复发布流（Hotfix）
线上故障需要绕过常规节奏时：从已发布版本拉修复分支、最小改动、跑必要门禁、快速发布并回合主干；流程可以加速，但验证与记录不能取消。
kubectl rollout status 跟踪发布
观察 Deployment 收敛过程的命令：输出各副本进度，脚本可用它判断发布成功或超时，替代轮询 Pod 列表的土办法。
移动应用分阶段发布（Staged Rollout）
应用商店按用户比例逐步放量新版本：先小比例用户升级、观察崩溃率与评价，再逐步放大；异常时可暂停放量。iOS 的分阶段发布在 7 天内按天提升比例，Android 可自选各档比例并随时暂停。
preStop 钩子与摘流延迟
preStop 在容器收到终止信号前同步执行：常用于等待负载均衡完成摘流、通知对端下线、留出请求处理时间，让滚动发布中的实例平滑退出。
Helm --wait 与 --atomic 发布保险
让 Helm 等资源真正就绪再判定升级结果：--wait 等待就绪；--atomic 在失败时自动回滚到上一版本，为 CI 自动发布加一道兜底。
影子流量（Traffic Mirroring）
把生产流量复制（或按比例复制）给新版本，响应被丢弃、只用于验证：可以用真实流量压测新版本，而不影响用户结果。
发布节奏的取舍（Release Cadence）
连续发布、按需发布与固定周期发布各有适用条件：批量越大、间隔越长，单次变更的风险与定位成本越高；小批量、高频率与稳定性可以并行改善。
PodDisruptionBudget 与发布期运维
PDB 限制自愿中断时同时不可用的副本数：节点 drain、节点回收等运维动作受其约束；对 Deployment 自身滚动更新不生效，但决定运维与发布能否安全穿插。
kubectl rollout restart 滚动重启
不改镜像也触发一次滚动重启：给 Pod 模板打时间戳注解使 Deployment 生成新 ReplicaSet，用于重载配置、清理异常实例或让镜像重新拉取。
爆炸半径（Blast Radius）控制
发布设计的核心问题：一次变更最多影响多少用户与多少功能；用分批、按区域、按单元隔离把影响面压到可接受范围。
发布开关的清理
开关相关代码是最容易沉积的技术债：全量后应删除开关判断与旧分支，并把清理动作纳入发布收尾清单。
暗发布（Dark Launch）
新功能随发布部署但不暴露入口：先在生产环境里被动运行（或承接影子流量），用真实负载验证性能与稳定性，再开入口放行用户。
terminationGracePeriodSeconds 宽限期
定义 Pod 删除时从终止流程开始到 SIGKILL 的最长等待：preStop 执行与应用自行退出的总时长都要落在这段预算内。
StatefulSet 滚动更新与 partition
有状态工作负载按序号从大到小逐个更新；partition 字段只更新序号不小于该值的 Pod，用它实现有状态服务的单实例先行验证与分批放量。
Istio 权重与灰度路由
用 VirtualService 把流量按权重分给不同版本，或按 header、URI 等条件定向路由：支持逐步提权、内部用户先行与镜像流量。
冒烟验证作为发布门禁
发布后对关键路径做最小验证：登录、下单、支付等主干流程的自动化断言通过才继续放量；失败即停止并进入回退流程。
零停机发布检查清单
把无中断发布所需的配置与流程汇总成清单：探针、容量、摘流、PDB、观测与回退通道缺一不可，发布前逐项确认。
停机重建（Recreate）策略
先终止全部旧 Pod 再创建新 Pod，发布窗口内服务中断；适合无法容忍两版本并存、或独占资源（本地锁、独占许可证、单写者）的服务。
按环发布（Ring Rollout）
把用户分成由小到大的环：先内部环、再尝鲜环、最后全量环，逐环放量验证；适合客户端软件与大规模在线服务的分阶段发布。
启动探针（startupProbe）与慢启动应用
为启动耗时长的应用设计的探针：startupProbe 成功之前，存活与就绪探针不会执行；成功一次后不再运行，让慢启动实例有充足的启动预算。
Argo Rollouts 渐进式发布
Kubernetes 控制器与 CRD：用 Rollout 资源声明式描述金丝雀与蓝绿流程，支持按步骤调权重、定时暂停、自动分析，并配套 CLI 做晋级与中止。
金丝雀观测指标的选择
选择能快速区分新旧版本差异的指标：错误率、延迟分位、资源饱和与关键业务指标；与基线版本同窗口对照，而不是只看新版本绝对值。
蓝绿与数据库兼容
蓝绿切换期间两套应用共享同一数据库：结构与行为必须同时满足新旧代码；破坏性变更要等旧版本完全退役后再执行。
A/B 测试与发布的区别
A/B 测试是产品实验：两个变体并行服务不同用户群，用统计方法判断哪个更优；金丝雀是风险控制：判断新版本是否可安全放量。二者可共用流量切分能力，但目标与决策规则不同。
发布冻结窗口（Change Freeze）
在业务高峰、促销与节假日等时段冻结高风险生产变更，避免故障出现时人力与恢复条件不足；冻结需要定义范围、豁免通道与退出条件，而不是停止所有工作。
NGINX Ingress 金丝雀注解
Ingress-NGINX 用注解实现金丝雀：给金丝雀 Ingress 设置 canary 标记与权重，按比例或 header/cookie 把请求分流到新版本服务。
金丝雀自动分析（Automated Analysis）
把放量判断自动化：定义指标查询与阈值，按间隔对比金丝雀与基线的错误率、延迟等；达标自动提权，超限自动中止并回滚。
放量阶梯与停留时长设定
放量梯度要按流量与指标收敛速度设计：低流量服务放大首档比例，高流量服务可把首档降到 0.1%；每档停留以「样本量足够」为原则。
固件/系统 OTA 灰度发布
固件与系统更新按设备人群分批推送：借助 A/B 双分区保证失败可回退，先小批量验证升级成功率与稳定性，再逐批扩大；异常时暂停批次并保留回退通道。
节点排空（drain）与发布穿插
节点维护前 cordon 停止调度、drain 驱逐 Pod；驱逐受 PDB 约束，DaemonSet 与使用本地存储的 Pod 需要单独处理，避免数据与可用性事故。
Helm Hooks（发布前后钩子）
在发布生命周期的关键节点执行一次性任务：升级前跑数据库迁移 Job、升级后发通知、测试钩子做验收；钩子用注解与权重控制执行顺序。
发布观察期（Bake Time）
每档放量后停留一段时间再继续：让指标积累到可判断的样本量，也覆盖缓存过期、定时任务、业务周期等慢变量；停留过短等于没有观测。
Flagger 自动金丝雀
以 Operator 方式执行自动金丝雀：接管工作负载后生成稳定版与金丝雀两套后端，按指标自动判定晋级或回滚，也可以按需暂停。
Gateway API 权重分流（HTTPRoute）
新一代网关 API：HTTPRoute 的 backendRefs 支持为多个后端设置权重，逐级调整权重即可实现灰度与蓝绿切换，配置比注解式更结构化。
不可变基础设施与发布
服务器不原地打补丁，而是整体替换：镜像或虚机模板作为制品构建与版本化；发布=替换实例，回滚=用上一版制品重新拉起。
负载均衡摘流延迟与发布
实例终止时流量系统的感知存在延迟：端点移除传播、负载均衡刷新、健康检查周期都要时间；发布缓冲按这些环节实测估算。
变更日历与协调
把重要的生产变更登记到共享日历：时间窗、负责人、影响系统、回退方式；减少多个团队同时改动同一系统的冲突，让值班与依赖方提前知情。
kubectl rollout pause / resume 合并变更
暂停 Deployment 滚动：pause 之后连续修改镜像、配额、标签等字段不会立即触发滚动，resume 时以最终模板一次收敛，减少无谓的滚动次数。
DaemonSet 滚动更新
节点级守护进程（日志采集、监控 agent、网络插件）的更新：按 maxUnavailable 控制每次停掉多少节点的实例，逐节点替换。
多集群分批发布
服务部署在多个集群时按集群为单位滚动推进：先验证集群、再少量生产集群、最后全量，每批之间验证并停留。
按 header / cookie 的定向灰度
权重之外的精确分流：用 header、cookie 把内部人员与尝鲜用户先导到新版本，再叠加权重放量给普通用户。
分区域渐进发布
面向多区域服务：先小区域、再大区域，观察区域级指标与依赖状态后扩大；区域是天然的分批与隔离单元。
单实例先行（One-Box Canary）
发布先从单个实例开始：在真实流量下观察错误率、日志与资源占用，再扩大到全部实例；有状态服务可用 StatefulSet partition 实现。
HPA 与发布期的容量配合
自动扩缩容与发布同时进行时避免相互干扰：按副本数近似的金丝雀比例会随伸缩漂移，资源竞争也可能拖慢新 Pod 就绪。
CRD 升级与存储版本迁移
CRD 是集群级扩展资源：升级要处理多版本并存与存储版本切换，顺序是先提供新版本、迁移使用者、再切存储版本、最后移除旧版本。
单元化发布（Cell Rollout）
把系统划分为独立运行单元：每个单元承载固定用户分片并具备完整服务能力；发布以单元为粒度推进，单元故障不扩散到其他单元。
DNS 权重切换与发布
用带权重的 DNS 记录在环境或区域间渐进切换流量：适合粗粒度切换与区域级蓝绿，生效速度受客户端与解析器缓存影响。
镜像烘焙（Golden Image）与发布
预先把操作系统、运行时与依赖烘焙成镜像，发布时只替换镜像：启动更快、行为更稳定；烘焙产物按版本与校验和登记引用。
工具链要点63 条
GitLab CI、GitHub Actions、Jenkins
GitLab CI 的 .gitlab-ci.yml 结构
GitLab 流水线配置文件：声明 stages 与作业（job），每个作业指定 stage、script 与运行条件；作业名即流水线中的显示名。
GitHub Actions 工作流结构
工作流文件位于 .github/workflows：name、on、jobs 为核心结构；每个作业在自己的 runner 上顺序执行一组步骤。
GitLab CI 的 rules
替代 only/except 的条件执行机制：按 if、changes、exists 从上到下逐条匹配、命中即采用，决定作业是否运行以及以何种方式运行。
GitLab CI 的 artifacts
作业产物：把文件在阶段间传递并留存供下载；可配置过期时间与上传时机，是构建制品在流水线内传递的标准方式。
GitHub Actions 触发事件
常用触发：push、pull_request、workflow_dispatch（手动）、schedule（定时）、release；均可附加分支、路径与类型过滤。
GitLab CI 的 needs（DAG）
让作业不等整个阶段完成：needs 直接声明依赖的作业，形成有向无环图，下游作业在上游就绪后立即开始。
GitLab CI 的 cache key 与策略
缓存按 key 隔离：用 lockfile 哈希做 key 让依赖变更即换缓存；前缀按分支隔离，避免不同分支互相污染。
Jenkins 声明式流水线（Jenkinsfile）
以 Jenkinsfile 定义流水线：pipeline 块包含 agent、stages、post；配置随代码评审与版本管理，替代界面里的手工配置。
GitLab CI 的 include 与 extends 复用
include 引入外部 YAML（本地文件、远程 URL、官方模板），extends 做配置继承：隐藏作业（. 开头）常作为被继承模板。
GitHub Actions matrix 矩阵
一次定义多环境组合：strategy.matrix 展开为多个并行作业，支持 include 追加组合、exclude 排除组合与 fail-fast 控制。
GitLab CI workflow 规则
在作业规则之外控制「整条流水线是否创建」：用 workflow:rules 避免分支推送与 MR 事件各触发一条流水线的重复问题。
GitLab CI 内构建镜像（DinD）
在流水线里构建容器镜像：docker:dind 服务方式需要特权与 TLS 配置；也可选择 rootless 或免守护进程的构建工具。
GitHub Actions secrets 与 vars
仓库/组织/环境三级配置：secrets 存敏感值（日志掩码），vars 存普通配置；作业容器经上下文引用，环境级在对应环境生效。
GitLab CI 的 services（旁路服务）
为作业启动伴随容器（数据库、缓存、模拟服务），测试作业可以连接真实的 MySQL/PostgreSQL 实例，而不是全部依赖桩件。
GitLab Runner 标签与调度
作业通过 tags 选择 Runner：只有标签匹配的 Runner 才能接单；共享、群组、项目 Runner 与不同 executor（docker、shell、kubernetes）决定隔离与伸缩能力。
GitHub Actions 缓存
用 actions/cache 缓存依赖目录：key 常用锁文件哈希，restore-keys 提供前缀回退；缓存按仓库额度管理与淘汰。
GitLab CI 测试报告与覆盖率
把测试结果与覆盖率以报告形式接入 GitLab：MR 页面直接显示失败用例与覆盖率变化，减少翻日志定位。
GitLab CI 的 environment 与部署跟踪
声明作业对应的部署环境：GitLab 记录每次部署的版本与时间，支持环境级停止（on_stop）、回滚查看与受保护环境审批。
GitHub Actions needs 作业依赖
声明作业之间的依赖：上游失败默认阻断下游；用 if: always() / failure() 调整分支逻辑，同时 needs 是读取上游 outputs 的入口。
GitHub Actions 权限声明
为工作流显式声明最小权限：permissions 可全局或按作业设置；OIDC 等能力需要单独开启（如 id-token: write）。
GitHub Actions OIDC 免密上云
用工作流身份换取云上短期凭据：id-token: write 打开 OIDC，云侧信任策略按仓库、分支等声明校验，替代长期静态密钥。
GitLab CI / GitHub Actions / Jenkins 对比
三种主流方案的定位差异：平台一体化、动作生态与完全自建；选型取决于托管形态、网络边界与团队既有经验。
GitLab CI 变量优先级
同名变量按层级覆盖：触发/手动运行传入的流水线变量优先级高于项目、群组与实例级定义，作业内定义优先级较低；排查时以运行时实际值为准。
GitLab 受保护分支与保护变量
受保护分支/标签限制推送与合并权限；标记为 protected 的变量只在受保护上下文（如受保护分支流水线）可用，用于把发布凭据留给受控流程。
GitHub Actions concurrency 并发控制
用 concurrency 给运行分组：同组内限制并发，可配置新运行取消进行中的旧运行；部署场景建议保留串行而非自动取消。
GitHub Actions 制品上传与下载
用 upload-artifact 保存作业产物、download-artifact 在其他作业取用；v4 起同一工作流内制品名不可重复，制品有保留期。
Jenkins agent 与节点调度
指定流水线或阶段运行在哪个节点：agent any / label / docker / kubernetes；agent none 时每个 stage 需要自带 agent。
Argo CD 与 GitOps 持续部署
把集群期望状态放进 Git：Argo CD 持续对比并同步，自动纠偏；发布等价于合并 Git 变更，回滚等价于回到上一个提交。
GitLab CI parallel:matrix 矩阵
一次定义多组作业：维度变量的组合自动展开，适合跨版本、跨数据库的兼容性测试。
GitHub Actions 环境保护规则
为部署作业绑定环境：可配置必需评审人、等待计时与分支限制，环境级 secrets 只对对应环境的作业可用。
Jenkins post 后置处理
流水线或阶段结束后的收尾逻辑：always、success、failure、unstable、changed、cleanup 分条件执行，用于归档、通知与清理。
Jenkins 凭据管理
集中管理凭据：用户名密码、SSH 私钥、Secret 文本与文件；流水线通过 credentials() 或 withCredentials 绑定使用。
GitLab CI retry 与 timeout
对特定失败原因自动重试，并给作业设置超时上限：重试用于基础设施抖动，超时防止挂起作业长期占用资源。
GitHub Actions 可复用工作流
把整条工作流定义为可调用单元：workflow_call 声明输入、密钥与输出，其他工作流以 uses 引用；适合组织级流程标准化。
GitHub Actions 表达式与状态函数
在 ${{ }} 中做条件与取值：success()/failure()/always()/cancelled() 控制运行与否，fromJSON、hashFiles 等函数做数据变换。
GitHub Actions 手动触发
为工作流提供手动运行入口：声明输入参数（字符串、布尔、选项、环境），通过界面、API 或 CLI 触发，适合补跑与受控发布。
Jenkins when 条件执行
按分支、变更请求、环境或表达式决定阶段是否执行；配合 beforeAgent / beforeInput 控制条件求值时机，减少无谓节点占用。
Jenkins 共享库
把可复用流水线逻辑集中到独立仓库：vars/ 定义全局步骤、src/ 存放类；流水线以 @Library 引用，建议固定版本。
GitLab CI 子流水线（Child Pipelines）
父流水线触发子流水线：适合按目录拆分的大型仓库与动态生成的流水线配置；用 strategy: depend 让父级等待子级结果。
GitLab 流水线计划（Schedules）
定时触发流水线：按 cron 配置周期并附带计划变量，常用于夜间构建、定时部署与巡检任务。
GitHub Actions 自托管运行器
在内网或自有硬件上执行作业：注册 runner 后按标签调度，适合需要私网访问、特定硬件或大缓存的任务。
GitHub Actions 服务容器
为作业启动伴随服务：数据库、缓存等以 service 容器运行，配合健康检查等待就绪；访问地址按作业是否容器化而不同。
GitHub Actions 路径过滤与必需检查
push/pull_request 可按 paths 过滤触发范围节省算力；但与分支保护的必需状态检查叠加时，未触发的工作流会阻塞合并。
Jenkins parallel 并行阶段
并行执行多个阶段：缩短流水线时长；failFast 控制一个分支失败时是否取消其他分支。
Jenkins options 构建选项
流水线级统一配置：超时、禁用并发、保留构建数、时间戳等；把行为约束写进代码而不是靠约定。
Jenkins input 人工审批
在流水线中途请求人工确认或收集输入：可限定提交者、设置确认文案与参数；必须配合超时避免无限等待。
约定式提交（Conventional Commits）
提交信息采用「类型(范围): 描述」格式：机器可解析，可据此生成变更日志与推断版本号，支撑自动化发布。
GitLab CI interruptible 与自动取消
标记作业可被更新的流水线取代：分支出现新提交时，旧流水线中的可中断作业自动取消，节省算力并减少过时结果干扰。
GitHub Actions 定时工作流
on.schedule 用 cron 定时触发：时间为 UTC；仓库长期无活动时定时工作流会被自动停用，需要留意。
GitHub Actions 作业输出传递
作业之间通过 outputs 传值：步骤将值写入 GITHUB_OUTPUT 文件，作业级 outputs 引用步骤输出，下游用 needs 读取。
Jenkins matrix 矩阵构建
按轴组合生成多个执行单元：axes 定义维度、excludes 排除组合，单元格可带独立的条件与后置处理。
Jenkins environment 与 withEnv
在流水线或阶段声明环境变量：environment 块集中定义，withEnv 在块内临时覆盖；常与凭据绑定配合使用。
Jenkins 多分支流水线
对仓库分支与变更请求自动发现并建流水线：每个分支独立构建，配合 Jenkinsfile 实现分支级持续验证。
Jenkins 触发方式：webhook 与轮询
代码推送触发的两条路径：SCM 侧 webhook 即时通知，或 Jenkins 定时轮询兜底；内网 Jenkins 接 webhook 需要可达路径。
Jenkins 参数化构建
为流水线定义构建参数：字符串、布尔、选项、密码等；参数通过 params 访问，把可变输入从脚本里移出来。
Jenkins 容器化 agent
动态提供构建环境：docker agent 在容器中执行步骤，kubernetes agent 按 Pod 模板在集群里拉起，随用随销。
pre-commit 提交前钩子
统一管理 Git 钩子：格式化、lint、密钥扫描等在提交前自动执行；同一配置在 CI 复跑，防止本地绕过。
GitLab Pages 静态发布
用 pages 作业发布静态站点：产物放到约定目录后由 Pages 服务托管，适合文档站、演示站点与前端预览。
GitLab CI default 全局配置
用 default 集中声明 image、before_script、cache、tags 等公共项：减少重复声明，但一次变更会影响所有作业。
GitHub Actions 复合动作
把多个步骤打包成动作：action.yml 中 runs.using: composite 内联步骤，供同一作业或其他仓库复用。
GitHub Actions 作业容器
让作业在指定容器中运行：jobs.<id>.container 指定镜像与参数，工具链版本随镜像固定，与宿主环境解耦。
托管运行器与自托管运行器
构建执行的两种供给方式：托管开箱即用，自托管在网络与硬件上更可控；混合使用是常见形态。
流水线配置静态检查
提交前校验流水线文件：GitLab CI Lint、actionlint、Jenkins 语法检查；把语法问题拦在推送之前。
质量门禁与回滚51 条
门禁指标、回滚预案与发布复盘
质量门禁基础：让流水线替团队把关
在流水线的关键节点设置必须通过的检查（测试、扫描、依赖与评审），未通过就中止后续阶段，把问题拦在发布之前。
DORA 四项交付指标
DORA/Accelerate 研究提出的四个交付效能指标，分速度与稳定性两组：部署频率、变更前置时间、变更失败率、恢复时长；看趋势与短板而非单点数字。
测试通过门禁与失败策略
测试阶段作为发布前置条件：单元与集成测试通过才进入构建与部署；对已知的辅助类作业单独标记允许失败，避免掩盖真实回归。
kubectl rollout undo 回滚 Deployment
Kubernetes 内置回滚：把 Deployment 回退到上一修订版或指定版本；前提是修订历史仍在且目标镜像标签仍可拉取。
覆盖率阈值门禁
为行覆盖、分支覆盖率设置通过线并接入流水线；阈值应基于当前基线渐进提高，关注增量与关键路径，而不是单看一个数字。
SonarQube Quality Gate 质量门禁
SonarQube 的通行条件组合：对新增代码的覆盖率、重复率与问题评级设阈值，全部满足才判定通过，可在 CI 中查询结果决定是否继续。
回滚与前滚修复（Rollback vs Fix Forward）
发布后出问题时有两条路径：回滚到上一版本恢复服务，或前滚发布修复版本；选择依据是恢复速度、数据兼容性与根因清晰度。
阻断门禁与告警的取舍
区分必须通过与先提示两类检查：正确性、安全强相关的设为阻断；风格类与探索期度量先告警观察，再逐步收紧。
密钥扫描门禁
在提交与流水线两个层面扫描疑似密钥：命中即阻断并通知；常用工具包括 gitleaks、TruffleHog、GitLab Secret Detection 等。
错误预算（Error Budget）
以 SLO 为基准计算的允许失败额度：1 减去 SLO 即为预算比例；例如 99.9% 可用性在 30 天里约允许 43 分钟不可用。
helm rollback 版本回退
Helm 按 release 修订号回滚到历史版本：回滚本身生成新修订，可再次回滚；先用 helm history 确认目标修订与状态。
数据库变更的回滚策略
数据库没有一键回滚：策略以向前兼容为目标，先扩展后收缩、变更与应用发布解耦，并准备回退脚本、确认备份可用。
不稳定测试（Flaky Tests）治理
同一代码重复运行结果不一致的测试即 flaky：会侵蚀门禁公信力。治理路径是识别、隔离、修复三步，并用 flaky 率观察趋势。
git revert 回退问题提交
以新增提交抵消问题变更，历史保留可审计，适合已推送的共享分支；合并提交与提交区间也可回退，但需注意合并回退的后续影响。
事故复盘（Postmortem）
事故恢复后系统还原时间线、根因与改进项；无指责复盘聚焦系统与流程改进而非追责个人，鼓励如实披露以避免隐瞒。
静态分析门禁（Lint 与类型检查）
用 Lint、类型检查与复杂度工具在合并前拦截低级问题；重点是控制信噪比：先清理误报与规则集，再让检查结果成为阻断条件。
必需状态检查（Status Checks）
把 CI 作业设为分支保护的必需检查：全部通过才允许合并；注意作业命名与路径过滤，避免出现永远处于等待状态的检查项。
部署频率（Deployment Frequency）
单位时间内成功发布到生产的次数，反映交付吞吐；统计要点是先定义清一次部署与生产的边界，并按需单列回滚事件。
增量代码覆盖率（New Code）
只对本次变更新增或修改的代码统计覆盖率并设门槛，让历史包袱不再压制新提交的要求；SonarQube 的 New Code 与 diff-cover 都支持该思路。
CODEOWNERS 定义评审归属
在仓库中声明路径与负责团队：相关文件变更自动请求对应评审人，配合分支保护可实现未获指定团队批准不得合并。
变更前置时间（Lead Time for Changes）
从代码提交到在生产运行所经历的时间，衡量需求流动速度；瓶颈通常在评审等待与手工发布环节，用分段数据定位更可靠。
恢复时长（MTTR / Time to Restore）
服务中断到恢复所需的平均时间，衡量系统恢复能力；DORA 口径强调从故障开始到修复完成，包含为修复而进行的发布。
回滚预案（Rollback Playbook）
把回滚写成可执行的步骤文档：触发条件、决策人、命令与验证、沟通模板；事故现场照单执行，避免临场摸索。
SAST 与 DAST 安全扫描门禁
SAST 在源码层面发现缺陷模式，DAST 在运行环境模拟外部访问行为；两者发现的问题按严重级与可利用性分级，高危项进入阻断集合。
必需评审（Required Review）
分支保护要求合并前获得指定数量的评审批准，并可在新提交后自动作废旧批准；目标是让变更在合入前经过独立评审。
变更失败率（Change Failure Rate）
生产事故中与变更相关、需要修复行动（热修复、回滚、补丁）的比例；统计关键是失败判定标准，通常以是否需要紧急修复发布为准。
金丝雀中止（Canary Abort）
金丝雀阶段指标越界时停止放量并回滚：自动化或人工判定都要定义明确阈值、观察窗口与执行人，并记录触发时的样本。
发布完成定义（Definition of Done）
为一次发布预先写清什么算完成：产物可追溯、验证通过、指标与通知到位；把口头约定变成检查清单，减少发布后的争议与遗漏。
以 SLO 为发布门禁（渐进发布观察）
把 SLO 指标接入发布过程：灰度阶段发现错误率或延迟超出预算消耗速度时自动暂停推进，让可靠性数据直接参与发布决策。
蓝绿环境回切（Switch Back）
蓝绿发布出问题时的回切：把流量切回旧环境；回切速度取决于旧环境的保持时间、健康状态与数据兼容性。
依赖变更评审门禁（Dependency Review）
对 PR 中新增或升级的依赖做专项检查：已知漏洞、许可证变化与降级风险；GitHub 的 dependency-review-action 可在 PR 上直接阻断高危引入。
错误预算策略（发布冻结与解冻）
预先约定预算消耗与发布行为的联动规则：预算充足按计划发布，消耗过快则收紧变更并优先可靠性工作；策略要可执行且有例外通道。
终止开关（Kill Switch）
预先埋设的快速关停通道：通过开关或配置让异常路径或整体功能立即停用，不依赖重新发布；与回滚互补，适合快速止血场景。
开源许可证合规检查
扫描依赖许可证类型，识别 GPL、AGPL 等与分发方式相关的条款；在构建阶段生成清单，对策略外许可证阻断或转人工评审。
燃烧率告警（Burn Rate Alerting）
按错误预算消耗速度而非瞬时值告警：快燃烧触发紧急响应，慢燃烧用于工单跟进；Google SRE Workbook 给出了多窗口配置模式。
Argo CD 回滚与历史同步
GitOps 下有两种回退方式：在 Argo CD 历史快照上回滚，或回退 Git 提交让应用重新同步；团队需约定单一入口，避免双轨。
事故分级（Severity Levels）
按影响范围与业务后果定义等级，并映射响应动作：通知对象、响应时限、是否拉起指挥、是否对外公告；标准要预先写好并演练。
合前检查与合后检查的分工
合前做快速、确定性高的检查（Lint、单测、依赖评审）；合后做耗时与依赖部署环境的检查（端到端、性能、DAST），结果回流到发布决策。
平均检测时间（MTTD）
从故障发生到被检测告警的平均时长；缩短 MTTD 依赖覆盖关键路径的监控与合成探测，是改善 MTTR 的前置环节。
迁移 down 脚本与其边界
为结构变更编写回退脚本（如 Liquibase rollback、Rails db:rollback、Flyway 的 undo 能力），同时明确边界：已删除的数据无法靠结构回退恢复。
发布窗口的事故响应
发布期间的事故响应要点：尽早确认与变更的关联、优先止血（回滚或开关）、冻结后续发布、保持单一指挥与固定同步频率。
门禁豁免与紧急通道（Break-glass）
为紧急发布保留受控绕过路径：申请、审批、限时，事后补齐手续并复盘；豁免必须留痕，否则门禁会被逐步架空。
回滚演练（Rollback Drill）
定期在类生产或生产环境执行一次回滚，验证版本可退、数据兼容、权限具备、观测正常；把能不能回从假设变成事实。
发布观察期（Release Watch）
发布后的集中观察窗口：指定观察人、盯关键 SLI 与业务指标、设定观察时长与退出条件；把发布完成定义到观察期结束。
变更审计链（Audit Trail）
完整记录谁在何时把什么版本发布到哪个环境、依据哪次审批：由流水线、制品库与发布系统自动留痕，支撑合规与事故回溯。
故障演练日（Game Day）
有组织地向系统注入故障（依赖中断、实例淘汰、慢查询等），验证检测、响应与回滚链路；在可控时间窗内发现真实的薄弱点。
回滚成本与代价评估
回滚不是免费选项：涉及停机时长、数据损失风险、客户影响与协调成本；发布前维护不可回滚项清单，为可能的回退做准备。
回滚率指标与其解读
回滚次数占总部署的比例，反映发布质量与制品可信度；与变更失败率配合观察，可按服务、团队与发布通道细分。
部署标记（Deploy Marker）
把每次部署的时间点与版本写入监控或日志系统：图表上叠加发布事件，便于把指标变化与变更关联，也是变更审计的组成部分。
发布复盘（Release Retrospective）
对单次发布或一段发布节奏的定期回看：交付周期、失败与回滚、协作顺畅度与改进项；与事故复盘互补，覆盖没出事但别扭的改进点。
告警静默与发布期降噪
发布或维护窗口内临时静默相关告警以减少噪声；使用时要限定范围与时长，并给关键告警保留兜底核对路径。