图是美的全球创新中心西门
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