工具，特别是平台化的工具落地，一定不是一蹴而就，需要逐步推进落地。
01
如上图，在没有统一的DevOps工具平台之前，每个研发环节都有自己独立成熟的管理工具，因为在瀑布式的研发模式中，每个环节是相对独立，术业专攻。但是在敏捷研发的模式下，部门墙需要被打破，研发链路上各节点需要频繁沟通。
一个研发团队需要使用如此多的工具，作为技术决策者在选择时将面临不小的压力。从学习、部署再到应用，成本经不起计算。一位新同事入职，需要收藏5～6个网址，数字资产的管理面临潜在风险。更重要的是，在这种工具集形态下，没有给开发者和管理者提供一个真正有效、柔性边界协同的环境。
工具太多，切换麻烦；阶段割裂，限制流动；数据不通，无法度量；
这是DevOps工具 v1.0要解决的基本问题，不论是采用自研方式还是采购第三方平台。
02
当V1.0版本落地初见成效，团队逐步把工具迁移到统一的DevOps平台后，我们希望团队成员开始注重协同效应，1 1 > 2，每个人都能获得交付价值所需的信息上下文环境，让团队中强个体能够更强。
例如：需求与代码的绑定，需求与用例的绑定，需求与缺陷的绑定，需求与发布的绑定。在迭代即将发布的时刻，通过查看需求，就可以知道这个需求整个研发过程的数据。
例如：自动化测试用例与CICD流水线的关联，让自动化做好发布守护。
例如：实践“一次编译，多次部署”，让发布的制品可控，质量有保障。
在这个阶段，需要把平台打造成：蕴含持续集成理念，倡导卓越工程实践的平台。紧紧围绕云原生、DevOps 等技术理念，让每一个研发团队以更短的路径实践这些理念，形成团队惯性，把这些经验标准化、规模化地去推广落地。
03
每个项目的敏捷思维及实践培养起来之后，我们要面临的是如何管理更大的项目群。在实际的公司级项目中，常会涉及多项目的联合开发，共同发布，子项目间有众多依赖，如何有效地管理这些内容，是DevOps平台面临的第三个阶段问题。
项目群的需求如何联动？如何拆分到子项目中去？
多版本的代码分支如何规范，实现按需发布？
跨项目联调的用例如何管理？如何执行和跟踪？大版本的质量如何评估？
研发流程如何与公司其它流程形成互动，完成从立项到验收的全流程跟踪？
这些其实已经没有前两个阶段那种标准的答案了。笔者在自己的团队虽然积累了一些经验，但是更多的，是需要SM或者PO共同去探索实践方式，让DevOps平台更好地去承载这些实践，摸索出符合自身团队场景的最佳实践出来。
04
在V4.0阶段，可以畅想下可能的落地场景，就是基于前面三个版本的数据积累，做一些数据挖掘和探索的事，形成有效的数字化资产，而不仅仅是保存在数据库中的数据资产。期待通过对这些历史数据的分析，得到产品的大致画像，让后续的产品或者迭代做出更好的风险预判。
05
DevOps工具和敏捷理念是相互影响的。
只有工具，没有理论，那么工具就很容易变形，沦为只为了满足特定需求的产物。
只有理论，没有工具，那么理论就很容易被忘记。逐步成为天上的云朵，无法落地。
DevOps平台应该成为蕴含持续集成理念，倡导卓越工程实践的平台。
往期推荐：
测试职业规划的思考
荒废2023，从纠结开始
关于写作这件事
2022年的我
在职场上拥有选择的权力
