之前看了社区论坛里一位大佬的关于 docker 的帖子，里面提到可以用 docker 解决代码打包部署时因为编译项目多导致很慢的问题。但是里面没具体说到是怎样实施的。所以发个帖子向各位请教下，看本人这样做是否可行。
举个例子：我公司开发语言是 go，项目里有 30 个微服务，每次更新测试环境，都是先 git checkout branch，再 git pull 下代码，然后 make 编译这些服务，再 reload 所有服务，至此环境更新好。
但是每次最慢的就是在 make 这 30 个服务，要花个 2,3 分钟。我是觉得很慢的。所以打算弄个镜像，里面包含 go 语言环境，和测试环境一样的环境变量，及 git 服务。
1.根据镜像起 10 个容器，容器占用内存不需要很大，因为我只需要在容器内编译服务，不启动服务，所以不要很大内存。每个容器指定只编译其中 3 个服务，然后挂载到测试环境的 build 目录中。
2.测试环境写个脚本，每次更新代码时，都是同时执行这 10 个容器内的脚本，这样原来需要花 3*60=180s 的编译时间，现在缩短了十分之一，只需要 18s。
3.挂载到测试环境后，就 reload 下服务，测试环境更新完成。
疑惑点：
一个宿主机内起 10 个容器，在执行脚本，让 10 个容器并行编译服务，是否真的能做到 “并行”？因为假设宿主机是 4 核 8g 的配置，那么最多也只能并行 4 个容器编译吧.
每次部署都需要更新所有服务？如果是这样 可能要考量一下服务设计是否合理了 依赖过多？
AngryTester
回复
因为每次更新，都是因为其中 7,8 个服务的代码有新提交。如果只单独更新这些有变动的服务，那就需要 make server1；make server2；一个个对照变动的服务手动编译。还不如先 make clean 掉所有之前编译的，再 make all 编译所有的服务，来的便捷。
另外就是，其实我就是想知道别的公司，当需要编译部署很大量的服务很耗费时间时，通过这种多容器部署是否能缩短编译时间，以及其它公司是否是通过这样操作的
黑山老妖
回复
对代码编译这种耗 CPU，又耗内存的，在单台物理机上并行并没有太大作用，并行处理只对 IO 密集型有很好的效果。
你的这种需求唯一的办法就是用多台物理机 Agent，一起编译。
arrow
回复
有 2 点疑问。
1.在 linux 宿主机里起 10 个 docker 虚拟机，忽略内存和 cpu 不足，编译时效果是否等同于 10 台物理机？
2.假设宿主机配置很差不是配置是 2 核 4 线程，能够做到并行 4，但 10 个并发也能缩短不少时间吧
黑山老妖
回复
感觉你对 docker 理解有误，docker 最大的作用是资源隔离，管理；你开 10 个 docker，和你开 10 个编译进程是一样的效果，在这里 docker 可以说没有任何作用。
一般来说都是用多个 agent，每个 agent 上同时编译的项目都是有限制的（2-4 个，看配置 ）。
你的这种情况，最好是能分开编译，一次就只编译一个你需要的服务，可以通过写一些脚本，来判断每次 git push 的时候的改编有哪些，然后正对性的编译。推荐你用 gitlab-ci 或者 drone 来试试。还有就是 go 的持续集成其实可以参考之前 b 站不小心开源的，里面有个 rider，就是专门编译 go 的