作者介绍：

王映红：第五空间学习中心DevOps Master学员代表，专注于软件质量及过程改进的咨询师和技术顾问，超过20年的IT行业经验。是PMI组织认定的PMPer，国家信息系统项目管理师，TMMi Professional专家，持有ISTQB AM，Scrum敏捷教练CSP、CSM、CSD等认证，熟悉PMBOK、TMMi、TPS、DevOps、Scrum、Agile、Lean、ITSM、ITIL、COBIT、CMMI等领域知识。。

在DevOps中，你可能经常会听到类似这样的一些话：

功能还没集成进来。

功能还没部署上去。

功能还没交付。

功能还没上线。

功能还没发布。

请问，以上“集成”、“部署”、 “交付”、“上线”、“发布”这几个概念，表达的是同一个意思吗？如果不是，它们有什么区别呢？

我相信大多数人都会为此而迷茫，本人也常常被这几个术语搞晕。

也许你会说，上面的例子太简单，难于判断。好吧，下面再给你一些更多的例子（均来自DOM【DevOps Master，简称DOM】认证课程的权威教材）：

还要再花几天才能把这个新版本发布到UAT环境中。

上次发布新版本到生产环境时，你花掉了整个周末的时间。

一行代码的改动需要花多长时间才能部署上线。

每次提交代码都可能产生一个可发布的版本。

很多公司都会在一天内发布很多次。

遵循极限编程的座右铭：如果它令你很受伤，那么就做更多的练习（If it hurts, do it more often）。合乎逻辑的极限就是每当有版本通过自动化测试之后，就将其部署到生产环境中。这种技术叫做“持续部署”，Timothy Fitz发明的一个术语。

持续交付指的是应用程序的构建、部署、测试和发布的自动化流程。

由良好的金丝雀发布系统提供的这层安全网让持续部署的风险甚至更小。

有些人反对持续部署，在直觉上，这么做的风险太高。但如前所述，越频繁的发布会让发布风险越低。

根据我们的经验，做这件事的最佳方法就是尽可能频繁地发布（即持续交付)。

持续交付目标是让应用程序保持在可发布状态。

对于组织来说，持续交付不仅仅是一种部署方法。

现在，你是否能区分开“集成”、“部署”、“交付”、“上线”、“发布”这几个概念了呢？

一头雾水！对，至少我自己仍然还不明白它们的区别。为此，我查阅了一些资料，但仍然不得解。网上的各种文章里有各种不同的解释，但要么是局限在特定的上下文环境中，要么是混淆使用，总是经不起推敲。

造成以上的混乱，我觉得可能是缺少对上述术语的标准定义和准确的描述。

怎样才能不被“绕晕”？我在不断的思考，也与一些同行探讨过，甚至曾经尝试使用表格的方式，从这几个术语所代表的活动操作执行者、执行时间、执行对象、执行环境、执行方法/方式、产出物、接收者（受众）等多个维度进行对比和区别，但最后又成功的把自己“绕”晕了。

在第五空间学习中心的DevOps Master课堂上，受许峰老师关于DoD（Done of Definition，简称DoD，指完成的定义）的启发，我觉得这些术语都代表了一种活动，活动之间会存在某种联系或依赖，所以下面尝试从DoD的角度（用下游的活动来确认上游活动是否真正完成）来解释和区分下这些术语。

集成（Integrate）

定义：将组成部分（部件）收集、归拢，并建立它们之间的联系或依赖关系，构建形成一个整体。

DoD：通过验证（验收）测试，确认集成的结果是正确的。

说明：为了验证集成的结果是正确的，需要对它（集成的结果）进行验证（验收）测试，而为了做验证（验收），需要将它（集成的结果）部署到一个环境中。但验证（验收）测试、部署，这些活动并不是集成，它们只是为了验证集成达到了期望的结果。如果你能保证集成没有问题，那么可以不做部署和验收测试这2个动作。

特征：将分散的东西合并到一起，形成一个整体。

举例：多个单元代码通过集成，形成一个组件。多个组件或模块通过集成，形成一个系统。多个系统通过集成，形成一个整体解决方案。

部署（Deploy）

定义：安装、配置（如有）。

DoD：通过验证（验收）测试，确认部署的结果是正确的（成功部署）。

说明：为了验证部署的结果是正确的，需要对它（部署的结果）进行验证（验收）测试。但验证（验收）测试并不是部署，它只是为了验证部署达到了期望的结果。如果你能保证部署没有问题，那么可以不做验收测试这个动作。

特征：将软件“放置”到某个环境中。

举例：部署人员将测试版本部署测试环境。将某个版本部署到试运行环境。将正式版本部署到生产环境。将一个模块部署到系统中。

交付（Delivery）

定义：交给、付出、移交，指物（如软件安装包的光盘）或权（软件的管理权、使用权、所有权等）在人与人之间的转移、传递或接管。

DoD：接收方确认收到（如签收、同意）。

