随着前端行业的不断发展,工程化对提高团队协作能力、开发效率以及降低维护成本都起着重要作用。自动化发布流程作为前端工程化的一部分,能够大大提高开发效率。
01
背景
微保C端主要是以微信小程序为主要技术平台,我们在小程序的研发上做了大量的摸索,以适应微保业务的发展。与此同时,H5页面作为微保小程序的补充,一直也在默默地生长。在H5保险平台发展初期,相关产品的发布流程主要靠各对口开发人员各自负责,类似于很多创业团队普遍做法。但保险是一个复杂的长链条业务,随着H5保险平台业务量增加和业务关联逻辑不断复杂,原有作坊式发布模式中存在的大量沟通成本已经开始制约我们的研发效率。H5平台工程化、自动化随之提上日程,并逐渐取得预期效果。本文将主要描述我们实际遇到的问题及我们的解决方案,以飨读者。
02
原有的发布流程
微保的前端开发工程师已经达到30多个人,线上在跑的项目也有40多个。原有作坊式的发布模式存在以下问题:
目录不规范:每个项目开发都按照自己的习惯去设立目录,为后面持续构建造成了障碍。
打包不统一:有的项目有编译,有的没有。没有编译的项目存在文件未压缩,图片未压缩等问题。
静态资源未上CDN:一些项目引用本地资源,同时也把它们放在Nginx机器上,这样会导致页面性能大打折扣。
如果项目需要线上体验,每次开发人员都需要手动把文件上传到对应的开发环境上,由于存在多套环境(DEV,SIT,UAT),导致过程特别繁琐。
每次发布,都需要人工收集H5项目包,再交给运维来安排发布。H5的项目多,再加上过程中会有代码变更,导致收集时间过长。
整个流程概览如下:
纵观全流程,其中主要的问题是(不统一的)人工发布流程带来的高成本,如果我们建立一套整体划一的自动化发布流程,将能减少绝大部分不必要的时间消耗。
03
构建自动化发布系统
为了解决上面提到的种种问题,团队意识到需要构建一个H5自动化发布系统。一个发布系统,怎么才算是合格,我认为它主要目的就要能够低成本地、准确地把代码部署到对应环境。
从下面三个纬度来思考规划:
自动化程度,决定了系统的效率。
健壮性,决定了系统的故障率。
可维护性,决定了系统的拓展性与维护成本。
04
如何实现自动化构建?
将代码检测、压缩、文件替换CDN链接、自动部署Nginx各种环境、静态资源存放CDN等操作流程自动化。
每次发布UAT,都会同步一个包到PRD,由开发者通过Tag选择最终测试通过的包发布。
通过自动化构建,减少了人力成本,出错的概率,从而得到研发效率上的提升。
05
如何保持系统的健壮性?
我们将该问题分解为三个小问题:
如何保持构建环境的稳定?
如何减少打包机压力,缩短打包时间?
发布出错,如何回滚?
通过对上面三个问题的解答,来进一步解决系统健壮性。
通过Jenkins来管理打包的策略,支持多个任务同时并发打包。
我们都知道node的依赖就是个“无底洞”,依赖包过大导致下载时间过长,且不稳定。
抽离依赖包,增量下载。首次打包项目时,把依赖包放在单独一个项目目录,后续的打包则判断上次的依赖包有没有更新变化,有则下载变化的依赖包,没有则继续沿用上次的依赖包,从而避免每次都全量下载,缩短时间。
每次构建UAT环境的项目,都会同步一个包到PRD用于发布,如果线上出现问题,发布系统可以选择回滚到上一个稳定版本。
06
如何让系统灵活可配?
为了支持前端开发过程的灵活性,我们支持统一打包和自定义打包两种方式。
对于普通的H5页面,统一采用Gulp打包,开发者可以不用关心。
同时又支持采用自定义的打包方案,开发者可以选择使用不同的打包方案去开发项目,比如:grunt,webpack 等。
这样就做到了普通项目可维护,自定义项目可拓展。
07
怎么做到的呢?
其实也不难实现,在H5项目中添加配置文件,告诉打包程序该跑哪个脚本命令即可,如:普通的h5项目,跑“gulp build”,执行默认的打包策略。自定义项目,则执行安装依赖包,“npm run build”,打包策略由开发者自己配置。
通过这两种模式的打包,去兼容更多的H5项目,减少了开发工作量的同时也照顾到了系统的灵活性。
08
小结
通过对整套开发流程的推广,目前已经有40多个项目迁移进来,规范了文件目录,统一了静态资源,方便管理。人肉收集包发布已经成为历史,团队的发版时间每次从3个小时,降低到了半个小时左右。
随着前端行业的不断发展,工程化对提高团队协作能力,开发效率以及降低维护成本都起着重要的作用。自动化发布流程作为前端工程化的一部分,能够大大提高开发效率。微保前端团队这块也算是补齐了其中一块能力,接下来,将会从打包效率,流程的便捷性,系统的稳定性去做进一步改进。
后台留言功能已开启,欢迎留言吐槽哦~
搜索公众号关注:微保技术
or
长按扫码可关注