研发管理经验总结：1 从"混乱"到"清晰"——我们的研发协作进化史

0 开篇故事：当狐狸程序员遇上树懒运维

在葱郁的森林里，狐狸（程序员）每天高效地敲代码，树懒（运维）慢悠悠地维护着系统，猫头鹰（架构师）在高高的树枝上设计蓝图，项目管理（野马）则风风火火地协调进度，猎狗（测试）一丝不苟地检查每个漏洞。

表面上看，协作井然有序——狐狸提交的代码顺着树懒搭建的“藤蔓管道”流向测试区，猎狗仔细检查后，项目管理一声令下，猫头鹰调整架构，一切流畅运行。

可实际上，每个人都心存疑惑。 狐狸挠头：“为什么我的代码在测试环境跑得好好的，一到生产环境就‘卡树’？”

树懒慢吞吞地回答：“呃……K8S集群的事，

下次再说。”猎狗汪汪叫：“测试通过，但用户反馈‘猎物（Bug）’还在！

”项目管理甩着尾巴急得团团转：“通知群消息太多，我追不上！

” 猫头鹰在树梢打了个哈欠：“别急，明天开个会，我画个‘森林地图’，把打包、镜像、流水线都标清楚。

”众人点头，终于松了口气——原来谜团不是协作问题，而是没人真正看懂这片“森林”的运行规则。

1 背景

已经在研发团队中搭建了基于GITOPS的协作体系，也规范了每个岗位的协作方式，做了视频讲解和答疑。

但是团队不停的有新人加入，就算是一些工龄比较长的前端和后端，测试和项目管理对系统的运行和各种通知群都比较迷惑。

前后端研发岗位在开发环境中是按照物理部署的方式在本地开发的，而生产和测试集成环境是使用Docker+K8S的方式部署的，研发对软件系统在生产环境的运行方式非常陌生和好奇。

所以，我抽取时间，整理了一些简单的材料，对前后端的项目的打包和制作镜像过程，对应的流水线和集成发布的通知群汇总到一起，进行一次综合的介绍。

想象软件交付是一条快递链路：

开发环境：狐狸在本地手工打包"代码包裹"（像寄送散装水果）

生产环境：树懒用标准化集装箱（Docker镜像）+智能分拣系统（K8S集群）运输

为什么出问题？狐狸习惯了散装运输，突然改用集装箱时，经常忘记贴标签（镜像版本混乱）或选错运输路线（K8S节点配置错误）。

2 云原生的CICD拓展

技术团队对软件系统要交付快，必须得进行持续交付，跑敏捷研发模式是很多技术团队的选择。

所以，在各个阶段都敏捷并且可持续，才是研发生产力和打造优秀产品的核心。

有几个概念，我先定义一下，如果不恰当，读者可以在留言区说明。

技术部门对一个软件系统的开发，部署，监控都是敏捷而可持续的，可以很好的支撑业务的需求和变化；

CI: 持续集成 continue integration ， 软件开发是多人协作，最终需要综合所有开发的成果，包括特性，缺陷，优化。 最终以一个整体运行。

CD: 持续交付 continure deploy , 软件开发最终是要交付客户一个可运行的系统，必须可以低成本密集的更新；

研发团队出现的问题是在CICD阶段，对这两个阶段不理解，看不全，然后迷惑。

3 技术架构和部署架构

要了解软件系统的运作过程，必须有一个全景图。这个是统一研发团队的各个岗位认知的非常关键的基础。

前端，后端，测试需要明确自己开发的工程对应的是哪些组件，通过这个图可以非常明确。

通过对整体组件的了解，实现一些业务功能可以使用哪些组件配合，会比较清晰，设计技术实现方案的时候，可以直接看到全链路，从而客观的对比各个路径和解决方案的优劣。

狐狸视角：只显示与代码提交相关的环节（打包→镜像推送）

树懒视角：聚焦K8S节点状态和日志

猎狗视角：突出测试环境与生产环境的差异对比

这个图展示了代码是怎么通过流水线打包，制作镜像，发布到k8s集群或者ecs机器上。整体的流向比较清晰。

然后可以聚焦自己感兴趣和迷惑的步骤进一步细化。

比如前后端的打包和制作镜像过程，是在流水线中完成。

部署到k8s集群和发出集成和发布通知也是在流水线中完成的。

4 打包制作镜像更新方式解密

下面是后端的springboot程序的打包，制作镜像，部署，通知的关键步骤和流水线截图。

后端部署三步曲：

1. 备料：mvn clean package（像淘米煮饭）

2. 装盒：docker build（把米饭装进保鲜盒）

3. 送货：kubectl apply（把盒子放进智能冰箱）

常见问题：

❓"为什么我的镜像总比别人慢？" → 检查冰箱门是否关紧（K8S节点资源不足）

❓"版本号冲突怎么办？" → 在米饭里放时间戳纸条（echo 'export const version=${DATETIME}'）

下面是前端的vue3程序的打包，制作镜像，部署，通知的关键步骤和流水线截图。

dockerfile 我就不给出了。

后端基于java8的jdk作为基础镜像。

前端基于openrest作为基础镜像。

各个组件模块的打包部署综合如下图。方便前后端和运维同事检索。

5 流水线和通知群解密

原来的通知群就像所有快递都堆在一个驿站：

CI群：早会提醒+延期任务（像驿站的"待取件"通知）

CD-QA群：测试环境更新（"美东驿站到货"）

CD-PROD群：生产环境发布（"总部驿站签收"）

解决方案：

按角色分配驿站取件权限（测试只关注CD-QA群）

紧急告警直接短信通知（CM-PROD群置顶+电话提醒）

特殊用途流水线说明：

6 小结

研发团队在敏捷协作中面临的核心问题是：流程已建立，但认知不统一。

尽管GitOps体系规范了协作方式，但新人及部分成员对打包、镜像制作、流水线部署等关键环节仍存在困惑，导致“协作有序但理解模糊”的矛盾。

关键原因

• 技术认知断层：前后端开发在本地模拟物理部署，但生产环境基于Docker+K8S，导致对运行时环境陌生。

• 通知群碎片化：CI/CD/CM四类群消息混杂，优先级不清晰，重要信息易被淹没。

• 文档与实操脱节：虽有架构图和流程说明，但缺乏针对具体角色（如测试、前端）的“视角化”解读。

解决方向

• 可视化全景图：用“森林地图”类比系统组件关系，标注各环节（如打包、镜像推送）的输入输出。

• 分层通知机制：按角色订阅通知群（如测试只关注CD-QA群），减少信息过载。

• 关键步骤手册：针对高频操作（如后端镜像制作）制作“傻瓜式”图文指南，附常见问题解答。

我也给各位读者提一个问题：

如果明天所有自动化工具都消失了，你的团队还能靠白板笔和便签纸完成一次部署吗？

如果有收获或者有启发，我很高兴，请点赞，收藏加留言，跟我一起交流。