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

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

• 更早的交付需求
  

• 提高版本质量
  

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

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

• 更加灵活地部署

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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