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