1. 背景
在企业内部大家几乎都是在使用gitlab来保存、自动化部署项目，也青睐于将一个团队的关联性高的项目都放到一个仓库下。与此同时，也会将项目的编译、测试、构建、发布都分别聚合在一个job中去做。初期项目只有2、3个的时候，还看不出来太大的变化，多等几十秒对于大家来说也无所谓。随着业务的发展项目会越来越多，在同一个工程下面我们也会构建出越来越多的子项目来。子项目膨胀到10、20个时候，你会发现每个job的执行时间都变的非常的长，当你想要发布一下项目看下效果的时候，你需要苦苦等待劲40分钟，才能完全构建完成。引用一句学习python时候，经常看到的话，”人生苦短，我用python“。是的，太慢了。
2. 项目太多构建速度太慢如何解决？
2.1 项目依然包含多个子项目
我们依然遵循了将所有的子项目都放到了一个工程下面。虽然这样我们在本地全量编译的时候，依然很慢。但是他有一点好处就是，所有的项目都聚合在一起，维护起来非常方便。毕竟IntelliJ可以帮我们做增加编译，所以，在平时开发上影响并不大。
当然了，随着微服务架构在企业的推广率越来越高，项目被切成了巨量的小项目，一个项目中维护着少量的子项目，可以让这个项目在任何环节都非常快。
2.2 gitlab-ci文件的修改
将每个job都切分成子项目数量的job，并保证各个子项目的构建过程互不影响，当我想要发布其中某个项目的时候，只需要执行该项目的pipeline流程就行了，并不需要关注其他子项目的pipeline流程。
这样，我们又可以快速的发布其中某个项目啦。
我们将这些子项目都聚拢在一个项目中的好处是，当我们需要全量发布项目的时候，我们可以轻松的发布掉他们。当然，在微服务体系下，也没这个需求:(
3. 项目需要很多下载很多依赖，但是这些依赖的下载过程过于漫长，并且有的不在兼容，如何解决？
3.1 例子: python2.7
python2.7已经不再维护，但是依赖链中却有很多在不断升级版本，并且不再兼容2.7
3.1.1 解决方案
- 将所有的依赖下载好环境构建好后，将这个环境打入一个
docker image中，并上传到镜像仓库，命名为Base-xxx。 - 项目的本身的
Dockerfile直接依赖Base-xxx
3.1.2 如果需要添加新的依赖怎么办？
方案一：重新构建Base-xxx镜像，并上传至镜像仓库（过程中，可以要解决依赖链上的不兼容问题）
方案二：基于Base-xxx镜像，构建一个新的镜像来拉取额外的这个依赖，并且将额外的依赖打入一个新的镜像中名为Base-V2-xxx（这种看起来比较恶心，但是可以避免处理原始依赖链上的不兼容问题）
