2021年持续交付经验小结

图是美的全球创新中心西门

2021年小结

后知后觉又一年。

2021年，我带着2个人（一个偏物理层运维，一个偏应用层的运维）支撑着8个平台，每平台约3个环境的运维工作。

• 部署方面：测试环境每日部署次数约250次，预发布和生产环境从一月至十一月部署达100次，约每3天1次。之前，我们只能在半夜用户量最小的时候部署，大约从10月开始，我们可以在白天进行部署。所有的应用及配置，所有的环境都采用高度一致又不失灵活性的部署方案。

• 构建方面：构建次数每日百次以上。

• 测试方面：8月左右做了单元测试方面的培训，至今没有的效果，因为还没有精力通过集成单元测试率覆盖率报告来push开发写更多的单元测试；11月加入冒烟测试，对于环境的稳定性有一定的改善。

• CodeReview方面：大概4月开始实施CodeReview，对于代码质量有一定的改进（感觉而已，所以，需要更多的统计数据）。最近1个多月，来了不少新人，新人开始觉得CodeReview只是形式；

• 混浊工程方面：这块最近才开始做，有些不尽人意。

我们的应用目前已经全部运行在K8s之上。持续交付领域使用到的技术栈有：

• 代码托管：GitLab

• Pipeline：Jenkins

• 部署：Ansible、Helm

• 测试：Pytest、Allure

没有使用云厂商的DevOps产品，是因为试用过的产品，对于Everything as Code都没有很好的支持。也似乎没有意向要更好的支持。所以，全使用开源的工具进行组装。

我们采用主干开发，release分支发布策略。

这里想给大家分享的经验有：

• 功能开关是实现持续部署的秘方。如何说服大家倒是个难点，笔者说了很长时间，开发团队才愿意采用；

• 应用软件架构本身的高健壮性是实现快速部署节奏的提前；

• 冒烟测试要尽早加入，我们加入太晚了；

• 运维工作尽量自助化：该开发自己做的，还是要开发自己做。比如测试环境的部署、业务级别的告警设置；

• 所有的事情，都优先使用配置代码实现，即Everything as Code；

• 混浊工程的前提是监控和自动化。如果这些没有做好，不叫工程，只能叫“玩”；

• 持续交付领域的知识在团队中没有工具的支持，容易腐化。比如CodeReview实践会被慢慢沦为形式，我们目前还没有CodeReview的辅助工具。

2022年展望

• 21年的数据是我自己扳手指头统计的，22年，我们希望能自动统计出来；

• 加强单元测试：通过报告PUSH开发人员提高单元测试的覆盖率；

• 实现自动化的金丝雀部署。目前已经实现初级手工的金丝雀部署；

• 低成本的实现统一的告警平台；

• 使用Jsonnet等具有编程功能的配置语言替换YAML的配置方式；

最后，如果能自动化统计业务系统的feature功能的使用率就更好了。

这是2020年的 一些持续交付的实践经验 。