谈DevOps支撑平台实施收益和价值02(10.21)

在9.18日自己谈过一篇DevOps平台实施收益和价值的文章，在当时主要提到了以下三点

今天准备进一步来扩展谈下里面的一些关键内容。

记得在几年前自己的一个朋友，原来是做工程设计咨询的，但是在规划设计项目中逐渐发现了有不少的信息化软件开发需求，刚开始的时候走的全部外包但是发现不好管理和持续。因此开始着手建立自己的软件开发队伍，更我说起这个事的时候差不多也有了10多个人的软件开发团队。

记得是有一个晚上，朋友突然找我让我出去聊下有急事，过去后才知道是由于内部管理或利益分配的诸多原因，在这里不方便细问，这个开发负责人逐步要离职走准备去单独干，而且可能还准备把几个核心开发都带走。由于我朋友本身也不是技术和IT出身，遇到这种事情本身还是一抹黑找不到对策，找到我的原因无碍乎是问我这边的技术人员或团队能不能先把他那边的系统和开发工作先承接过去下。

前期没有完整的研发流程，需求文档也不完善，而且在离职的时候提交的文档，代码是否完备这些即使是有经验的技术人员去验证本身也存在相当的难度，到了最后离职谈判阶段实际上我朋友本身已经处于相当被动的地位。在这个时候来谈工作交接或找人接替本身也为时已晚。而实际上具体分析个人理解实际上这个问题很多非技术背景的领导都会遇到，造成的原因主要是。

1. 核心研发资产，包括需求设计文档，源代码往往掌控在关键的一个人手里面，或者干脆无文档

2. 研发过程不透明，研发资产没有显性化，他人很难短期接手

而要解决这个问题，个人理解至少需要从几个方面来考虑，第一就是我们常说的研发团队划分，岗位角色设置上面要考虑分离，关键岗位角色要考虑有备份和AB角，能够相互替代。第二就是我们说的研发过程流程改进，研发资产的可视化。

而对于第二点，实施DevOps平台本身就是一个很好的支撑，即研发资产可视，过程可视，你每天新产生的代码都要检入，并进行相关的代码检查和自动化测试，整个持续集成和自动化构建确保了进入到我们配置管理库的代码是编译通过的。其次，我们自动构建完成的部署包本身就是推送给测试人员进行测试的部署包，中间不需要开发人员去插手或增加小动作，那么测试人员测试通过的版本，一定就是当前代码已经实现的版本。

即在整个DevOps持续集成过程中，实现了研发资产的持续落地可视化，这个可视化不仅仅是整个研发版本的可视，更是中间各个阶段的可视化，即使你团队所有人员都离职，我们也应该能够确保当前研发资产库里面的代码能够自动化构建完成并形成当前的应用版本。代码当前是全的没有遗漏，而且代码完全和当前功能对应。

还有就是，在实施SOA项目的过程中，我们也经常和甲方沟通，当时有一个甲方就提到一个关键点，当要给完整的业务系统招标选择了要给供应商来定制开发后，在项目验收完成后虽然提交了相关的文档，相关的源代码，但是发现后续的运维甲方根本无法承接。包括乙方提供的源代码本身都无法编译通过，即使能够编译通过构建出来的版本功能也和当前生产环境功能有明显差异。甲方如果本身不是专业的IT类公司实际上很难在验收的时候发现这些问题，也就是说最终验收你得到的文档，代码等内容实际上完全无法支撑甲方运维。

而这个问题和前面一个问题很类似，就甲方来说如何加强对开发商的管控，如何确保开发商定制的系统版本和当前的研发文档，源代码资产等是时刻同步的。如何确保最终验收的研发交付文档，代码就是和当前生产环境运行的系统版本是一致的？

如果所有的事情都到了验收的时候才去处理，那么往往为时已晚，说得直白一点对应乙方提供给甲方的业务系统对甲方来说就是一个黑盒子，里面的东西甲方完全搞不懂，只有乙方能够进行后续运维和定制维护。也就是甲方不得不承认间接被乙方绑架的事实。

我们都知道最终的研发资产要能够移交，要能够可交维，但是里面的关键点究竟在哪里？

简单来说就是 研发资产的可交维必须是一个在一开始就持续增量不间断进行的过程，一个是按阶段进行持续的交付，一个就是按业务系统的功能点进行持续集成交付。在整个过程中会分很多小的阶段点，在这些阶段点都需要植入相应的自动化检查和测试手段，确保最终入库的资产质量是满足的。整个持续集成过程在一开始配置完成后，研发人员就不应该过多的介入，而应该是流水线自动进行，确保中间没有人为不确定性因素的加入。

我们在给甲方推DevOps绝对不是简单的解决持续集成的问题，而是真正将研发过程管理的经验，包括研发资产的持续可视化融入到整个DevOps平台，实现真正的研发资产可控，过程可控，降低对单个人，乃至单个团队的强依赖。

我们在推DevOps平台，会过度强调了整个自动化，持续集成流水线过程，强调研发和测试的协同，而忽视了研发和运维过程的协同。而研发和运维的协同是整个DevOps的另外一个关键内容，研发的系统，包括每一个功能点应该是做到从一开始就是可运维的，具备运维属性。

一个系统的可运维，本身有一个潜台词就是系统可移交。而对于甲方来说也可以很名正言顺的强调是为了整个研发管理过程的规范化，自动化和研发效率提升来推进DevOps平台工作。下面一篇将从完全云化角度来进一步思考DevOps平台的实施价值。