自动构建系统是从美团的自动部署系统发展出来的一个新功能。每当开发人员提交代码到仓库后，系统会自动根据开发人员定制的构建配置，启动新的Docker容器，在其中对源代码进行构建（build），包括编译（如Java、C++和Go）、预处理（如Javascript和CSS）、压缩（如图片）等操作，生成最终需要上线的程序包。
美团的代码发布系统有中央控制节点，负责代码的拉取、应用的构建和上传等任务。随着业务的迅速增长，应用发布项的数目和单个发布项的服务器数量也随之增长，中控节点的任务加重，几个问题也变得亟待解决：
- 不同应用的构建环境在同一个虚拟机上，需要解决环境冲突和隔离的问题
- 多个应用同时构建会竞争发布机的CPU和IO资源，让构建变慢
- 应用的构建脚本运行在公共发布机上，脚本的bug可能会影响到发布机的正常运行
例如某次主站（PHP）的发布速度非常慢，调查后发现当时某些Java应用正在编译，占用了大量CPU资源，导致其它应用的发布变慢。
为解决上述问题，我们设计了把应用的构建过程从中央发布机分离出来的方案，并利用Docker作为构建的基础环境。关于Docker的介绍，可以参考《Docker系列之一：入门介绍》这篇文章。
首先，开发人员在Stash上配置自动构建，之后的代码提交就会通知自动构建系统。自动构建系统收到通知，找到所有配置了该仓库的发布项，生成构建任务，并把这些任务提交到Django-rq队列。任务的主要配置是YAML格式的自动构建配置文件，该文件类似Dockerfile，但是为了使用方便，只支持少量的关键字，因此比Dockerfile使用更简单。通过该配置文件可指定构建容器使用的镜像，一些环境变量，以及构建命令等。系统从私有的Docker registry获取镜像，并根据YAML配置生成Docker容器，在此容器中完成构建。
从Stash触发自动构建的功能，是从这个项目修改实现的，只需简单配置即可启用自动构建。 
构建成功的结果会自动上传到美团存储服务（Meituan Storage Service）。当发布人员发布时，就直接从MSS拉取构建好的应用包进行发布，省去了在发布时才进行的编译环节。
为什么用Docker？
为了达到隔离构建环境的目的，应用的构建可以在分别的美团云虚拟机上实现。但是，应用构建有一些特点让Docker在此场景更合适。首先，构建环境都是临时的，每次构建结束后就销毁（也可选择保留）。而我们内部使用的美团云虚拟机是和运维用的配置管理数据库（Configuration Management Database）关联的，新虚拟机会自动部署一些基础环境、监控报警项等，并注册进CMDB，而这些东西对自动构建的系统是多余的。第二，自动构建的系统启停频繁，Docker这样的轻量级容器可以更好地满足快速生成和销毁的需求。因此，自动构建系统是在美团云虚拟机里面运行的Docker容器中进行的。
自动构建很好地解决了文章开头提到的发布系统的三个问题：
- 自动隔离不同应用的构建环境，无需担忧环境冲突的问题
- 不同应用的构建容器不必运行在同一台虚拟机，可以分布在多虚拟机的集群上，避免了构建之间的资源竞争，让构建过程更加迅速
- 任一应用构建的错误不会影响其它应用的构建或者中央发布机的运行
此外，自动构建还有如下两个好处。
首先，预先的主动构建把冗长的构建时间从发布过程省去，让发布人员在发布时耗时更短，既让发布更敏捷迅速，又提升了用户体验。美团在工作日每天的代码发布要上千次，快速的发布过程才能更好地保证业务的迭代过程。
其次，自动构建让构建环境的定制更方便。原来在发布机上构建时，如果需要的依赖在发布机上还没有，就需要给运维人员提需求来进行配置，这个过程不够敏捷。使用自动构建后，开发人员可自行在YAML格式的配置文件指定构建环境。前端开发人员的构建环境往往比较新，需要频繁改变环境，因此支持自定义依赖的自动构建系统受到了前端开发人员的欢迎。
自动构建目前是发布项配置里面的一个可选项，这保持了和原有系统的兼容。自动构建是美团在线上业务中首次使用Docker。我们会持续推进该特性在自动部署系统的使用，最终成为所有发布项的默认配置。
自动构建使用Docker的方式，为我们后续更广泛地使用Docker提供了启发。
第一，将Docker用于开发环境。通过Dockerfile描述测试环境，并维护起测试环境的Docker镜像，可以让开发人员快速搭起来一个统一的开发环境；再结合Vagrant，可以很好地解决研发团队中普遍存在的测试环境搭建麻烦的问题。
第二，将Docker用于应用部署。完成自动构建后，容器中已经有了应用程序包，再加上运行时依赖，即可让这个容器直接提供服务。
未来可以在应用的开发测试，编译构建，和部署运行等三个环节，都使用Docker容器。关于Docker在上述场景的应用，请关注我们博客的后续更新。
架构和设计)