说明：接收方可能会对收到的物或权进行验收测试，然后才签收。但验收测试、签收并不是交付，它只是为了验证交付的东西是期望的东西，它们是交付的下游动作。如果能保证交付物没有问题，那么可以不做验收测试、签收这样的动作。

特征：交付物或权的拥有者发生了“转移”。

举例：开发人员将测试版本交付給了测试人员。测试人员将正式版本交付给了运维人员。测试人员错误的将测试版本交付给了运维人员。IT团队将系统交付给了业务部。某公司将软件产品交付给了零售商。商店将软件光盘交付给了用户。这次只交付了一个模块。

上线（Go-live / Ship）

定义：上到生成线，即部署到生产线上（生成环境中）

DoD：在生产环境中可以看到，并可以使用。

说明：上线后，可以使用系统，也可以不使用系统。如果使用系统，开始创造业务价值，那么也叫投产（即投产=上线+使用系统）。如果上线后，不使用系统，那么表示系统还没有“开工”，它并不影响上线这个动作。“使用系统”这个动作是上线后的下游活动，它不是“上线”活动的一部分。

特征：一定是部署到生成环境中（不是其它环境），即生产线上。上线 = 在生产环境上的部署。

举例：IT部门上线了一个演示版。正式版刚刚上线，还没有用户访问。某系统上线了半年，还没有投产，某系统刚上线1个月，公司业绩就得到了大幅提升。

发布（Release）

定义：将集成（构建）出来那个整体（发布对象），打上一个发布标签，提供出来，受众可以获得。

DoD：提供出来，受众可以获取到。

说明：发布的版本未必是正式版，比如发布测试版（如Beta版）、试用版、演示版。发布之后，受众可以获得软件，但不一定就使用它。发布的软件可以存储在VCS（版本控制系统）中或制品库中，也可以存储在光盘等介质上。受众获得软件之后的下游动作，不一定是部署，也可能是其他动作（如交付或其他）。如：

发布测试版-->部署到测试环境-->交付给测试人员做验收测试。

发布正式版-->部署到生产环境-->交付给用户使用。

发布正式版产品（如windows安装盘）-->（售卖）交付给用户 --> 部署 -->上线使用。

特征：发布物有（标签）标识，提供出来可以获得。

举例：开发人员发布了一个测试版。开发团队在每个月都会发布一个演化版。某产品发布了新的版本，用户需要重新购买后，才能部署升级。某云平台发布了新的版本，不需要用户部署就可以使用新的功能。本次版本发布了，但没有人使用。

按照以上的定义，那么开头的那段话，就可以这样来解读，做出区分：

功能还没集成进来 --> 功能还没有被合并到一起，没有形成一个整体。

功能还没部署上去 --> 功能还没有安装、配置到指定的环境中。

功能还没交付 --> 功能还没有“转移”给使用者。

功能还没上线 --> 功能还没有部署在生成环境。

功能还没发布 --> 功能还没有提供出来，不可以获得。

至于它们的依赖关系，即谁先谁后，除了集成是首先要完成的，其它几个活动没有固定的依赖关系，它们的先后顺序需要根据具体的应用场景，例如：

场景1

某乙方公司为甲方公司开发了一个web应用，需部署到生产环境，再发布给甲方公司，交付给使用部门（用户），使用部门才能投产使用（上线），那么它们的先后顺序就是：

集成—>部署—>发布—>交付—>上线。

场景2

A公司开发了一个商用软件，发布到网上，B公司通过购买获得，由A或B公司的技术员将软件部署到B公司的生产环境，交给B公司的使用部门（用户），使用部门才能投产使用（即上线），那么它们的先后顺序就是：

集成—>发布—>部署—>交付—>上线。

场景3

早年，微软发布了Window XP（存储在光盘中），交付给用户，用户再部署到生产环境，然后投产使用（上线）。现在的很多单体软件，大多也是这样的流程。那么它们的先后顺序就是：

集成—>发布—>交付—>部署—>上线。

场景4

A公司开发了一个SaaS应用，部署到生产环境，交付给B公司，B公司再加入自己公司的基础数据后上线了该SaaS应用，发布给使用部门（用户）使用，那么它们的先后顺序就是：

集成—>部署—>交付—>上线—>发布。

还有更多场景，就不列举了。

通过以上分析，你对“集成”、“部署”、“上线”、“交付”、“发布”的概念的理解是否清晰了？如果还不清晰，请再读一遍。

*感谢：

最后，要对第五空间和许峰老师表示感谢。平时，在阅读DevOps相关书籍和工作中应用时，这几个概念常常混淆在一起，难于解释清楚（容易引起歧义），确实很头大，这种感觉很不好，但又总是“萦绕”在脑中，困扰着我。最近反复思考，上完DOM课程，从DoD的角度来考虑，才感觉清晰起来。为此，特别感谢第五空间！感谢许峰老师！