DevOps 实践：CI/CD 流水线入门

引言

很多团队上线依赖手工：有人打包、有人传包、有人在服务器上改配置，出了问题再靠记忆回滚。流程越长，出错概率越高。CI/CD 流水线就是把这些重复、易错的步骤变成一条可重复执行的自动化链路，让每次代码变更都经过同样的检查和发布流程。

CI 与 CD 是什么

持续集成（CI）强调频繁合并、尽早验证。代码提交后，流水线自动编译、跑单元测试和代码检查，问题立刻反馈，而不是等上线前集中暴露。持续交付（CD）把验证通过的版本变成随时可发布的状态；持续部署则在验证通过后自动发布。入门阶段先做到前两者，就能明显提升稳定性。

最小可用的流水线

一条入门流水线有五个环节：触发、构建、测试、产物管理和部署。提交代码或合并请求自动触发；构建用固定命令和环境打包，保证结果一致；测试先跑单元测试再跑冒烟测试，失败即停止；产物加上版本号保存，发布时直接使用，不再重新打包；部署先上测试环境，再灰度或分批上生产环境。

环境一致最重要

新手常踩的坑是环境不一致：本地能跑，线上却因依赖版本、环境变量或数据库配置不同而失败。办法是把配置和环境变量纳入版本管理，锁定依赖版本，部署脚本与代码同仓评审。这样差异就变成可追踪的变更，定位问题也更快。

失败先看日志

流水线失败不可怕，没有证据才可怕。好的流水线会在每个环节输出清晰日志：哪一步失败、失败命令是什么、对应哪个代码版本。排查时先看失败环节，再对比最近成功版本与本次变更，最后决定修复、调整测试或回滚。回滚也应是流水线的一部分，而不是临时手工操作。

小团队落地清单

不必一次做全，按顺序推进：先打通提交、构建和测试；再实现测试环境自动部署；然后引入版本号和产物管理；最后做生产灰度发布和自动回滚。每阶段只加一个环节，跑稳再推进。还要养成习惯：小步提交、写清说明、测试失败不绕过流水线、发布后观察一段时间。

结语

CI/CD 不是工具堆砌，而是一种交付习惯：用自动化代替记忆，用日志代替猜测，用可重复流程代替临时操作。从一条只有构建和测试的最小流水线开始，逐步补齐部署、观测和回滚，就能把时间花在业务和代码本身，而不是反复救火。