「这是我参与2022首次更文挑战的第7天，活动详情查看：2022首次更文挑战」
一、使用场景
目前实际开发过程中，pc项目的打包机制有两种：一种是测试环境，直接通过将代码推送到develop分支来触发；另外一种是通过将代码合到发版分支，手动触发的方式来构建。
接下来就围绕这两方面来详细阐述一下整个过程中那些不为人知的事情。
二、测试环境构建
先大体描述一下流程，初步形成概念： 代码合入develop，推送到远程 =》gitlab触发hook钩子 =》工蜂服务处理组装 =》jenkins任务执行 =》 通知工蜂构建结果。
1. gitlab的hook钩子
其实就是一个类似于点击事件的 Push events。唯一的区别是，点击事件是点击的时候触发，Push event是推送代码到远程的时候触发。
2. 工蜂担任的角色
首先就是识别触发hook的对象是谁，gitlab推送过来的信息里面没有明确的标识分支名称，而是提供了个 "refs/heads/master" ，经过我的一番研究，最后终于弄懂了这是个什么玩意。refs竟然是reference（引用）的意思，而heads则是不需要Code Review的意思，对应的for是需要Code Review的意思，master则是我想要找的分支名称。至于更深入的解读，可以自行查看gerrit规则。
判断了是谁之后，接下来又要一通操作了。任务是哪个？任务的配置都有啥？对应的jenkins任务又是哪个？通过跟数据库一通交流之后，终于都整明白了，接下来就是交个jenkins来操作了。
3. jenkins的职责
jenkins任务相对来说，大家就比较熟悉了，就是将各种命令行操作和git操作整合到了脚本中，通过脚本自动进行打包上传。
通过整个流程的分析之后，想必大家就能看出，推送develop到远程之后，构建不触发的可能原因了。
- 没有配置gitlab hook（也就是 Push Event）
- 找不到对应的jenkins任务
- jenkins任务配置参数有问题
三、线上环境的检查机制
手动触发一次线上打包会经历很多次关卡的检查，只有闯关成功才能最终触发线上环境的打包构建。
1. 合并校验
发布计划上关联的分支是否全部合入了发布分支，如果有功能分支（feature/*）没有合入发版分支（release/**），那合并校验是过不了的。
顺带说一下，发版计划编辑的原则。
如果没有构建批次执行成功（包括未执行过和执行过但是失败的情况），发布计划可以进行编辑；
-
如果功能分支已经合入到发版分支，则不允许删除功能分支；
-
如果有批次在构建中，则不允许增删功能分支；
-
校验当前发版计划是否将该发版日期之前发版的发布计划的代码全部合入master，其次是，合入master的代码是否全部合入该发版计划，防止出现漏合代码导致功能被覆盖掉的情况。
