做这件事的起因是因为公司处于高速发展阶段，前端的代码也在逐步从原来的ko、jquery转变成现在的react，因此也出现了构建一个版本需要分别打包，然后手动合并的情况。以此为契机，我开始了整合前端资源，搭建符合公司现有业务场景的自动化构建流程。
主要用到的工具:gitlab、Jenkins、sonarqube
主要模块:任务管理、分支管理、Jenkins工作流、质量检测、资源发布。
-
1、任务管理
讲任务管理之前我先提一下我们公司的代码管理流程，因为它决定了任务管理的切入点在哪，我们公司的代码管理类似于gitflow，但是也在此流程上做了一些调整以适应公司的现状，因此每次发版之前我们都会创建一个对应的发版分支release，以便开发者将自己的feature代码合并到当前分支（可以看下图），所以任务管理模块的主要功能就是管理release走向，我们会提供release创建暂且就叫做task，同时将task关联到jenkins、gitlab、运维发布系统。这便是任务管理模块所要做的事。
-
2、分支管理
这里大家可能会有疑问，分支管理不是有gitlab吗？还有一些辅助的工具比如sourceTree、Tower等。其实呢gitlab有很多很强大的功能需要我们去定制。比如
-
上面我提到每次发版都会新建发版分支release，通常我们会从master创建一个新的branch。而这里就有一个注意点(假如创建出来的分支名称叫A)，为了当前分支代码不被其他分支污染，通常会将分支A设置为protected，如果我们手动在gitlab中设置，那么就显的很不自动了，这与我们的标题就不符了。这时候我们可以通过调用gitlab的api来实现这个步骤。
-
为了把控任务的走向，我们会通过很多webhooks来本地记录分支的状态，比如feature会通过merge request的方式提交代码给release，然后由管理者去处理，具体的处理结果我们就会通过webhooks关联到我们的任务中。这其实也是分支管理的一部分
其实我们还提供了分支的创建删除，提供了一些实时的统计数据，目的是为了让开发者在同一个地方完成所有的工作。
-
3、Jenkins工作流
有了发版分支，接下来就要创建环境去执行项目的build，这一步其实蛮关键的，构建服务在创建完分支之后自动调用jenkins api来完成job的创建，这里小小的吐槽一下，jenkins的api写的确实有点...接受参数都是xml，让我想起了早些年开发微信公众号的场景😂。在job创建时重点关注以下几个点(括号里是xml中的节点名称)
1.构建时的分支(hudson.plugins.git.BranchSpec)
2.gitlab证书id(credentialsId)
3.构建脚本(command)
说一下构建脚本，主要是用shell，实现的功能包括了获取资源、代码校验(包含了eslint和其他库合法性的校验，具体的大家可以根据业务来定)、webpack打包、提交dist到资源仓(发版)、消息通知。具体代码就不贴了
-
4、质量检测
这一块我放到后面和校验一起去说
-
5、资源发布
这里的发布系统是我司自己搭建的，也就不过多的解释了，主要做的事就是把打包好的资源发布到线上。
上面我简单的把每一个模块做了阐述，其实大部分功能都是运行在我们自建的服务中，作为一个帮助开发者简化流程的工具，我们也要考虑使用者的感受，所以我们也提供了管理端，展示任务时间轴，构建状态，代码质量指标等等。
随着公司逐渐的壮大，团队人数的增加带来了很多高并发，但易忽视的问题，就拿发版流程来说，由最初的开发->测试->线上的三步操作衍生出开发->测试->灰度->线上四步。看起来没什么问题，随着业务碎片化，微服务化，灰度到线上这一步出现了弊端，开发者无法把控灰度和线上之间的同步，品牌之间的同步。导致每到发布日，我们都得通宵去验证测试环境，灰度环境是否正确。
后来我们尝试着去掉灰度，只保留测试和线上，但线上会保留多个版本，最新版本验证通过之后做流量切换。这保证了发布效率的同时，也为提供了很好的回滚方式。但是这样的流程迫使我们再一次去梳理前端自动化流程，去思考如何去适应。
2019年的某一天，我们几个小伙伴再一次来到“小黑屋”,一起探讨如何优化前端构建流程。多版本发布带给我们几个难题
-
发版分支管理
-
代码同步时机，如何保证最新的release分支包含所有的预发布feature
-
应不应该使用版本号去代替之前的时间命名任务的方式，等等
为此我们做出了如下调整，所有分支创建权限移交至manager，同时记录分支信息，feature向release/develop提交merge request时增加合法性校验，验证是否同步master，组件库版本等信息。release构建时增加上诉合法性校验的同时，关联同一项目不同任务状态的判断，保证release包含所有预发布功能。同时所有验证失败结果实时通知到manager/developer。
接下来我们说说除了校验分支的同时我们还做了哪些质量检测。
-
首先就是我们在jenkins中运行了eslint和tslint，审核代码规范
#eslint
{
cp -v -r /Users/android/pc/eslint/eslintrc.js /Users/android/.jenkins/workspace/$1/.eslintrc_copy.js
node ./node_modules/eslint/bin/eslint.js -c .eslintrc_copy.js --ext .jsx,.js,.ts,.tsx src --ignore-path .eslintignore
} || {
send $2 $5 'fail' $1 'eslint验证失败' 'eslint'
exit 1
}
同时也会生成相应的报告
-
其次我们通过sonarqube进行项目质量审核，同样也是配置在jenkins中
结果会展示在sonarqube服务中供大家查看，这里简单吹一下sonarqube，作为一个开源工具做的真的很nice，通过他可以查出一些被忽略的问题，比如定位BUG，统计单元测试情况等等，有兴趣的可以去看看sonarqube
-
其次就是一些业务上的检查了，这里就不做说明了。
到这里已经快接近尾声了，总结一下，我们通过搭建服务将gitlab和jenkins做了连接，同时提供管理端来统一处理任务。
- 作为开发者只关注自己的开发任务，代码质量等，摆脱了以往全过程参与的状况。
- 作为项目管理者，简化发布流程，不需要手动打包，将目光转移到代码质量、业务实现上。
- 作为构建服务,凡是能让我去解决的都不应该让开发者或者管理者去处理
最后的最后再给大家分享点我自己踩的坑
-
1.jenkins创建任务时如何获取创建对应的xml？
答：访问http://localhost:8080/jenkins任务名称/config.xml你就明白了，前提你要搭建好jenkins。
-
2.jenkins api都有哪些，具体该怎么使用？
答：推荐使用node-jenkins-api
-
3.gitlab api使用要注意什么？
答：首先你要确认自己的gitlab版本，然后确认调用v3还是v4的api，二者是有区别的。其次你要注意gitlab的验证，其实也不难，主要创建一个Private token然后配置在你的header中就可以了
