有了Jenkins,为啥还需要一个独立的部署系统?

2016/01/26 - 上海 by 徐桂林

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

注:本文以Jenkins为例来说明独立部署系统的重要性。但持续构建工具不仅仅限制于Jenkins,还包括如BuildForge、TeamCity、CruiseControl等,而它们和独立部署系统的关系与Jenkins基本都一致。

持续交付与部署系统

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

服务流程

从上图中可以看出,从开发人员写下代码到服务最终用户是一个漫长过程,整体可以分成三个阶段:

如果从持续交付角度看,其最核心诉求就是要让上图三个阶段能够无缝连接并自动化运行起来,从而达到持续交付的两个核心目标:提高交付频率(部署次数)和降低部署延时(从代码提交到上线的时间差)。

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

参照如上持续交付的流程,可以发现持续交付对于一个部署系统的要求绝对不仅仅是一个自动化的部署过程,这也是在有了Jenkins和其相关部署插件后仍然需要搭建独立部署系统的原因所在。具体来说,我们可以从下面几点分析:

当然,除了上面列出的这些原因外,独立部署系统还有其他一些优势(如方便部署版本管理等),这里就不一一列举。通过如上分析,我希望大家对于一个独立部署系统的优势以及它需要包含的内容能有一个整体理解。当然,你可能会说“我正在按照上面的这些要求、基于Jenkins做自己的部署流程”。如果真是这样,那恭喜你!其实你已经走在构建一个独立部署系统的路上,而它和Jenkins的关系其实已经不大,或许你还可以考虑把这套系统对接其他构建系统(如CruiseControl、TeamCity等)。

写在最后

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

部署系统生态

为此,FIT2CLOUD产品提供了独立的“代码部署”模块,并在产品内部完成了对于环境、用户、制品仓库以及构建系统的对接,满足客户对一个独立部署系统所需要的各个方面功能。如果您对于FIT2CLOUD内的部署功能感兴趣,欢迎随时试用我们的产品(www.fit2cloud.com)或者联系我们(support@fit2cloud.com)。