布景
公司原有的代码编译流程，是研制同学在提交代码之后，需求到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），更多干货实践，欢迎沟通共享~
