自动构建系统是从美团的自动部署系统发展出来的一个新功能。每当开发人员提交代码到仓库后，系统会自动根据开发人员定制的构建配置，启动新的Docker容器，在其中对源代码进行构建（build），包括编译（如Java、C++和Go）、预处理（如JavaScript和CSS）、压缩（如图片）等操作，生成最终需要上线的程序包。
背景和问题
美团的代码自动部署系统承载着美团所有业务的代码上线工作。代码部署系统一开始基于简单的Bash脚本，从一个中央主机上通过Rsync和SSH进行文件传输和命令执行。
图1 代码部署系统架构图
代码发布系统经过多番演进，增加了很多功能，但原来的中心式架构仍然保留了下来，见图1。发布者通过Web界面或者REST API控制中控机，中控机负责从Git服务拉取代码，构建应用程序包，然后通过Rsync上传程序包到应用集群，并用SSH执行远程命令。
自动部署系统为美团业务的快速发展提供了有力的支撑。由于我们采用了开发人员自助上线的方式，发布操作频繁，工作日每日上线达上千次。图2是过去15个月每个月的发布次数。为了持续优化发布速度，给发布人员提供良好的体验，我们把单次发布平均时间作为发布系统的一项重要的KPI。
然而，随着美团业务的迅速扩张，服务增多，发布应用数目也增多，中心化的架构的问题也凸显了出来。
问题1：资源竞争多个构建任务同时进行，竞争中控机的资源，影响发布速度。有一次一个应用受到同时进行的某Java类应用发布的影响，通常两分钟的发布变成了十多分钟，严重影响发布体验。如果出现事故需要回滚，就是更严重的问题了。
问题2：环境冲突不同应用的构建依赖环境在一台发布机上，需要考虑环境冲突和隔离的问题。例如，Java 1.6/1.7共存，应用需要通过JAVA_HOME变量指定使用的Java版本，Maven 2/3也存在同样的问题。npm的global包也需要兼容多个应用的构建。
问题3：安全隐患应用的构建脚本运行在公共发布机上，脚本的Bug可能会影响到发布机的正常运行。例如某次一个构建脚本里面的sudo service nginx reload命令，本应是在应用服务器上执行的，但开发人员错误配置到了在发布机上执行的构建脚本里面。
解决方案
解决上述三个问题，我们首先想到的方案自然是重构为多台中控机的可横向扩展的方式。但由于某些应用的特殊性，改动比较麻烦，所以开始并没有走这个方向（现在已实现多中控机）。
那么另外一个思路：能不能把构建过程从中控机分离出来？这个思路受到了Travis CI（https://travis-ci.org）的启发。我们借鉴Travis CI，在代码提交时自动在一个新的环境中触发应用的构建。
因此，我们的解决方案可以概括为如下三点：
把构建过程放到Docker容器；提交代码时自动触发构建；发布时直接使用构建好的应用包。