欢迎光临，我是溪源。

在上篇文章里，溪源和大家聊了 DevOps 的“道”——为什么要做、业务价值是什么。

但很多客官留言说：“道理我都懂，但具体怎么落地呢？我写完代码，怎么就到了服务器上？”

确实，DevOps 听起来很玄乎，什么 CI/CD、什么流水线、什么容器化。其实剥开那些高大上的名词，DevOps 本质上就是一个不断循环的“加工流水线”。

今天，溪源就把这个流水线拆开了、揉碎了，带大家看看代码是怎么一步步变成业务的。

01 传统的“黑盒”：代码扔进去，祈祷能出来

在聊 DevOps 之前，我们先看看传统开发模式下，一个 OA 系统的功能是怎么发布的。

假设我们要给 OA 系统加一个“加班打车报销”的功能。

传统流程是这样的：

1. 开发阶段：小王在本地写代码，用着 Windows 系统，数据库连的是自己的本机。
2. 提交阶段：代码写完了，小王把代码塞进 Git 仓库，发给测试小李。
3. 测试阶段：小李把代码拉到公司的测试服务器上。这时候问题来了——测试服务器的操作系统版本和小王的不一样，导致程序跑不起来。小王远程连上去修了半天环境。
4. 发布阶段：终于测完了，到了周五晚上发布。运维老张要把代码打包，停掉服务器，替换文件，重启服务。
5. 灾难现场：重启后发现，因为配置文件里有个 IP 地址写错了，系统崩了。老张连夜加班改配置，周一早上全公司都在骂娘。

这个过程就像个“黑盒”。
小王只管写，不管运行环境；老张只管跑，不管代码质量。代码在两个部门之间传，中间充满了“等待”、“返工”和“不确定性”。

这就是我们要用 DevOps 改造的对象。

02 第一步：持续集成（CI）—— 让代码“自我净化”

DevOps 流水线的起点，是持续集成（Continuous Integration, CI）。

它的核心逻辑是：只要代码一变，机器就自动干活。

回到 OA 系统。小王在电脑上写完了“加班打车”功能的代码，按下 Commit（提交）的那一刻，神奇的事情发生了：

2.1 触发器（Trigger）

代码提交到 Git 仓库的瞬间，CI 服务器（比如 Jenkins 或 GitLab CI）收到了信号：“嘿，有新代码了！”

2.2 自动构建（Build）

CI 服务器会自动拉取最新代码，在一个全新的、干净的容器里（比如 Docker）进行编译。

• 以前：小王说“我本地跑得好好的”。
• 现在：不管小王是用 Mac 还是 Windows，CI 服务器都是用标准的 Linux 环境编译。如果小王漏装了依赖包，编译第一步就会报错，小王立刻就能收到邮件通知。

2.3 自动化测试（Test）

这是最关键的一步。编译通过后，流水线会自动运行单元测试和接口测试。

• 系统会自动模拟一个员工提交“加班打车”申请。
• 系统会检查：金额对不对？发票格式对不对？审批流对不对？

如果测试失败，流水线立刻熔断，代码绝对不能进入下一步。

溪源比喻：
CI 就像是工厂门口的“全自动质检仪”。任何不合格的零件（代码），连车间都进不去，直接被弹回去返工。

03 第二步：制品管理 —— 打造“标准化集装箱”

代码通过 CI 测试后，还不能直接上线。我们需要把它打包成一个“制品”（Artifact）。

在 DevOps 里，我们通常使用 Docker 镜像 作为制品。

3.1 什么是制品？

想象一下，以前我们发货是散装的：有的用纸箱，有的用木箱，有的直接堆在车上。到了客户那儿，很容易散架。

现在，我们把 OA 系统的所有代码、配置文件、运行环境，全部打包进一个 Docker 镜像里。

3.2 推送镜像库（Registry）

打包好的镜像会被推送到镜像仓库（比如 Harbor 或 Nexus）。

• 以前：发布时需要手动拷贝文件，容易拷错版本。
• 现在：发布时，直接从仓库拉取这个镜像。因为镜像是唯一的、不可变的（Immutable），所以“在我机器上是好的”这个问题彻底消失了。

溪源比喻：
制品就像是超市里的“冷冻预制菜”。不管你在北京还是在广州，只要加热（部署）的方式一样，做出来的味道（运行结果）绝对是一样的。

04 第三步：持续交付（CD）—— 环境的一致性

有了标准化的“预制菜”（制品），下一步就是把它端上桌。这就是持续交付（Continuous Delivery, CD）。

CD 的核心挑战是：环境一致性。

