CI/CD 流水线你会怎么搭？

我的流水线设计：代码阶段——git push 触发单测与代码扫描，五分钟内反馈；构建阶段——镜像化构建，制品带版本与 Git SHA 打 tag 推仓库；部署阶段——测试环境自动部署跑集成测试，生产环境手动审批加灰度批次（1%-10%-50%-100%）；每批观察指标再放量；回滚——制品回退一键化。工具链 Jenkins 或 GitLab CI 加 Harbor 加 Ansible。

我讲一次流水线落地：团队从脚本发布到流水线的改造。关键决策：镜像即制品——环境差异收敛到配置（ConfigMap/环境变量），避免『我这好的』；数据库变更纳入流水线——migration 脚本版本化随发布执行且必须可回滚；灰度自动化——发布到 10% 后自动跑核心接口拨测，指标异常自动暂停并通知。上线后发布事故率明显下降，回滚时间从 15 分钟到 2 分钟。

资深视角：CI/CD 的本质是变更风险管理。三个进阶认知：一，流水线的可信度是生命——不稳定的用例与虚假的绿灯比没有流水线更危险，flake 用例要隔离治理，绿灯要有意义；二，部署与发布解耦——先部署不引流量（feature flag 控制发布），部署风险与产品风险分开管理，灰度从运维动作变成产品能力；三，安全左移——依赖扫描、镜像扫描、密钥检测嵌进流水线，凭证管理脱离代码库。度量：部署频率、变更前置时间、变更失败率、MTTR——四个指标讲故事。

追问『数据库变更怎么保证安全』：migration 版本化、大表变更用在线工具（gh-ost）、回滚脚本与正向脚本同评审；『多环境配置怎么管』：配置中心或环境隔离的 values 文件，密钥走 vault 绝不进 Git；『回滚会不会丢数据』：区分无状态回滚（代码回退即可）与有状态（先回滚代码，数据由兼容设计保证——扩列容易缩列难，发布前保证 N-1 兼容）。