有了Jenkins，为什么还需要一个独立的部署系统？在此之前，他曾就职于意法半导体、欧特克和阿里云。许桂林热衷于云计算（尤其是公有云IaaS平台）。拥有多年AWS生产环境工作经验。是较早在国内分享AWS实战经验的作者之一。 是否需要独立的部署系统，是很多企业用户在构建持续交付流程时经常混淆的问题。经常有用户问我们，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.获取部署运行数据 部署是一个团队从代码到服务的关键路径，所有这方面的运行数据都值得记录，用于各种运营支持（包括安全审计、部署记录查询、部署频率、故障率分析等），ETC。）。当然，这些数据也可以基于Jenkins直接部署获取，但是在独立部署系统中获取会更加灵活方便。 6。让部署操作服务化 前面说过，部署不仅仅是开发人员和测试人员需要的。我们要努力做到部署服务化，让团队中的任何人都可以随时触发部署。Jenkins的操作界面对于开发人员或者测试人员来说可能更方便，但是对于其他人来说就太复杂了（而且对部署操作不友好）。自主部署系统在这方面可以做得更好，帮助更多人以低门槛完成部署操作。 当然，除了上面列举的原因，独立部署系统还有其他优点（比如部署版本管理方便等），这里就不一一列举了。通过上面的分析，希望大家能够对独立部署系统的优势和需要包含的内容有一个整体的认识。 当然，你可能会说“我是按照上面的要求，基于Jenkins做自己的部署过程”。如果是这样，恭喜！其实你已经走在搭建独立部署系统的路上了，和Jenkins关系不大。或许你也可以考虑将这个系统连接到其他构建系统（比如CruiseControl、TeamCity等）。 写在最后 前面说了，一个独立的部署系统需要包含很多内容（绝对不仅仅是Jenkins部署插件需要做的那些事情）。如下图所示，部署系统需要连接项目涉及的人员、环境、产品库、构建环境等，但这个连接的目的是打通整个流程从产品到最终服务（即本文之前的持续交付过程中的第二和第三阶段）。
