为什么“复杂应用”开发测试阶段需要 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