Beetle编译/部署自动化

背景

公司原有的代码编译流程，是研发同学在提交代码之后，需要到devops平台，点击编译，等待成功之后，才能点击部署，等待成功后才能进入测试环节。此场景下，用户需要频繁地切换到平台进行操作，影响了用户效率。在这个背景下，我们设计了用户提交代码后，自动发布依赖包->自动编译->自动部署的功能。

当前流程及问题

Beetle现有编译、部署流程如图：

用户提交代码后需要到 Beetle 分支详情页面，若需要发布 Jar 包，则编译前要先点击发布jar包，等待jar 包发布成 功再点击编译，又要等到编译成功后才能点击部署。若遗忘发布 jar 包直接编译将会编译失败，需要发布 jar 包后重新编译。且这些手动点击的操作都需要等待成功之后才能进入下一流程，无疑会浪费掉开发同学等待的时间。

问题：

• commit 与编译之间是相对独立的，如何将他们之间串联起来

• 开发人员提交代码后我们系统是无感知的,如何做到感知代码提交

• 对于需要发布 jar 包的工程，如何做到在编译前先发布 jar 包，否则编译将会失败。

• 在 Beetle 等待的耗时如何省掉

---

切入点

GitLab提供的Webhook功能：

Webhook 可以在特定事件出现时，触发用户定义的 URL，例如，提交了新代码或者创建了新的 issue 就可以触发这个 URL。我们可以将 webhook 配置为侦听特定事件，例如代码推送或合并请求，当该事件发生时，GitLab 将带有数据的 POST 请求发送到 Webhook URL。通常，我们需要根据自己的要求设置自己的 Webhook 接收器，GitLab 将监听到的事件信息发送到我们的 Beetle 系统。

方案设计

• 利用 gitlab 的 webhook 监听代码的 push 动作，将 commit 信息通过配置的 URL 发送给 Beetle。

• 分支新建时：增加是否开启 push 后自动编译选项，是否自动部署选项，如果选择了本选项，则部署 ip 必选。

• 在分支详情页增加是否开启 push 后自动编译选项，是否自动部署选项同上。

• 通过 diff 判断是否需要在编译前发布 jar 包。

• 在操作期间的流程用户也应需感知，因此将会在触发开始或过程失败时发送微信消息通知用户。

流程图如下：

 

设计流程图

diff检查编译前是否需要发布jar包

由于项目的依赖文件都放在项目的 contract 文件中，因此我们需要在编译前检测提交的代码是否包含 contract，由此来判断是否需要发布 jar 包。我们根据 webhook 传递的信息拿到工程信息及 commitid，Beetle 获取信息后，查询文件变更列表是否包含 contract 字段，若包含则说明需要发布 jar 包。

diff检测流程

• Beetle 收到 commit 信息后调用 diff 接口检测是否需要先发布 jar 包。

• 若不需要发布 Jar 包则直接进行编译。

• 若需要发布 jar 包，则先发布，当发布成功后再进行自动编译，如果发布失败则发消息给代码提交人提示 Jar 包 发布失败的原因，以便开发人员进行处理。

• 自动编译结束后再触发自动部署和相对应的 CI 配置。

• 触发相应 CI配置例如静态代码扫描，执行测试用例和覆盖率等并通知给代码提交人需要关注的信息。

用户感知信息：

需要用户及时处理及关注的成功、失败事件将发送企业微信通知用户，以便用户能够及时处理。

用户使用情况及收益：

• 使用自动编译/部署的工程数量：724 个项目。

• 总分支数：七千多个分支已使用过自动编译、部署功能。

• 平均每日使用量：平均每天自动编译、部署达到三百五十次左右。

• 减少用户等待成功进行下一阶段的时间差。

• 避免了遗忘发布 jar 包导致编译失败的情况发生。

总结：

从使用情况来说，此功能很大程度地减少了开发及测试人员的频繁编译/部署及等待时间，给 Beetle 使用者提供了 便利。若配置自动编译和自动部署，那么发布 jar 包、编译、部署、静态代码扫描、执行测试用例等这一系列的流 程都将在代码提交后由 Beetle 自动完成，在一定程度上也减少了用户的咨询时间。

作者：周海霞

> 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

> 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~