需不需要一个独立的部署系统是很多企业用户在构建持续交付流程中经常困惑的一个问题。也经常有用户会问我们，现在已经有Jenkins，它自身提供了丰富的部署插件（如WebSphere部署插件、Tomcat部署插件等），方便用户直接把构建出来的部署包自动化部署到指定机器（甚至云服务）。那为什么不可以围绕Jenkins，集成一系列部署流程，从而不需要额外搭建一个独立的部署系统？

注：本文以Jenkins为例来说明独立部署系统的重要性。但持续构建工具不仅仅限制于Jenkins，还包括如BuildForge、TeamCity、CruiseControl等，而它们和独立部署系统的关系与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部署插件要做的那些事情）。如下图所示，部署系统需要连接项目中涉及的人、环境、制品库以及构建环境等，只不过这种连接的目的是打通从制品到最终服务的整个流程（即本文之前持续交付流程中的第二及第三阶段）

（徐桂林原创）

需不需要一个独立的部署系统是很多企业用户在构建持续交付流程中经常困惑的一个问题。也经常有用户会问我们，现在已经有Jenkins，它自身提供了丰富的部署插件（如WebSphere部署插件、Tomcat部署插件等），方便用户直接把构建出来的部署包自动化部署到指定机器（甚至云服务）。那为什么不可以围绕Jenkins，集成一系列部署流程，从而不需要额外搭建一个独立的部署系统？

注：本文以Jenkins为例来说明独立部署系统的重要性。但持续构建工具不仅仅限制于Jenkins，还包括如BuildForge、TeamCity、CruiseControl等，而它们和独立部署系统的关系与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部署插件要做的那些事情）。如下图所示，部署系统需要连接项目中涉及的人、环境、制品库以及构建环境等，只不过这种连接的目的是打通从制品到最终服务的整个流程（即本文之前持续交付流程中的第二及第三阶段）

（徐桂林原创）