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

标签: 微服务架构 | 发表时间:2019-10-21 15:28 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi

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

1. 企业研发管理过程的标准化和规范化
2. 企业研发资产的可视化
3. 协助企业进行微服务架构转型的关键支撑

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

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

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

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

1. 核心研发资产,包括需求设计文档,源代码往往掌控在关键的一个人手里面,或者干脆无文档
2. 研发过程不透明,研发资产没有显性化,他人很难短期接手

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

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

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

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

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

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

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

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

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

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

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

 

相关 [devops 平台 收益] 推荐:

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

- - 人月神话的BLOG
在9.18日自己谈过一篇DevOps平台实施收益和价值的文章,在当时主要提到了以下三点. 企业研发管理过程的标准化和规范化. 协助企业进行微服务架构转型的关键支撑. 今天准备进一步来扩展谈下里面的一些关键内容. 记得在几年前自己的一个朋友,原来是做工程设计咨询的,但是在规划设计项目中逐渐发现了有不少的信息化软件开发需求,刚开始的时候走的全部外包但是发现不好管理和持续.

谈 DevOps 平台设计:版本号相关功能的设计

- - IT瘾-dev
在设计 DevOps 平台时,笔者认为版本号的管理是一个绕不开的课题. 可是,行业里似乎很少人提这个事,笔者觉得要谈一谈,所以就有了这篇文章. 一万个人的眼里有一万个“版本号”. 笔者这三年在同一家公司里,换岗换了四个团队. 团队的成员组成各异,有的团队都是在大型跨国企业跳槽过来的,有的团队大部人都是刚毕业的.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

2019十大最佳DevOps工具

- - IT瘾-tuicool
【编者的话】DevOps落地重要的一方面是选好工具集,本文介绍了最流行的DevOps工具. 开发和运维的集成翻开了软件开发的全新篇章. 如果你还是DevOps的新手,或者正在寻求改进已有流程的方法,那么第一道关卡就是调研哪些工具最适合你的团队. 本文整理了工具列表,为大家选择所需的工具提供详实的参考信息.

DevOps不是个技术问题,而是个业务问题

- Allen - 译言-电脑/网络/数码科技
来源DevOps is not a technology problem DevOps is a business problem. DevOps不是个技术问题,而是个业务问题. Since Patrick Debois called for the first DevOps Days event and unleashed the term "DevOps" upon the world, there is no denying that DevOps has evolved into a global movement..