后端项目构建速度优化思路、gitlab-runner镜像构建详解
背景:
当前公司后端项目自动构建(gitlab-ci)使用的运行器(gitlab-runner)是使用docker方式执行ci脚本,整个流程是代码合并触发自动构建,运行期执行gitlab-ci.yml文件中的脚本。首先拉下来指定的image,然后启动这个镜像实例在里面执行ci脚本。整体流程如下图1所示:

这样做的弊端是每次触发ci都会使用一个新的docker容器,当maven构建jar包时因为本地没有依赖包每次都会去下载依赖,且当前runner所在环境上的maven没有配置镜像仓库,下载依赖速度很慢,这就导致构建的耗时久,进而拉低整个ci的效率。随着业务越来越多,打包速度也会越来越慢,因此需要优化下构建流程。
优化思路
解决此问题目前有三个思路
第一个思路是在原来gitlab-ci.tml文件里使用cache关键字加上缓存,缓存路径为容器里依赖存储的目录,缓存key为项目id+分支名,这样每次在容器内打包时就会使用上次构建使用的jar包,可以大幅加快构建速度,但流程上还是比较复杂。
第二个思路是继续使用docker方式执行ci脚本,但是在拉取的指定的image上下载好大部分的依赖,这样可以省去占比较大的下载依赖所消耗的时间。但此方法maven的打包耗时会与此镜像内依赖包的全面程度挂钩。
第三个思路是使用shell方式执行ci脚本。首先在基础镜像基础上构建一个有gitlab-runner、maven、gradle、java

本文介绍了如何通过优化gitlab-runner镜像来提升后端项目的构建速度。针对现有构建过程中下载依赖慢的问题,提出了三种优化思路,并详细阐述了使用shell执行ci脚本的方式,包括构建包含gitlab-runner、java、maven、gradle环境的镜像,以及实操步骤。优化后,构建时间从6分钟缩短到1分钟。
最低0.47元/天 解锁文章
1497

被折叠的 条评论
为什么被折叠?



