DevOps 全流程拆解：代码是怎么变成业务的

欢迎光临我是溪源。在上篇文章里溪源和大家聊了 DevOps 的“道”——为什么要做、业务价值是什么。但很多客官留言说“道理我都懂但具体怎么落地呢我写完代码怎么就到了服务器上”确实DevOps 听起来很玄乎什么 CI/CD、什么流水线、什么容器化。其实剥开那些高大上的名词DevOps 本质上就是一个不断循环的“加工流水线”。今天溪源就把这个流水线拆开了、揉碎了带大家看看代码是怎么一步步变成业务的。01 传统的“黑盒”代码扔进去祈祷能出来在聊 DevOps 之前我们先看看传统开发模式下一个 OA 系统的功能是怎么发布的。假设我们要给 OA 系统加一个“加班打车报销”的功能。传统流程是这样的开发阶段小王在本地写代码用着 Windows 系统数据库连的是自己的本机。提交阶段代码写完了小王把代码塞进 Git 仓库发给测试小李。测试阶段小李把代码拉到公司的测试服务器上。这时候问题来了——测试服务器的操作系统版本和小王的不一样导致程序跑不起来。小王远程连上去修了半天环境。发布阶段终于测完了到了周五晚上发布。运维老张要把代码打包停掉服务器替换文件重启服务。灾难现场重启后发现因为配置文件里有个 IP 地址写错了系统崩了。老张连夜加班改配置周一早上全公司都在骂娘。这个过程就像个“黑盒”。小王只管写不管运行环境老张只管跑不管代码质量。代码在两个部门之间传中间充满了“等待”、“返工”和“不确定性”。这就是我们要用 DevOps 改造的对象。02 第一步持续集成CI—— 让代码“自我净化”DevOps 流水线的起点是持续集成Continuous Integration, CI。它的核心逻辑是只要代码一变机器就自动干活。回到 OA 系统。小王在电脑上写完了“加班打车”功能的代码按下 Commit提交的那一刻神奇的事情发生了2.1 触发器Trigger代码提交到 Git 仓库的瞬间CI 服务器比如 Jenkins 或 GitLab CI收到了信号“嘿有新代码了”2.2 自动构建BuildCI 服务器会自动拉取最新代码在一个全新的、干净的容器里比如 Docker进行编译。以前小王说“我本地跑得好好的”。现在不管小王是用 Mac 还是 WindowsCI 服务器都是用标准的 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 台更新它启动它检查健康状态。没问题后再停掉第 2 台……最后更新完第 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 的完整生命周期mermaidgraph LRA[开发者提交代码] -- B(CI: 自动构建 测试)B – 通过 -- C[生成 Docker 镜像]C -- D(CD: 部署到测试环境)D – 测试通过 -- E[部署到生产环境]E -- F{监控与反馈}F – 发现问题 -- AF – 运行正常 -- G[用户享受业务价值]开发写代码推送到仓库。CI机器自动编译、跑单元测试。制品打包成 Docker 镜像。CD自动部署到测试、生产环境。发布滚动更新或金丝雀发布不停机。监控实时监控有问题自动报警或回滚。08 溪源的总结聊了这么多技术细节溪源想说的是DevOps 不是一个工具而是一个“不断缩短反馈回路”的过程。以前代码写错了可能要两周后上线才发现。现在代码写错了两分钟后 CI 就会告诉你。这种“极速反馈”才是 DevOps 的灵魂。它让团队敢于修改代码敢于尝试创新因为即使出错了也能在几秒钟内挽回。对于我们的 OA 系统来说这意味着行政部提出的每一个小需求都能在几天内而不是几个月内见到用户。这就是业务引领的 DevOps。如果文章对你有帮助不妨点个推荐或分享给需要的朋友。感谢你来。坐下来慢慢聊~—— 溪源于《编程小馆 》