谈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 最佳实践』 — DevOps 平台 - Ledge DevOps 知识平台

- -
DevOps 数字化转型框架. 企业为什么需要一站式综合研发平台. 越来越来多的组织开始搞敏捷和 DevOps 转型,打造了很多的 DevOps 基础设施,比如有管理需求的 Jira, 有持续集成的 Jenkins,有容器编排的 K8S 等等. 可是这纷繁复杂的 DevOps 工具链,同时也给企业带来新的困扰.

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

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

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

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

『DevOps 最佳实践』 — DevOps 实践

- -
Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;. Automation – 自动化:在价值链中尽量除去手工步骤;. Lean – 精益:运用精益原则更频繁地交付价值;. Metrics – 度量:度量并使用数据来优化交付周期;. Sharing – 分享:分享成功和失败的经验来相互学习.

让DevOps起作用

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

DevOps,你真的了解吗?

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

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

DevOps最佳实践(200711)

- - 人月神话的BLOG
今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一:业务层面,重点是中台规划和建设. 其二:技术层面,重点是云原生解决方案,包括了微服务,DevOps和容器云. 当然,如果你是传统的软件开发框架技术,或者传统的基于虚拟机的PaaS平台也可以上DevOps实践,但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.