4.1 自动化部署到测试环境

流水线会自动把制品推到测试环境。

• 以前：运维老张手动在服务器上敲命令 java -jar oa-system.jar。
• 现在：CD 工具（如 ArgoCD 或 Spinnaker）自动读取 Kubernetes 的配置，启动一个新的 Pod 来运行这个镜像。

4.2 自动化冒烟测试

服务启动成功后，流水线会自动发起一轮冒烟测试（Smoke Test），验证核心功能（比如 OA 首页能不能打开，登录能不能用）。

如果这一步也通过了，这个版本就被标记为“Release Candidate（候选发布版）”。这意味着：它已经准备好了，随时可以发布到生产环境。

05 第四步：发布策略 —— 怎么发才不背锅？

这是 DevOps 最迷人的地方。在传统模式下，发布就是“大停机、大重启”。在 DevOps 模式下，我们有多种“无损发布”的策略。

5.1 滚动发布（Rolling Update）

假设 OA 系统有 10 台服务器。

• 以前：10 台全部停机，同时更新，耗时 1 小时。
• 现在：
  1. 先停掉第 1 台，更新它，启动它，检查健康状态。
  2. 没问题后，再停掉第 2 台……
  3. 最后更新完第 10 台。
  • 结果：整个过程用户无感知，业务不中断。
    

5.2 蓝绿发布（Blue/Green Deployment）

• 我们维护两套完全一样的环境：蓝色（当前线上）和绿色（新版本）。
• 更新绿色环境，测试通过后，把流量瞬间切换到绿色。
• 如果出问题，瞬间切回蓝色。

5.3 金丝雀发布（Canary Release）

这是最高级的玩法。

• 先给 5% 的用户（比如 OA 系统的“HR 部门”）使用新版本。
• 观察一天，如果没有报错，再把流量扩大到 100%。
• 结果：风险被降到了最低。就算有新 Bug，也只影响了 5% 的人，而且能第一时间发现。

溪源比喻：
以前的发布像是“换轮胎”，必须把车停下来，四个轮子一起换。
DevOps 的发布像是“高速换胎”，一边跑一边换，而且可以先给一辆车换右前轮，看看稳不稳，再换其他的。

06 第五步：监控与反馈 —— 闭环的最后一步

发布成功不是终点，运行稳定才是。

6.1 实时监控

在 OA 系统上线的同时，监控系统（如 Prometheus + Grafana）已经在盯着它了。

• 它监控：CPU 使用率、内存占用、接口响应时间、错误率。
• 场景：如果“加班打车”功能上线后，报错率突然飙升，系统会自动触发告警，发短信给小王和老张。

6.2 快速回滚

如果监控发现严重问题，DevOps 流水线支持“一键回滚”。

• 以前：回滚需要找昨天的备份，恢复数据库，耗时半天。
• 现在：因为制品是版本化的，运维只需要在控制台点一下“回滚到上一个版本”，流水线会自动把旧镜像拉起来。几分钟内，业务恢复如初。
  

07 总结：DevOps 的全景图

让我们把刚才讲的串联起来，这就是 DevOps 的完整生命周期：

mermaid
graph LR
A[开发者提交代码] --> B(CI: 自动构建 & 测试)
B – 通过 --> C[生成 Docker 镜像]
C --> D(CD: 部署到测试环境)
D – 测试通过 --> E[部署到生产环境]
E --> F{监控与反馈}
F – 发现问题 --> A
F – 运行正常 --> G[用户享受业务价值]

1. 开发：写代码，推送到仓库。
2. CI：机器自动编译、跑单元测试。
3. 制品：打包成 Docker 镜像。
4. CD：自动部署到测试、生产环境。
5. 发布：滚动更新或金丝雀发布，不停机。
6. 监控：实时监控，有问题自动报警或回滚。
   08 溪源的总结

聊了这么多技术细节，溪源想说的是：

DevOps 不是一个工具，而是一个“不断缩短反馈回路”的过程。

• 以前，代码写错了，可能要两周后上线才发现。
• 现在，代码写错了，两分钟后 CI 就会告诉你。

这种“极速反馈”，才是 DevOps 的灵魂。它让团队敢于修改代码，敢于尝试创新，因为即使出错了，也能在几秒钟内挽回。

对于我们的 OA 系统来说，这意味着行政部提出的每一个小需求，都能在几天内而不是几个月内见到用户。

这就是业务引领的 DevOps。

如果文章对你有帮助，不妨点个推荐或分享给需要的朋友。
感谢你来。坐下来，慢慢聊~
—— 溪源，于《编程小馆 》