用瀑布开发模式的企业是否可以直接上DevOps

原文链接:https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=43824

在Jez Humble的《持续交付》一书中,我们能看到反模式和持续交付原则提倡的开发方式的对比,持续交付能给我们带来的好处,包括但不限于如下:

  • 更早的交付需求

  • 提高版本质量

  • 减少由不良好的配置管理引入到生产环境的错误。

  • 缓解积压发布带来的压力

  • 更加灵活地部署

书中很多地方提到了精益敏捷,已经假定你所在的公司开发模式就是敏捷了,然后再实践持续交付。但是在我们走访企业的时候,发现很多企业,依旧使用的是瀑布开发模式,因为敏捷转型是一场变革,有的企业由于高层领导不接受转型,所以一直保留着瀑布开发方式。那么在这种情况下,是否可以进行DevOps落地?是否可以采用持续集成、持续交付呢?


这里我说的DevOps指的是狭义的DevOps,即Dev-Ops的部分。因为端到端的DevOps已经包括了敏捷部分。

在考虑这个问题的时候,想到了一张图,见下图,也是Jez Humble的图。

这里我们可以看到,对于瀑布开发模式职能团队来说,开发和测试团队的交接,开发团队和运维团队的交接,分支模式的使用,严格控制发布窗口,这一系列使得交付频率受限,是高不了的。也就是说,瀑布开发的模式,决定了你无法完全进行DevOps落地。

那么再看看有哪些能改善的地方呢?能不能在不受职能团队影响的情况下,落地DevOps的一些好的实践呢?比如持续集成的几个原则,这些是纯开发团队自己能做的,不涉及到多职能团队,所以可以独立进行开展。包括如下

  • 构建失败之后不要提交新代码

  • 提交前在本地,或持续集成服务器,运行所有测试 

  • 提交测试通过后再继续工作 

  • 回家之前,构建必须处于成果状态

  • 不要将失败的测试注释掉

  • 开发人员每天开始时至少拉取一次代码

  • 开发人员每天结束时至少提交一次代码

通过这些实践,可以提高代码的质量,减少协作间的代码冲突,降低反复工作所消耗的时间。测试方面,开发人员自己要做单元测试,同时可以适当加入接口自动化测试,来保证一定的业务场景是好用的。因为每次提交代码都要运行测试来保证质量,所以测试比如使用自动化来进行,考虑到开发人员在测试方面的投入不会高,所以用接口测试来覆盖场景就可以。每次提交新的代码,自己运行一遍接口自动化测试,可以提高代码的质量,降低代码交付给测试团队后,出现的问题。最重要的是,每开发一段新代码,自己运行一遍以接口自动化测试承担的回归测试工作,大大降低了手工的工作量。


版本控制方面,由于环境配置等内容涉及到跨职能团队了,所以这里我们只考虑代码版本库。建立版本库进行管理,并保证提交的代码和对应的需求进行关联,这样当回溯问题的时候,方便追踪。


部署流水线方面,由于运维团队控制着生产环境,所以我们只考虑开发人员在开发环境的部署,目的是可以尽早做一些集成测试和验收测试。而部署到开发环境做的频率又是很高的,即使这是瀑布开发模式。所以在这里可以引入部署流水线,并配置上代码检查、基本的测试等内容。


综上所述,笔者的意见是,对于不接受转型敏捷开发的团队,可以在持续集成、版本控制、部署流水线方面采用DevOps的一些理论、支撑的工具及最佳实践,来帮助团队提供更高质量的代码。

合智互联客户成功服务热线:400-1565-661

admin
admin管理员

上一篇:【DevOps入门篇】DevOps的3大核心基础架构
下一篇:实战CloudIDE插件开发-事件订阅

留言评论

暂无留言
取消
扫码支持