使用 ChatOps 改进研发流程

1. 什么是 ChatOps

GitOps、ChatOps、AIOps 等 (以下简称 NewOps ) 是近几年出现的新兴运维理念。NewOps 将 Ops 从混沌的状态离析为两个部分：一个面向用户，趋势是更加人性化、可审计、可回溯；另一个面向基础设施，趋势是更加程序化、自动化、智能化。

下面，我们主要聊一聊 ChatOps 。

如上图，ChatOps 的前端通过聊天工具驱动，后台通过机器人执行操作，更新基础设施。这里简单介绍一下在 GitHub 上的两种 ChatOps 工具。

• Prow

在文档《DevOps 工具链之 Prow》[1] 中，我曾做过分享。通过标签驱动开发流程，在 Kuberntes 社区中具有广泛实践，在目前的团队中主要由我负责维护。

• Hubot

Hubot 是 GitHub 开源的聊天机器人，使用 .coffee 或者 .js 文件进行配置，可以通过评论执行动作。下面是一个官方的示例:

module.exports = (robot) ->
  robot.hear /badger/i, (res) ->
    res.send "Badgers? BADGERS? WE DON'T NEED NO STINKIN BADGERS"

  robot.respond /open the pod bay doors/i, (res) ->
    res.reply "I'm afraid I can't let you do that."

  robot.hear /I like pie/i, (res) ->
    res.emote "makes a freshly baked pie"

当然也有其他的工具或者方案，比如 Slack Bot，这里只是举例而已。再思考一下 ChatOps，实际上它是一个匹配系统，通过匹配关键字，然后执行相应的动作。

如此简单，那么这里的 Bot 其实可以不必是一个外部服务，对于一些小的需求，几行脚本也能达到目的。

2. 团队需求和效果

下面简单介绍一下，团队的开发模式。

• 前后端分离
• 新功能由后端先完成 API 开发，接着后端将服务部署到指定的环境上，前端调用指定环境上的 API 进行新功能的开发

仓库采用的是 Monorepo ，准备向 Polyrepo 转变。现在所有组件都耦合在一起，放在一个仓库，未来会拆分到多个单独的仓库。

目前 Monorepo 遇到的问题是测试没有跟上，导致 Pull Requests 不能迅速合并，版本不能快速迭代，降低了敏捷开发的速度。这里另外一个技巧是使用功能开关，但是功能开关又意味着增加冗余、兼容代码。

为了尽量减小对研发人员的影响，主要还是需要从测试作为切入点。在之前的文档 使用 Terraform 和 GitHub Actions 对基础设施进行自动化安装测试 中，我对全部组件的交付汇聚点进行了自动化测试。这里，主要是对每个 Pull Requests 提供一个预览的环境。

前端提交 PR ，等待 All checks 完成之后，只需要回复 /deploy 即可得到一个预览的链接地址。

在预览验证完成之后，只需要回复 /clear 即可清理因预览产生的负载。

上线第一天，前端仓库负责人，通过预览就提前发现了一个 PR 的问题，效果还不错。

3. 参考

• https://hubot.github.com/docs/scripting/