发布管理、部署管理、持续交付，这些概念在实际的运维落地中往往让大家很头疼，尤其是在有研发团队的IT组织中更是如此，发布、部署、交付到底管理的那一段呢？在实际的运维落地中我们该如何应用呢？今天我们就聊聊这个话题。

发布、部署和交付的概念

还是我们一贯的风格，我们在使用一个理论、方法时先要理清楚它们的概念，概念明确了，边界也基本清楚了。发布管理、部署管理、持续集成、持续部署、持续交付涉及到ITIL4和DevOps两个知识体系。

ITIL4中的定义：

持续集成（Continuous integration）：在软件开发环境中集成（Integrating）、构建（building）和测试（ testing）代码。

持续交付（Continuous Delivery）:持续交付意味着构建好的软件可以随时发布到生产环境中。但通常情况下，组织更喜欢较慢的部署速率，因此发布决策是根据情况逐案（case by case）做出的。

部署（ deploymen）：将任何服务组件移动到任何环境中。

在一些组织中，“供应/配置（provisioning）”一词是指对基础架构的部署，而部署一词仅指软件部署，不过在当前介绍的情况下，“部署”一词同时兼具这两层含义，即部署即包括IT基础设施硬件的安装配置，也包括对应用系统软件版本的部署。

持续部署（Continuous deployment）:变更会通过流水线自动发布到生产环境中,每天可以进行多次生产部署。持续部署依赖持续交付。

部署管理（ Deployment Management）：部署管理实践的目的在于将新的或变更的硬件、软件、文档、流程或其它服务组件移至生产环境中。

但是，部署不仅仅是生产环境的部署，可以涉及将组件部署至不同环境，以用于测试或预发布。

环境（Environment）：用于特定目的IT基础设施的子集，比如包括服务器、中间件、数据库、网络等。常见的环境包括：开发/集成环境、测试环境、预发布环境、生产环境。

发布（Release）：某一服务或其它配置项或者一系列配置项可供（最终用户）使用的一个版本。

注：ITIL4中的发布管理是针对最终用户的发布，发布的是最终用户可用的功能、特性或服务。

发布管理（Release  management）：发布管理实践的目的在于提供新的和变更的服务与特性以供（最终用户）使用。

发布管理针对的两种应用场景

对于发布管理在实际落地时根据发布对象的不同有两种应用场景。

场景1：针对最终用户的发布

ITIL4的发布管理中说的就是这种应用场景，即我们的发布是确保最终用户的“使服务或任何其他配置项的版本或配置项的集合可用。”可以用如下的示意图表示：

这种场景的发布通常是由变更管理触发，或者发布管理可以作为变更实施中的子流程。此时发布管理的主要目的就是确保计划变更的内容（通常指的是软件）针对最终用户可用。

此场景下部署管理是确保有一个可以供运维部门测试、验证的环境。

此种场景下流程的负责人是运维部门，此场景的流程图如下：

场景2：研发针对运维的发布（不属于运维）

在这种场景下往往是研发的视角，研发工程师把软件集成后可以形成一个可供测试的软件版本，这个过程属于研发端的“发布管理”，不属于ITIL4中定义的发布管理的范畴了，可以更倾向于理解是一种测试发布。所以我们在使用发布管理和部署管理的时候一定要明确我们是在那个场景中。此场景下的示意图如下：

理解了发布的场景后，部署管理的作用也就明确了，在不同的场景下，部署管理的阶段是不同的。我们在运维中可以使用部署管理来管理针对用户版本的发布的部署、也可以用来管理在测试环境中的部署。

变更管理中的变更实施与发布和部署的关系？

在实际的落地过程中，变更的涉及范围是比较大的，可能是针对软件系统、硬件系统的某个参数、权限的变更，也可能是其他IT组件的增删改。通常我们把针对软件系统、硬件设备内置系统的升级、新功能增加等涉及到需要严格测试、分步实施的场景中来使用发布管理和部署管理来管控。而针对与原有功能不变的增删改直接使用变更实施环节就可以。如果下面的流程中就是变更实施中嵌入发布管理和部署管理子流程。

部署管理仅是指生产环境的部署吗？

不是，ITIL4中定义的部署不仅仅包括向生产环境部署，还包括测试环境部署、预发布环境部署等。通过部署管理是让内部测试人员有了一个可以测试的环境或者是可以提供预发布的环境供最终发布给用户使用。

从端到端的场景理解：部署、发布、交付

在实际的工作中我们还可能遇到针对软件的集成、部署、发布、交付、上线等术语，至于它们的依赖关系，即谁先谁后，除了集成是首先要完成的，其它几个活动没有固定的依赖关系，它们的先后顺序需要根据具体的应用场景，例如：

场景1：某乙方公司为甲方公司开发了一个web应用，需部署到生产环境，再发布给甲方公司，交付给使用部门(用户),使用部门才能投产使用(上线) ,那么它们的先后顺序就是: 集成—>部署—>发布—>交付—>上线。
  场景2：A公司开发了一个商用软件，发布到网上，B公司通过购买获得，由A或B公司的技术员将软件部署到B公司的生产环境,交给B公司的使用部门(用户),使用部门才能投产使用（即上线) ,那么它们的先后顺序就是: 集成—>发布—>部署—>交付—>上线。

场景3：例如,微软发布了Window (存储在光盘中),交付给用户,用户再部署到生产环境,然后投产使用（上线)。现在的很多单体软件,大多也是这样的流程。那么它们的先后顺序就是：集成—>发布—>交付—>部署—>上线。

场景4：A公司开发了一个SaaS应用,部署到生产环境，交付给B公司，B公司再加入自己公司的基础数据后上线了该SaaS应用,发布给使用部门(用户)使用,那么它们的先后顺序就是: 集成—>部署—>交付—>上线—>发布。

综上，我们在落地的过程中除了区分关键的概念外，还是要充分考虑应用的场景，同样的术语在不同的场景下可能活动是不同的，需要控制的内容也一样，因此，首先明确自己面临的问题、期望达到的管理目标、预期看到的结果，然后再结合各个知识体系做出适合自己组织的管理流程和管理办法。