Jenkins系统+独立部署系统

原文出自：http://os.51cto.com/art/201601/504846.htm

有了Jenkins，为何还须要一个独立的部署系统？

如今已经有Jenkins，它自身提供了丰富的部署插件(如WebSphere部署插件、Tomcat部署插件等)，方便用户直接把构建出来的部署包自动化部署到指定机器(甚至云服务)。那为何不能够围绕Jenkins，集成一系列部署流程，从而不须要额外搭建一个独立的部署系统?

持续交付与部署系统

上面提出了一个很是好的问题，可是要回答这个问题，咱们须要从更大的视角(即持续交付)来理解一个部署系统须要扮演的角色，而不只仅从自动化部署过程这一点(尽管这一点也很是重要)来理解它。首先，让咱们看看软件生产中从代码到最终服务的典型流程(以下图)。

从上图中能够看出，从开发人员写下代码到服务最终用户是一个漫长过程，总体能够分红三个阶段：

1.从代码(Code)到制品库(Artifact)：这个阶段主要对开发人员的代码作持续构建并把构建产生的制品集中管理，是为部署系统准备输入内容的阶段。

2.从制品到可运行服务：这个阶段主要完成制品部署到指定环境，是部署系统的最基本工做内容。

3.从开发环境到最终生产环境：这个阶段主要完成一次变动在不一样环境的迁移，是部署系统上线最终服务的核心能力。

若是从持续交付角度看，其最核心诉求就是要让上图三个阶段可以无缝链接并自动化运行起来，从而达到持续交付的两个核心目标：提升交付频率(部署次数)和下降部署延时(从代码提交到上线的时间差)。

持续交付对部署系统的要求

参照如上持续交付的流程，能够发现持续交付对于一个部署系统的要求绝对不只仅是一个自动化的部署过程，这也是在有了Jenkins和其相关部署插件后仍然须要搭建独立部署系统的缘由所在。具体来讲，咱们能够从下面几点分析：

1.解耦构建和部署过程

尽管持续交付但愿自动化完成从代码到部署上线的整个流程。可是整个持续交付过程有多个不一样角色的人参与其中(开发、测试、运维甚至还有经理及市场人员)。其中，有些角色(如开发/测试)须要关心构建过程，而更多的角色(如运维等)绝大时候都是从制品开始部署工做。这也就要求构建和部署过程相互解耦，可以独立操做。

若是基于Jenkins直接触发部署，要直接绑定构建和部署过程。构建和部署这两个过程经过制品(Artifact，又称为部署包)链接(制品是构建过程的产出，同时是部署过程的输入)。若是它们相互解耦，天然就须要有统一的地方管理存储和管理这些制品，即统一制品库。

有了统一制品库后，构建过程自动提交产生的制品到此，而部署过程则主动到制品库拉取须要的制品进行部署，从而实现构建和部署的完整解耦。

2.管理复杂的部署环境

如前所述，服务上线须要涉及到不少不一样目的环境(开发、测试、预发、生产、演示等)。并且，在愈来愈多的云化基础设施中，环境内部的资源会频繁变化(例如，Auto-Scaling时刻都有可能添加或者减小你的云主机)。

这时候须要对部署流程隔离部署环境差别以及环境内频繁变化的基础设施。当须要执行一个部署时，操做人员只须要指定部署到哪一个环境(即环境名称或者ID号)，而不须要关心环境内部的任何信息。

由部署系统负责把部署请求分发到指定环境内的每台主机并自动执行。若是基于Jenkins来直接部署，则必然把环境管理的不少复杂度引入到部署流程内部。

3.支持多种部署策略

为保障服务的高可用，落实部署和发布的解耦以及其余业务须要，用户常须要支持如灰度发布、A/B测试发布等部署需求。一个独立的部署系统在此能够提供多种部署策略，并结合环境管理等其余功能知足业务上对部署和发布的各类需求。一样，Jenkins及其部署插件并无提供这样的能力。

4.落实部署流程规范

在一个公司内部常常有不一样的项目，使用不一样的编程语言，而部署流程也五花八门。从控制风险，减小重复操做，下降部署自动化难度等多重考量，公司都倾向制定一套标准的部署流程。

这时候，独立的部署系统就能够帮助用把这些规范落实下去并在平常的部署过程当中时刻校验(在软件工程领域，几乎全部的规范落实都得靠工具来助一臂之力，不然基本都会变成纸面上的规范而已)。

若是基于Jenkins来直接部署，如何落实这些部署规范仍然是一个很困难的事情，由于Jenkins及其部署插件并未对此提供任何实质性的支持。

5.获取部署运营数据

部署是一个团队从代码到服务的关键路径，这上面的全部操做数据都值得记录并用于各类运营支持(包括安全审计、部署记录查询、部署频率和失败率分析等等)。基于Jenkins直接部署固然也能够获取这些数据，可是把它作在独立的部署系统内会更灵活和方便。

6.让部署操做服务化

如以前提到，部署不只仅开发和测试人员须要，要努力让部署服务化，从而让团队内任何一我的均可以随时触发一次部署。Jenkins的操做界面对于开发或者测试人员可能还比较方便，可是对于其余人员来讲则过于复杂(并且对于部署操做也不友好)。独立部署系统能够在这方面作得更好，帮助更多的人低门槛完成部署操做。

固然，除了上面列出的这些缘由外，独立部署系统还有其余一些优点(如方便部署版本管理等)，这里就不一一列举。经过如上分析，我但愿你们对于一个独立部署系统的优点以及它须要包含的内容能有一个总体理解。

固然，你可能会说“我正在按照上面的这些要求、基于Jenkins作本身的部署流程”。若是真是这样，那恭喜你！其实你已经走在构建一个独立部署系统的路上，而它和Jenkins的关系其实已经不大，或许你还能够考虑把这套系统对接其余构建系统(如CruiseControl、TeamCity等)。

写在最后

如前所述，一个独立的部署系统须要包括的内容是很是丰富的(绝对不只仅是Jenkins部署插件要作的那些事情)。以下图所示，部署系统须要链接项目中涉及的人、环境、制品库以及构建环境等，只不过这种链接的目的是打通从制品到最终服务的整个流程(即本文以前持续交付流程中的第二及第三阶段)。