【我想出门！】关于 devops 的一些思考​

• 2020 年 2 月 25 日
• 筆記

上半年在做微信文档的时候，有一些自动化的需求，比如像一键发布，git push 发布，自动发布等。后面推动内部运维，做了 devops 的尝试。以前手工发布会经常遇到 环境问题、权限问题、测试问题，基本上此次都要解说好久，而且大部分都是重复描述，我只能说：我太难了。

整体感觉上来说，在接入 devops 之后，彻底解决了我在 开发 和 客服 之间身份徘徊的问题，让我能够更加专注到开发中去。

借由此机会，顺便了解下业界关于自动化系统的方案。

常见自动化系统

在日常开发中，遇见两种比较具有代表性的系统，一个是腾讯内部的蓝盾流水线(pipeline)，一个是 github Action(yml) 。

• 蓝盾(左图): 通过流水线编排的方式，将编译、测试、自动化部署通过 服务 的方式来提供，用户能够非常直观的了解到自己实现的流水线是什么，以及它完成了哪些事情。
• github action(右图): 通过 yml 文件格式，描述当前 action 需要做的任务。整体来说，这种方式对于开发者上手门槛较高，里面包含了很多开发者陌生的概念，比如 action、job、runner 等。但是，正是由于这些概念，也给 github action 带来很大的灵活性。

(本人作为一个非专业且业余的开发者来说，还是挺中意 腾讯蓝盾 这种傻瓜式流水线的模式。

了解一下概念

在自动化系统中，有几个必备概念需要了解，便于你在后续开发中的应用，CI(Continuous Integration, 持续集成)、CD(Continuous Delivery, 持续交付)、CD(Continuous Deployment, 持续部署)，还有一个 DevOps(自动化运维) 。

• CI: 主要完成的事实，保证每次合并到主干的代码都是可用，并且都是经过自动化测试的。比如，A 在 feature-A 开发了一个功能，完毕后，合并到 master，此时通过 PR 触发自动化 CI，如果 CI 失败了，则说明 A 的代码有毒，需要 review 一遍。
• CD(Continuous Delivery, 持续交付): 当多个开发者完成功能开发后，会通过一系列自动化测试，人工测试后，达到一个可发布阶段(staging)，最终是通过手动来确定是否发布。
• CD(Continuous Deployment, 持续部署)：比持续交付更自动化，最终的发布环节也是自动发布的。这个环节去年做的文档自动化类似，改了文档之后，提交代码直接上线。

参考下图，可能更明确些：

最后还有个 DevOps，这个概念就很玄学，可以说 DevOps 是一种自动化理念，通过 CI/CD 的方式来保持测试环境和生产环境的一致性， 解决运维和开发之间的沟通问题。这个概念可以参考下图：

打算做什么

前段时间在做微信文档自动化时，devops 其实就已经带给我了很大的震撼（原来微信以前的运维系统这么难用。之后，组内有部分是小程序业务，了解了一下，基本现状是一切围绕开发者工具，搞个 Macos 系统 + 微信开发者工具，通过 http 的方式来调用工具提供的脚本命令。这个也是业界大部分自动化系统的做法。

整体来说，只要你搞的自动化系统上有开发者工具，其他的自动化操作都可以完成。不过，细细挖掘会发现，这样做的成本还是有点高，比如，你原先在一个组里面做了一个自动化系统，但是，你很难将这个自动化系统再推广到其他组去（分享能力差，不易复用。

因为和工具那边隔的很近，有消息工具已经把 代码上传的能力放出来，这样做解决了自动化系统大部分的工作量，点个赞。