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

举报
华为云PaaS服务小智 发表于 2021/02/02 11:01:29 2021/02/02
【摘要】 原文链接:https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=43824在Jez Humble的《持续交付》一书中,我们能看到反模式和持续交付原则提倡的开发方式的对比,持续交付能给我们带来的好处,包括但不限于如下:更早的交付需求提高版本质量减少由不良好的配置管理引入到生产环境的错误。缓解积压发布带来的压力更加灵活地部署...

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

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

  • 更早的交付需求

  • 提高版本质量

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

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

  • 更加灵活地部署

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


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

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

image.png

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

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

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

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

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

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

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

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

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

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


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


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


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

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。