jenkins部署流程图_日部署 6000 次！携程持续交付与构建平台实践之路

作者简介

周光明

携程旅行网

高级技术经理

我的演讲主题是《携程持续交付与构建平台实践》。

首先看一下携程目前持续交付的简介。我们现在有 8000 多个应用，整体研发人员大概有 3000 多位，每天在各个环境上部署的次数有 6000 多次，因此持续交付对于我们来说是一个非常重要的能力。

1. 携程持续交付简介

我们先看一下持续交付对于我们的意义，首先是效率的提升，我们知道部署是一个很麻烦的事情，如果说你有多个环境需要部署，那部署的难度也会直线上升。而这个时候如果我们有一个工具去做这样的事情，研发人员就可以将更多的精力投入到研发它的功能上面，让产品的迭代更加迅速。

第二是质量保障，我们在持续交付的过程中穿插了一些代码扫描、单测或者集成测试的过程，可以让整个产品的质量在交付过程中得到很好的保障，也可以让我们在交付的时候更加有信心。

第三是安全可靠，如果没有这个机器就要人工跑上去进行部署，就会对线上系统增加很多误操作的隐患。如果大家知道的话，携程之前也是有过一段非常惨痛的经历的，某个运维人员在线上的操作导致网站大面积的瘫痪，我们对这个印象是非常深刻的。

第四是团队协作，在传统交付模型从产品讨论到上线需要经过很长时间，有可能出现一个现象，在开发阶段的时候开发人员可能在闷头写代码、测试人员没有什么事情做，到了测算阶段这个现象又会反过来。如果我们采用小步快走的方式可以让各个团队之间的协作更加紧密和紧凑。

最后是流程更加透明，因为我们使用的是统一的规范、统一的工具，在交付过程当中的每个细节都可以被暴露出来。不管谁多写一个 bug 或者少写一个单测都会被系统记录下来，作为后面的依据。

这是目前我们简单的交付流程，首先是研发人员 Push 代码，扫描单测集成测试，再将结果反馈，之后创建一个版本，版本是什么概念待会再说。

创建版本之后进行打包，再部署到测试环境，部署成功之后我们会同志周边的自动化测试平台或者性能平台，项目测试人员、QA根据测试结果进行审批工作，就可以将项目部署到下一个测试框架或者生产环境当中。

对于研发阶段来说，我们目前主要推崇的分支管理模型是 Master 分支和 Feature 分支，多个分支同时进行功能的开发，我们是将其可视化的。我们之所以这样做的原因，因为可以让代码的冲突在合并之前就暴露出来并提前解决。

如果这个时候线上有一些紧密的 bug 要修复，也可以通过 Master 提交一个代码，但是提交的代码也会被合并到之前创建的代码当中。

接下来解释一下刚才提到的版本概念，我们知道很多开源软件是使用Git Tags作为开源版本的，但是一个 Git Tags 可以快速找到准确的内容。如果一些项目比较复杂，可能会有一些其它代码的依赖。因此我们可以将源码打包成一个版本，打包的东西就会比使用Git Tags 更加准确。

但是有些代码依赖，不是一个特定版本号，可能是一个范围，上个月打包出来的结果和今天打包出来的结果就会不一致，如果这样就会被部署增加很多不稳定的因素。

第三点是在一些比较特殊的项目里面，除了语言依赖之外，还会有环境依赖。

以前容器没有出现之前，我们将环境依赖的过程写到项目原码的脚本，通过部署运行多个程序安装那些依赖。但是在有了容器之后，我们就可以将环境的依赖也作为版本的因素，容器就可以很好的帮我们解决这个问题。因此一个明确版本的概念，对于交付来说也是相当重要的。

下面介绍一下我们这些年的部署模型的演进。

在2015年之前我们使用虚拟机做单机多应用的部署。

对于运维来说成本相当高，在2015年的时候我们重新做了一个发布系统，也是主推单机单应用的部署模型。到了2016年我们开始研究容器，但是将容器作为一个虚拟机的方式，我们叫它“胖容器”，以这样的方式部署应用。

我们的整个部署过程，上面写的是一个生态环境的部署过程，总体来说还是有一些复杂的。因此我将几个比较关键的概念整理出来。

• 首先是Group，一组