阅读 235

前端自动化构建历程

做这件事的起因是因为公司处于高速发展阶段,前端的代码也在逐步从原来的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

bug

  • 其次就是一些业务上的检查了,这里就不做说明了。

到这里已经快接近尾声了,总结一下,我们通过搭建服务将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中就可以了

关注下面的标签,发现更多相似文章
评论