本文共 2575 字,大约阅读时间需要 8 分钟。
1年前入职时,公司前端部门的静态代码部署都是用ftp工具拖拽部署,没有记录,没有关联,经常造成许多困扰的问题,
比如:今天有没有其他人在我要部署的路径上工作?我的代码为啥被盖掉了?被谁盖掉的?啥时候盖掉的?
本地build,ftp拖拽部署这种方式,导致git版本与手动的构建、部署没啥关联,更有在本地写完代码部署上去后,压根没传git这种失误可能发生。
靠人去遵守规范来控制工作流,总会有失误、疏忽的发生。
要靠机器和代码去规范工作流,提高效率、准确性,实现真正的前端工程化。
不讨论通用模板(项目开发层面),只关心构建以后的事情,精确的说,就是从npm run build:xxx 这个脚本开始对接,npm run build:xxx之前的事情不在本文讨论范围内。 实现构建-部署-测试(多个环境)-沙箱-上线(可回滚)的全部半自动化流程把控。
为什么选择jenkins:优先选择强大的开源工具,避免重复造轮子,主要原因是插件特别丰富,基本可以满足所有实际需求
先把成果贴上来,整体示意图
核心思想是分离构建、部署,所以每个项目,jenkins会建两个job。
jenkins服务部署在公司内网堡垒机上,使用tomcat管理jenkins的war包,占用系统服务、全量部署定时任务都跑在同一台堡垒机上(Linux)。
因为内容很多,所以我直接采用一张图 + 注释 来零碎的讲解每个功能的实现,因为每个公司的前端业务环境都不一样,所以我也不打算花太大的笔墨去描述所有的实现。写这篇文章的目的就是可能某个思想、某一段对jenkins插件的使用等等会帮助到有类似需求的人。注释会是截图,或者是关键代码,对应图中的数字。
先放几张实际使用的图
jenkins项目界面部分截图
构建job部分截图
部署job部分截图(使用jenkins-pipeline实现流程图)
多套测试环境占用系统部分截图(占用环境后别人无法部署,全量脚本也不会覆盖)
全量部署脚本日志展示部分截图
整体示意图的注释(每一条都对应示意图中的红色阿拉伯数字):
4. 下图展示了部署job可操作的选项
check_results=`git log $branchName..origin/master`if [[ ! $check_results = "" ]] then echo "【Error】:当前代码比master落后,需要合并master或更新代码重新打包之后才能进行构建!" exit 1 else echo "【info】:当前代码正常,可以部署!"fi复制代码
整篇文章比较零散,主要讲了一下我对前端工程化探索的思想和实践,因为手头的需求也很多(18年一起工作的好几个小伙伴被裁了,你猜他们剩下的工作谁来做),断断续续搞了两三个月,目前这套系统已经稳定运行几个月了,不断的完善使它现在很好用,线上再也不会出现因为忘了某些分支操作导致的bug;这套系统的优点就是,基于开源jenkins+核心思想,就可以很快的通过node/shell/pipelinescript搭建起一套完整的系统,成本极低!超级实用的功能却实现很多!
如果你觉得读完没啥收获或我写的实在不知所云,那就好好看看说明12,我觉得把这一个小技巧分享出去,并且让你有所收获,那也值了,毕竟写作能力有限~
作者:Terry豆 链接:https://juejin.im/post/5c6d096551882562d17d9a2e 来源:掘金 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。