图是美的全球创新中心西门
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年的 一些持续交付的实践经验 。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/70966.html
