与任何持续集成和持续部署平台一样,速度对于开发人员效率至关重要。
GitLab.com 提供共享的Runner程序供每个存储库使用,虽然这对于快速开始来说是很棒的,但我们发现最大的单项速度提升来自接待我们自己的Runner。对我们来说,瓶颈实际上不是CPU或RAM,而是网络。在私有云服务器上,网络速度大大提高。网络速度对于构建和部署尤其重要。构建通常需要下载库,依赖项,Docker映像等,而部署则需要将资源上传到其他位置。当网络挤满了GitLab的共享Runner时,这些阶段就会很慢。
构建依赖存储在本地内网私有仓库中比在internet中获取有很大的速度提升,如果每次运行CI作业时都安装依赖项,那是在浪费时间。相反,您应该将Docker映像用于已经安装了所有必需依赖项的CI作业。构建缓存可以使用pipeline语法 cache进行保存,也可以使用全局的缓存。
尽可能使用小型Linux发行版映像来运行CI作业。Alpine Linux可能是最受欢迎的选择,但还有其他选择。为什么?可以想象一下,如果使用Ubuntu这样的庞大发行版来运行一些测试或执行一些构建命令,可能是Alpine 30到40倍大的图像,下载时间就会很长些。当然我们也可以修改runner下载镜像的策略,例如我们提前将镜像下载到本地并配置runner的镜像下载策略为“本地不存在则远程获取”。
仅在文件发生变化时运行作业,为了节省时间,请考虑通过将only:changes
来有条件地运行作业。只需列出需要更改以运行作业所需的目录/文件。确保列出所有可能影响工作的内容,包括共享依赖项。请查看以下示例:
test-example1:
script:
- yarn --cwd apps/example1/ test
only:
changes:
- apps/example1/**/*
- shared-dependencies/**/*
test-example2:
script:
- yarn --cwd apps/example2/ test
only:
changes:
- apps/example2/**/*
- shared-dependencies/**/*