部署与发布：缺乏发布管理的部署活动对软件交付是低效的
部署和发布是软件工程中经常互换使用的两个术语，甚至感觉是等价的。然而，它们是不同的！
- 部署是将软件从一个受控环境转移到另一个受控环境，它的目的是将软件从开发状态转化为生产状态，使得软件可以为用户提供服务。
- 发布是将软件推向用户的过程，应用程序需要多次更新、安全补丁和代码更改，跨平台和环境部署需要对版本进行适当的管理，有一定的计划性和管控因素。
部署是发布的前提，只有当软件已经成功部署后，才能进行发布。缺乏发布管理会导致发布不规则、手动交付过程、数据库更新问题、协作问题等。
如下，简单归纳了发布&部署的差异：
部署、发布：概念区分
日常研发活动中，我们会经常听到下面的说法，感觉有点差别，又感觉一头雾水说不清楚区别在哪里。
- 功能还没集成进来。
- 功能还没部署上去。
- 功能还没交付。
- 功能还没上线。
- 功能还没发布。
下面对上述关键词进行了总结归纳
集成（Integrate）
- 定义：将组成部分（部件）收集、归拢，并建立它们之间的联系或依赖关系，构建形成一个整体。
- DoD：通过验证（验收）测试，确认集成的结果是正确的。
- 说明：为了验证集成的结果是正确的，需要对它（集成的结果）进行验证（验收）测试，而为了做验证（验收），需要将它（集成的结果）部署到一个环境中。但验证（验收）测试、部署，这些活动并不是集成，它们只是为了验证集成达到了期望的结果。如果你能保证集成没有问题，那么可以不做部署和验收测试这2个动作。
- 特征：将分散的东西合并到一起，形成一个整体。
- 举例：多个单元代码通过集成，形成一个组件。多个组件或模块通过集成，形成一个系统。多个系统通过集成，形成一个整体解决方案。
部署（Deploy）
- 定义：安装、配置（如有）。
- DoD：通过验证（验收）测试，确认部署的结果是正确的（成功部署）。
- 说明：为了验证部署的结果是正确的，需要对它（部署的结果）进行验证（验收）测试。但验证（验收）测试并不是部署，它只是为了验证部署达到了期望的结果。如果你能保证部署没有问题，那么可以不做验收测试这个动作。
- 特征：将软件“放置”到某个环境中。
- 举例：部署人员将测试版本部署测试环境。将某个版本部署到试运行环境。将正式版本部署到生产环境。将一个模块部署到系统中。
交付（Delivery）
- 定义：交给、付出、移交，指物（如软件安装包的光盘）或权（软件的管理权、使用权、所有权等）在人与人之间的转移、传递或接管。
- DoD：接收方确认收到（如签收、同意）。
- 说明：接收方可能会对收到的物或权进行验收测试，然后才签收。但验收测试、签收并不是交付，它只是为了验证交付的东西是期望的东西，它们是交付的下游动作。如果能保证交付物没有问题，那么可以不做验收测试、签收这样的动作。
- 特征：交付物或权的拥有者发生了“转移”。
- 举例：开发人员将测试版本交付給了测试人员。测试人员将正式版本交付给了运维人员。测试人员错误的将测试版本交付给了运维人员。IT团队将系统交付给了业务部。某公司将软件产品交付给了零售商。商店将软件光盘交付给了用户。这次只交付了一个模块。
上线（Go-live / Ship）
- 定义：上到生成线，即部署到生产线上（生成环境中）
- DoD：在生产环境中可以看到，并可以使用。
- 说明：上线后，可以使用系统，也可以不使用系统。如果使用系统，开始创造业务价值，那么也叫投产（即投产=上线+使用系统）。如果上线后，不使用系统，那么表示系统还没有“开工”，它并不影响上线这个动作。“使用系统”这个动作是上线后的下游活动，它不是“上线”活动的一部分。
- 特征：一定是部署到生产环境中（不是其它环境），即生产线上。上线 = 在生产环境上的部署。
- 举例：IT部门上线了一个演示版。正式版刚刚上线，还没有用户访问。某系统上线了半年，还没有投产，某系统刚上线1个月，公司业绩就得到了大幅提升。
发布（Release）
- 定义：将集成（构建）出来那个整体（发布对象），打上一个发布标签，提供出来，受众可以获得。
- DoD：提供出来，受众可以获取到。
- 说明：发布的版本未必是正式版，比如发布测试版（如Beta版）、试用版、演示版。发布之后，受众可以获得软件，但不一定就使用它。发布的软件可以存储在VCS（版本控制系统）中或制品库中，也可以存储在光盘等介质上。受众获得软件之后的下游动作，不一定是部署，也可能是其他动作（如交付或其他）。如：
- 发布测试版-->部署到测试环境-->交付给测试人员做验收测试。
- 发布正式版-->部署到生产环境-->交付给用户使用。
- 发布正式版产品（如windows安装盘）-->（售卖）交付给用户 --> 部署 -->上线使用。
- 特征：发布物有（标签）标识，提供出来可以获得。
- 举例：开发人员发布了一个测试版。开发团队在每个月都会发布一个演化版。某产品发布了新的版本，用户需要重新购买后，才能部署升级。某云平台发布了新的版本，不需要用户部署就可以使用新的功能。本次版本发布了，但没有人使用。
不同企业场景下的部署与发布
对于上面的概念解释，可能你会觉得有什么用呢？能解决什么问题呢？不妨按照以上的定义，把开头的那段话，进一步解读，得到如下信息：
- 功能还没集成进来 --> 功能还没有被合并到一起，没有形成一个整体。
- 功能还没部署上去 --> 功能还没有安装、配置到指定的环境中。
- 功能还没交付 --> 功能还没有“转移”给使用者。
- 功能还没上线 --> 功能还没有部署在生产环境。
- 功能还没发布 --> 功能还没有提供出来，不可以获得。
除了集成是开发完成后首先完成的外，其它几个活动没有固定的依赖关系，它们的先后顺序需要根据具体的应用场景。
场景1-2B项目交付
某乙方公司为甲方公司开发了一个web应用，需部署到生产环境，再发布给甲方公司，交付给使用部门（用户），使用部门才能投产使用（上线），那么它们的先后顺序就是：集成—>部署—>发布—>交付—>上线。
场景2-2B在线服务类
A公司开发了一个SaaS应用，部署到生产环境，交付给B公司，B公司再加入自己公司的基础数据后上线了该SaaS应用，发布给使用部门（用户）使用，那么它们的先后顺序就是：集成—>部署—>交付—>上线—>发布。
还有更多场景，就不列举了。
场景3-2B软件售卖
A公司开发了一个商用软件，发布到网上，B公司通过购买获得，由A或B公司的技术员将软件部署到B公司的生产环境，交给B公司的使用部门（用户），使用部门才能投产使用（即上线），那么它们的先后顺序就是：集成—>发布—>部署—>交付—>上线。
场景4-2C软件包售卖
早年，微软发布了Window XP（存储在光盘中），交付给用户，用户再部署到生产环境，然后投产使用（上线）。现在的很多单体软件，大多也是这样的流程。那么它们的先后顺序就是：集成—>发布—>交付—>部署—>上线。
场景5-2C互联网在线服务
对于互联网应用服务，互联网厂商一般会进行集成（频率集成），通过自动化方式部署到dev/test/uat等环境，通过一定的审批机制获得部署到prod环境的授权（蓝绿、灰度等），正式发布上线，交付给用户使用
那么它们的先后顺序就是：集成—>部署—>发布—>上线—>交付
通过以上分析，你对“集成”、“部署”、“上线”、“交付”、“发布”的概念的理解是否清晰了？
吃透“部署发布”的重要性
上面说了这么多，目的不是为了死记某些概念，而是想说明，不同组织、产品形态不同，部署发布方式差异很大，在设计持续交付 (CD) 流程之前，需要了解关于部署、发布的素有信息。
1. 有助于设计并优化软件交付流程
从代码提交到集成，再到功能验证，再到被部署到不同的环境，中间涉及了“代码提交信息”，“制品信息”，“环境配置信息”等，不同的发布方式，这些信息的传递和保存方式也各不相同。理解吃透这些差异，才能设计出来有意义的交付流程。
- 如何集成涉及到了代码仓库的组织和构建流水线的设计
- 部署又和环境紧密联系，还有部署策略
- 上线又会和审批流程有关系
- 发布就需要对制品进行晋级标签的处理
- 交付就需要和制品的存储/分发方式密切相关
2. 部署发布的质量取决于明确的发布计划
另外，发布管理是ITIL服务管理框架中的一个重要流程，主要负责计划、实施和控制IT服务的变更，确保变更过程中各个环节的顺利进行。
发布管理关注的是将经过测试并导入实际应用环境的新增或改进的配置项分发到最终用户，并确保这些配置项能够安全、可靠地运行。
因此需要在发布计划、包和构建发送进行测试之前进行广泛的规划，主要涉及
- 发布单元具体业务需求及应用功能升级详情
- 主要发布的发布数据
- 预定义的文档流程
- 广泛的测试计划
另外，软件版本需要适当的管理以避免与未来版本相关的问题。
相关案例
这里，从不同角度归纳一些关于发布的案例。一般来说，需要提前制定发布计划，并且由专人(例如release manager这样的角色)负责管理发布计划。release manager 作为研发团队（研发执行）和客户（需求变更）之间的桥梁，清楚了解每次发布的变更，以及影响客户的范围。
案例-1 发布活动的协同
2016 年，联合航空为超过 1.43 亿用户提供服务。然而，软件发布管理是一个巨大的挑战。有几个手动流程和电子表格，这增加了发布周期时间。
因此，联合航空公司选择通过转移发布团队的角色来利用在岸/离岸发布模型，以确保完成特定的承诺。他们的发布管理方法最好的部分是使用 DevOps 和集中治理模型。他们设法通过持续交付团队 (CDT) 和开发团队之间的协作来简化发布。
案例-2 Firefox的发布火车
Firefox的发布流程：每个独立的发布火车（新的发布过程采用火车模型，固定的“发车”时间，特性的发布取决于该特性是否赶上最近的火车发车时间）包括6周的开发时间加上12周的稳定时间：
除了发布计划，这里也需要分支策略的配合 （新的开发成果不会直接发布到Aurora和Beta分支上，这些分支需要被开发人员和社区测试人员共同测试完方可；如果发现开发中存在程序问题或者BUG，就需要先解决问题）
案例-3 支持发布的平台Zadig
对于发布，市场上少有平台会关注这个环节。笔者过去见过的团队，一般都会用一个excel表格的方式来记录各个版本的变更，以及发布的客户范围。
这里介绍Zadig平台中的“发布管理”模块，特别是对于2B场景，可能面对很多不同客户，包括不同的定制， 需要一个平台来汇总这些信息，包括
- 发布版本管理-与产品版本规规划对齐，首尾呼应，形成闭环
- 发布审批 - 对于直接对线上的正式环境，需要配合自动化的流水线，取得管理人员的审批
- 客户管理- 最终的交付物最终给哪个客户，需要明确的体现出来
目前，Zadig更多是针对于客户SAAS服务，直接面对线上环境，所以还会有线上基础设施云供应商的配置。
这里其实可以拓展更多，比如对于私有化部署场景，这里交付的可能是部署包，数据库文件等等。
最后
上面从部署发布的概念，不同场景，到案例工具进行了总结，希望能对大家有所启发~
下面归纳了可能影响发布的关键要素。部署发布是软件交付的最后一公里，呼应了产品的发布计划，有序的发布管理和流程，会让价值交付更加清晰透明，取代混乱和低效。
- 版本发布计划/需求变更
- 版本发布流程/人员
- 分支策略
- 部署策略
- 环境/配置管理
- 制品晋级/标签
注：部分内容参考网络资料，如有侵权请联系我
