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),更多干货实践,欢迎交流分享~
版权声明: 本文为 InfoQ 作者【转转技术团队】的原创文章。
原文链接:【http://xie.infoq.cn/article/bfaf1f94de892e20991e27096】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论