为什么“简单利用”开发测试阶段须要 ChatOps ?

• 随着部署工具及部署 pipeline 流程引入到整个开发迭代流程中，应用公布单模式进行开发、测试环境的部署往往须要关上多个 web 控制台，对于日常开发迭代来说较为繁琐。
• 现在我的项目的开发往往会存在多个 git repo，每个 git repo 又会产生多个制品用于部署，基于手动抉择的形式对于开发人员开发、测试都十分不敌对。
• 在音讯告诉方面，尽管应用了 webhook 将我的项目协同信息进行了群告诉，但我的项目所有告诉发送到一个群内，造成信息爆炸，逐步失去告诉意义。

首先来看咱们团队以后的部署流程所须要的步骤，须要通过“期待 CI 构建胜利”“公布单抉择所需制品及环境”“部署”这么几个流程。其中制品的抉择，在每次公布时，都须要进行抉择，当组件较多时，则较为繁琐。

并不是所有的场景都须要 ChatOps，这里重点强调“简单利用”，是因为利用复杂度进步后，会面临配置简单、制品简单、流程简单的场面，因而须要 ChatOps 工具来升高开发测试过程中的部署难度。而对于简略的利用，例如我的项目初始阶段的单体利用，则不用大费周折折腾简单的工具流程，在 CI 中集成小局部自动更新测试环境的流程就很高效。

如何联合 CI/CD 体系和 IM 开放平台构建 ChatOps 工具

以后 CI/CD 落地的现状及选型思考

继续集成

继续集成是所有流程的根底，指标也很明确，就是将构建环境、制品类型进行对立，便于进行后续的部署应用。在以后容器化流程的背景下，咱们也是抉择了容器镜像作为最终制品，开发人员对立产出容器镜像，不便进行部署。

所有的代码仓库，无论简单与否，都会创立 Jenkinsfile 进行构建。流程如下图所示。

利用定义选型

在利用定义的抉择上，经验了最后的 PaaS 平台自定义利用模型、代码仓库存储动态 Manifest 文件后，最终抉择了 helm 作为利用定义的工具，次要基于以下几个方面思考。

• 部署形式简略，能够通过单条命令间接进行装置，即便在工具较为匮乏的私有化环境中脱离部署工具也可应用一条命令进行部署和降级。
• 应用模板进行定义，便于进行多个正本部署及差异化配置。
• 通过制品库来存储 helm chart，dev 环境应用构建号进行版本推送，生产环境通过 helm 仓库打 tag 后进行版本推送，实现“利用定义”的版本化。

利用部署工具选型

在利用部署工具上，抉择应用 Spinnaker，次要基于以下的内容进行思考。

• 利用定义及组件版本拆散
• 基于环境加载公共配置
• 公布启动参数定制

部署流程定义如下图：

将 helm chart 及容器镜像作为制品输出，通过制品绑定将 helm chart 版本与 image 版本进行拆散，实现利用定义和利用组件版本的独立配置。

应用 values 文件援用，不便的对“某一类”环境进行对立配置，例如专用云不同厂商间的差异化配置。

构建适宜团队的 ChatOps 体系

ChatOps 工具构建的指标

• 解决音讯杂而乱的问题，以我的项目迭代为粒度进行音讯的分类、创立 IM 群组。
• 解决开发测试环境创立繁琐、须要口头约定的问题，以我的项目迭代为粒度创立独立的测试环境。
• 尽量避免 web 控制台操作。
• 迭代完结后主动清理环境、群。

开发测试过程流程梳理

如下图所示，咱们对开发测试的整个部署流程进行梳理。其中最为繁琐的、须要屡次人工操作的局部就是“部署配置”+ “ 版本抉择 ” 这个过程，如何将制品依照肯定的规定更新到对应的环境中，并且可能记住以后的抉择便是这个流程的要害。

首先，咱们须要将整个部署流程进行模板化，这里咱们应用 namespace 作环境间的隔离，将环境中最要害的两个因素，namespace、拜访域名作为启动参数，将繁多的部署流水线模板化。

告诉隔离

通过接管 webhook 事件，将原有的我的项目协同告诉进行从新散发。当我的项目协同工具中产生迭代创立时，主动触发创立一个预制好 devops 机器人的群，并利用 IM 提供的卡片能力对音讯进行优化，减少便捷的入口。我的项目协同事项变更时，主动对群内成员进行增删。同时，环境也与以后的迭代关联，在须要时通过聊天指令进行疾速创立。在迭代完结时，回收群、测试环境等，进行清理工作。

以后 ChatOps 次要实现以下指令:

• deploy – 唤出部署设置卡片。
• branch – 设置某个仓库对应的分支、查找对应制品并唤出部署卡片。

其中卡片性能合成如下图：

当环境创立胜利后，ChatOps 控制器会记录以后环境的制品抉择，当对应的制品有更新时，会自动更新以后的环境，实现测试环境一次配置，整个迭代内自动更新。

整个流程如下图：

开发测试阶段如何疾速调试利用

在日常的开发过程中，基于上述的 ChatOps 流程进行环境的部署和更新曾经能满足大部分的需要，代码推送后，也能够在分钟级做到环境的更新。

单对于联调和测试时遇到的问题须要批改时，期待一个 CI/CD 的流程显得十分漫长，另外开发新的性能和新组件时，想疾速放入测试环境中也较为繁琐。

因而咱们在寻求一个工具，用于疾速调试开发环境。

在早年的服务端开发时，咱们时常应用 sftp 插件，将本地代码同步到服务器上进行执行，那么 nocalhost 就是容器化的 rsync 工具，nocalhost 在进入调试模式时，把对应的 container 镜像替换为指定的开发镜像，并减少一个文件同步的 sidecar，能够将本地的代码同步至容器中，对于脚本类型的语言能够间接进行调试，对于像 golang 这样须要编译的类型，能够在本地构建进行同步，也能够间接在容器中进行构建。

整个应用的过程中，须要注意的关键步骤是制作适宜开发调试应用的镜像，nocalhost 提供了常见环境的开发镜像，但利用于本人团队外部时，镜像所蕴含的内容往往与组件相干，此时就须要定制一个实用于以后业务的开发镜像。次要基于以下 2 点思考:

• 尽量蕴含理论环境中应用镜像中的工具和罕用的调试工具。
• 去除掉影响调试的缓存组件，例如 php 中的 opcache。

总结

随着业务的复杂程度进步，开发测试流程中反复繁琐的操作会变得越来越多，基于已有的 CI/CD 体系构建 ChatOps 工具是解决这种问题的一个思路，抉择适宜本人团队的计划才是最为重要的。

作者

卢兴民 红亚科技 CTO

本文由博客一文多发平台 OpenWrite 公布！