软件开发团队可以使用各种框架或发布管理模型来组织他们的工作。这些模型帮助组织通过不同的策略实施软件开发生命周期 (SDLC)，以实现相同的结果。一个发布管理模型包含软件开发人员在交付软件产品或功能时用来组织工作的各个阶段。一般来说，每个模型包含以下六个阶段：变更请求、规划、设计与构建、测试、部署和发布支持。
发布管理模型确保根据客户需求生产出高质量的软件。为此目的已经创建了各种发布管理方法，如 ITIL、瀑布模型、迭代模型、V模型、螺旋模型、大爆炸模型、敏捷模型和 DevOps 模型，但还有一些不太流行的方法不在本书的讨论范围内。让我们来回顾一些最常用的 SDLC 发布管理模型：
- ITIL 模型
- 瀑布模型
- 迭代模型
- V 模型
- 螺旋模型
- 大爆炸模型
- 敏捷模型
- DevOps 模型
ITIL 模型
英国政府的中央计算机和电信局 (CCTA) 创建了信息技术基础架构库 (ITIL) 模型，这是一套用于 IT 活动的最佳实践，如 IT 服务管理 (ITSM) 和 IT 资产管理 (ITAM)，其起源可以追溯到1980年代初期。这些实践的核心理念是将 IT 服务与公司运营的需求对齐。2000年，CCTA 并入英国政府商务办公室 (OGC)。
在企业 IT 部门的初期，高层管理者将其视为成本中心，而非价值倍增器。当时，许多公司没有建立获取服务或报告 IT 事件的协议，IT 与业务的沟通也很差。因此，许多公司的领导层认为 IT 无法创造价值或实现公司范围内的目标。随着企业 IT 部门的扩展，他们意识到需要通过实现业务定义的可衡量结果来证明其价值。
随着 ITSM 范式的出现，企业的关注点从 IT 部门转移到了 IT 服务的管理和履行。ITSM 对 IT 专业人员来说是新的概念，他们被视为一个独立实体，而业务部门则被视为他们的客户。为了服务客户，IT 提供由技术资源和专业知识支持的服务。因此，为了展示其价值，IT 必须在既定的服务级别协议中提供这些服务，并满足战略业务需求。
ITIL 指导 IT 服务管理在整个服务生命周期中的应用。ITIL 的核心是一个管理组织 IT 基础架构的框架，以实现战略目标、创造业务价值并确保基本的能力。公司可以使用这一基准作为未来规划、实施和评估的起点。
正如你可能已经推测到的，ITIL 发布管理模型更多地涉及系统开发而非软件开发。尽管如此，ITIL 被公认为最早且在企业环境中广泛实施的发布管理模型之一。尽管 ITIL 在软件发布管理中是一个特例，但了解 ITIL 是什么以及它如何融入整体发布管理生态系统仍然很重要。现在，让我们看看 ITIL 的两个最新版本：V3 和 V4。
ITIL 3
OGC 在其 IT 服务管理 (ITSM) 策略中取得了重大进展，并提供了比 ITIL 版本2 更深更全面的更新指南。ITIL 版本3 于2007年向公众发布，结构为服务生命周期内的五个不同阶段的汇编。这些阶段包括服务战略、服务设计、服务过渡、服务运营和持续服务改进。
这五个阶段中的每个阶段都涵盖了服务生命周期的某个特定阶段，概括如下：
- 服务战略：制定计划以更好地服务客户。服务战略流程从客户需求和市场条件的分析开始，确定 IT 组织应提供的服务和应建立的能力。最终目标是将 IT 部门的思维方式转向战略规划和执行。
- 服务设计：开发新的信息技术 (IT) 服务。该过程的范围既包括新服务的创建，也包括现有服务的修改和增强。
- 服务过渡：创建和发布计算机系统。服务和服务管理程序的更改以协调的方式实施，这也是服务过渡功能的责任之一。
- 服务运营：确保 IT 服务得到良好且迅速的提供。在服务运营过程中，用户的请求得到满足，服务故障得到修复，问题得到解决，例行操作任务也得以完成。
- 持续服务改进：应用质量管理技术来洞察当前和过去的表现。持续服务改进流程的目的是将 ISO 20000 采用的持续改进理念应用到 IT 流程和服务中，以最大限度地提高其有效性和效率。
下图展示了 ITIL V3 发布管理模型的各个阶段：
这就是我们对 ITIL V3 的探讨。我们之所以同时观察 ITIL V3 和 ITIL V4，是因为它们之间存在相当显著的差异。值得注意的是，ITIL V4 是最近才推出的版本，其流程图并未延续早期 ITIL 版本所著称的传统。ITIL V4 的转变体现了它更侧重于成为一个灵活的服务框架，而不是一个僵化的 IT 服务管理模型。
ITIL 4
自2007年以来，ITIL 没有进行过重大修订；因此，ITIL 4 可以看作是对 VeriSM™、SIAM® 和 FitSM 等竞争性服务管理框架兴起的回应。它是 ITIL V3（也称为 ITIL 2011）的更新和扩展版本，可以为企业在数字化转型过程中提供灵活的基础。
ITIL 版本4 概述了一个为 IT 支持的产品和服务提供流程框架。文档进行了大量编辑，使其更易读，并增加了多个示例。ITIL 4 还考虑了当代软件工程和信息技术管理中的实践，通过提供有关在服务管理背景下使用敏捷 (Agile)、DevOps 和精益 (Lean) 方法的指导。最后，ITIL 4 强调它是一个服务管理框架（而不仅仅是 IT 服务管理），这反映了服务管理最佳实践在 IT 业之外的应用扩展。
重要的是要记住，尽管 ITIL 确实是一种发布管理方法，但它与系统开发生命周期的联系比与软件开发生命周期的联系更多。这也是 ITIL 在我们列表中首位出现的原因。现在，让我们把注意力转向瀑布发布管理模型。瀑布模型是组织信息系统建设项目的原始发布管理标准。瀑布模型的出现正值工程师们从用交换机板和电缆编程计算机向使用穿孔卡片的逻辑序列过渡的关键时期。这标志着历史上首次可以独立于物理机器编写和管理程序。
瀑布模型
瀑布模型是一种以线性、顺序方式组织项目阶段的方法。这意味着每个阶段都建立在前一个阶段的可交付成果之上，并对应于不同的任务专业化水平。该方法经常用于多个工程设计专业领域。由于进展主要沿着一个方向（向下，如瀑布）进行，这种方法通常被认为是软件开发中最不迭代且适应性最差的模型之一。原因在于，团队在瀑布过程中只能向前推进，不能回头。这种不可逆的线性推进包括需求收集与分析、系统设计、实施、测试、部署和维护等阶段。
瀑布模型是软件开发中使用的第一种发布管理 SDLC。制造和建筑行业被认为是瀑布开发模型的发源地。在这些行业中，高度组织化的环境意味着在制造过程的早期进行设计修改变得极其昂贵。当它首次被用于软件开发时，对于基于知识的创意工作并没有公认的替代方案。
瀑布发布管理方法由于其缺陷而受到了大量批评。在看到功能性软件之前，客户可能不清楚自己的确切需求，这可能导致他们在事后更改需求。这将导致重新设计、重新开发和重新测试的需求，从而增加成本。软件工程师和业务开发人员可能无法预见在设计新软件产品或功能的过程中可能出现的潜在挑战。在这种情况下，建议重新评估设计，而不是继续推进未考虑新识别的限制、前提条件或问题的设计。
每个分阶段的过程在查看其阶段及其流程图后可以更好地理解。观察瀑布发布管理模型的图表后，可以清楚地了解其线性序列的不可逆步骤如何赋予瀑布模型其名称：
如你所见，瀑布发布管理模型非常适合组织大型项目，涉及数百甚至数千名开发人员共同参与一个项目。现在，你已经对瀑布发布管理模型有了基本的理解，也具备了掌握其后出现的更高级发布管理模型概念的能力。
接下来我们将探讨的发布管理模型是迭代和增量模型，通常简称为迭代模型。这种方法涉及以小的增量步骤或迭代来构建系统。这个发布管理模型是瀑布模型最早且最接近的竞争对手之一，起源于1960年左右。这就是我们接下来要讨论迭代和增量发布管理模型的原因。
迭代模型
这种技术背后的理念是通过小的增量步骤或迭代来构建系统，使软件工程师能够从构建系统早期版本中学到的经验中受益。在系统开发和使用过程中不断学习，其中关键步骤可能从基本实现部分软件需求开始，逐步改进，直到整个系统实现。在每个开发周期的迭代之后，设计的修改和新功能会被整合进来，如下图所示：
具体技术分为三个步骤：初始化阶段、迭代步骤和项目控制列表。系统的起点在初始化期间构建。在开发的第一个阶段，我们希望提供给用户一些可以反馈的内容。它应该提供对问题的全面概述以及一个简单的解决方案。在每次迭代开始时，会编制一个项目控制列表，以记录所有未完成的任务。这包括重新处理当前解决方案的部分或添加全新的功能。分析步骤会导致控制列表的持续更新。
迭代的重新设计和实施应易于理解和应用，可以在迭代本身期间完成，也可以作为添加到项目控制列表中的单独任务。迭代方法不强制要求设计的特定粒度。然而，在关键的迭代项目中，可以使用正式的软件设计文档来补充代码，作为系统的主要文档来源。迭代的分析基于用户反馈和可用的程序分析工具。它包括对结构、模块化、可用性、可靠性、效率和目标达成的检查。研究结果会更新项目控制列表。
通过迭代开发，你的团队将对软件进行增量改进和调整，直到它完全具备功能。每次迭代都应旨在改进整个产品，而不仅仅是产生新的功能或组件。迭代式管理允许根据需要对项目进行调整以确保成功。这有助于开发团队在出现意外变化时（无论是积极的还是消极的）将其纳入考虑范围。
一个合格的迭代项目经理必须能够在项目进展中进行这些调整，尽量减少对团队的干扰，并听取其他团队成员的反馈，以确保进度和预算可行。此外，错误和困难可以更早识别并修复，从而节省时间和成本。当你定期提供可行的产品增量时，它使消费者能够更早地提供反馈，从而产生更符合用户需求的优质软件。如果产品以迭代和增量方式管理，就不会有最后一刻的调整或拼命完成无法实现的截止日期的情况。
这就是我们对迭代和增量发布管理模型的探讨的总结。正如你现在可以推断的，迭代和增量模型与几十年后出现的敏捷发布管理模型惊人地相似，我们将在本章后面讨论它。现在，让我们转换方向，将焦点转向V型发布管理模型。
V模型
V模型因其形似字母“V”而得名。在这个SDLC发布管理模型中，V模型被划分为多个阶段，每个阶段都有其专门的测试阶段。V字的左侧代表验证阶段，而右侧代表确认阶段。V模型是系统创建过程中各阶段的图形表示，用于构建严格的项目管理和开发生命周期模型。下图展示了V模型：
V模型提供了计算机化系统验证框架中主要活动及其相关输出的高级概览，有时也被称为项目生命周期开发。它规定了在产品开发过程中必须执行的活动以及必须生成的可交付成果。
V字的左侧展示了分解需求和开发系统规格的过程。整合和验证各个组件则由V字的右侧表示。然而，需求首先必须经过验证过程，即将它们与更高级别的需求或用户需求进行比较。此外，还有一个被称为系统模型验证的概念。你也可以通过向左移动来完成这一过程，这意味着声称验证只发生在右侧的说法可能并不准确，具体取决于团队的运作方式。
在V模型中，时间和开发从左向右推进，无法逆转这一过程。正如图中所示，所有迭代都发生在框架的垂直方向，要么向上要么向下。两者的区别在于，验证是根据预定的技术规范进行的，而验证是根据实际世界条件或用户需求进行的。你可以通过确保你在构建正确的东西来进行验证，并通过确保你以正确的方式构建它来进行验证。
螺旋模型
1986年，Barry W. Boehm 创建了螺旋发布管理模型，用于组织 SDLC。它假设构建一个应用程序是一个可以无限次重复的循环，直到实现预期结果。通过持续监控风险和检查中间产品，螺旋模型显著降低了大型软件项目失败的可能性。
在开发过程中出现的问题可能对成品产生多种潜在影响。如果发生这种情况，你应该准备好应对成本增加、工作量增加以及交付日期延迟。这些都是可能迅速对公司可持续性构成威胁的因素。螺旋模型采用迭代和渐进的方法，加上定期的风险评估（可以采取原型草稿、研究或模拟的形式），旨在完全消除这种事件发生的可能性，或至少减少其造成的损害程度。螺旋软件开发在大型、高度定制的项目中非常流行，特别是在客户和开发人员优先考虑财务管理或市场高度不稳定的项目中。与其他传统模型相比，螺旋模型的最大优势在于风险分析，这对所有参与者都有益。定期的风险评估在缺乏经验值且风险概率较高的创新技术环境中特别重要。
软件开发项目通过其螺旋模型周期持续进行，直到达到最终状态。该周期主要包括以下四个步骤：
-
螺旋模型的典型周期的第一个阶段是确定应与软件开发的各个阶段相关联的目标。这类变化的例子包括增加功能或提高性能。同时，需要指定多个实施选择（例如，设计A与设计B）并确定框架条件、费用或将花费的时间。
-
接下来的阶段是分析各种选项，以目标和框架条件作为权威参考值。在螺旋模型周期的这个阶段，应该识别和分析对软件项目整体开发构成重大风险的不确定区域。在下一个阶段，将利用一些工具（如原型制作、模拟、基准测试、分析模型和用户调查）来制定既能减少风险又能最具成本效益的策略。
-
在进行彻底的风险评估后，可以继续进行软件开发——始终存在一定程度的剩余风险。例如，如果性能风险、用户界面风险或内部接口控制风险在开发过程中占据主导地位，第一种选择是采用渐进式开发策略，其中项目被更明确地定义，原型被优化。在这种策略中，用户界面风险和内部接口控制风险是强烈主导开发过程的关注点。然后，代码被创建并多次测试，直到获得预期结果，这为随后的开发过程提供了低风险的基础。
渐进式原型开发
渐进式原型开发，也称为试验板原型，与其他原型策略不同。使用渐进式原型的主要目标是通过系统化过程构建一个高度稳健的模型并不断加以改进。这种方法基于这样一个理念，即渐进式原型作为新实施系统的基础，允许未来逐步增加增强功能和额外需求。
- 当前一个周期结束后，立即规划下一个周期。如果单个周期的目标能够实现，并且下一个目标的确定尚待进行，那么这可能是项目的通常延续。另一方面，如果前一阶段的开发存在缺陷，寻找解决方案可能是唯一的选择。一个可能的替代方案是已经确定的其他选择之一，或引入一个全新的方法。通过这种方式，你可以再次尝试，直到实现目标。
在软件开发中，螺旋发布管理模型被认为是一种通用过程模型。这四个阶段仅仅是为一个周期确立了基本目标，并不要求它们在每次迭代中都必须实现。螺旋模型并未严格规定这些步骤的顺序。因此，该模型有可能在任何时候与其他过程模型结合使用。
这就是我们对螺旋发布管理模型的回顾。到现在为止，你已经知道螺旋软件开发是一种风险规避模型，它强调迭代开发技术的实施，并在SDLC的每一步管理风险。接下来，让我们探讨大爆炸发布管理模型——一种与螺旋模型截然不同的高风险开发风格。
大爆炸模型
在大爆炸发布管理模型下，软件工程师几乎没有任何准备，便全力投入编程。换句话说，没有预先制定的计划，需求是随着发现而实现的。在某些情况下，如果需要进行调整，可能需要对应用程序进行完全重写。你可以清楚地看到，大爆炸模型的名字由此而来。然而，当项目仅涉及一两个开发人员时，例如在学术界或实践中，这种方法便表现得尤为出色。这种技术在项目需求不明确且有一个固定的完成期限时非常有用。
大爆炸模型是一种从无到有的软件开发生命周期范式。几乎没有时间花在规划上，我们也不遵循任何特定的程序。由于它不需要任何计划，它是最基础的发布管理方法类型。需求是随时应用的，几乎没有预先的考虑，甚至客户也不明确他们想要什么。这种方法的主要目标是尽快开始编码，不遵循任何特定的结构，并尽快将成品交付给客户。日常开发从少数前提条件开始，尽管对最终结果知之甚少。随后，客户与开发团队保持紧密联系，以跟踪工作进展。如果结果符合预期，产品将获得批准；否则，将制定另一种解决方案。
简而言之，这种方法不需要详细的需求规范，产品需求在收到后会立即被理解并执行。这个范式的核心重点是编码，使其比其他发布管理模型更容易受到风险影响。当组件或至少它们的组成部分完全集成后，测试可以开始。该模型最适合在现有环境中整合尖端技术、分析所做的修改以及适应性调整。
正如你可以推测到的，这个模型与宇宙大爆炸理论相似。时间、资源和能量的浓缩混合在一瞬间产生了成品，仿佛凭空出现。下图是对大爆炸发布管理模型的详细描述：
这就是我们对大爆炸发布管理模型的回顾总结。到现在为止，你已经对发布管理的真正含义有了深入的理解。你明白了发布管理可以从最正式到最非正式的多种形式。接下来，我们将探讨备受争议的敏捷发布管理模型。无论你爱它还是恨它，敏捷模型在大约二十年间异常流行，直到 DevOps 的兴起并最终超越了它。
敏捷模型
敏捷发布管理模型将 SDLC 阶段划分为多个开发周期，团队在每个周期结束时交付增量的软件变更。敏捷方法非常有效，其快速的开发周期帮助团队及早发现问题；然而，过度依赖客户反馈可能导致过度的范围蔓延。敏捷模型非常适合需要随着时间的推移而具备适应性和灵活性的软件开发项目。下图展示了敏捷模型：
敏捷开发的大多数技术将工作分为多个较小的增量。这些增量相比其他发布管理模型（如瀑布模型）在前期规划和设计上需要的时间和精力更少。这些迭代被称为冲刺（sprints），是短暂的活动周期，通常持续一到四周。每次迭代都需要跨职能团队参与，团队负责所有活动，包括规划、分析、设计、编码、单元测试和验收测试。在迭代结束时，利益相关者会看到一个已经具备功能的产品演示。这整体上降低了风险，并使产品更容易快速适应新情况。
目标是在每次迭代结束时拥有一个可用的版本（且错误较少），尽管每次迭代可能不会产生足够的功能来支持市场发布。当产品以增量方式开发时，与其在产品最终交付日期前出现灾难性失败，不如在每个迭代阶段早期且频繁地失败，这样更具灵活性。产品或新功能在发布前可能需要多次修订。最重要的进展指标是可运行的软件的存在。
快速产品开发和降低风险是采用敏捷方法的两个主要优势。因此，通过将产品以较小的增量发布到市场，可以减少与创建不满足消费者需求的产品相关的风险。
这就是我们对敏捷发布管理模型的回顾总结。正如你所见，敏捷模型是迭代和增量模型的逻辑继承者，同时也是迈向 DevOps 发布管理模型的一个步骤。这也是我们接下来将讨论 DevOps 模型的原因。
DevOps 模型
DevOps 发布管理模型涵盖了一系列方法，这些方法将软件开发（Dev）和 IT 运营（Ops）结合起来，以加快和更频繁地发布软件。这种软件开发策略结合了沟通、自动化和分析。DevOps 方法论强调交付与业务目标一致并满足客户需求的软件。通过利用快速反馈循环、相关的关键绩效指标 (KPI) 和迭代开发策略实现这一目标。虽然 DevOps 包括规划、设计、编码、测试和部署，但该模型的一个显著特点是将持续集成、持续交付、持续测试和持续监控融入到 SDLC 中。下图展示了 DevOps 模型：
发布管理在很大程度上依赖于精确的报告，以便跟踪需求、风险和障碍。它还确保项目的初始目标和目的在整个软件开发生命周期中都能得到实现。
采用 DevOps 原则自然会导致改进的发布管理框架，从而在交付生命周期的每个阶段创建符合行业标准的有效协作和测试流程。人们往往将自动化视为 DevOps 中最重要的价值；然而，自动化应始终以提高人员生产力为目标。当人们致力于提高运营效率并减少人为错误的影响时，他们将不可避免地以更高的速度发布可靠的服务。
在 DevOps 文化中整合发布管理，使企业能够实现快速、可靠和成功的软件发布。最终，这种现象有助于提升客户满意度，增进开发团队内部的合作关系，并加速企业的扩展。
DevOps 和发布管理在软件开发、项目管理和 IT 运营方面有着密切的联系。DevOps 发布管理涵盖了监督软件发布和交付周期的设计、规划、调度、测试和实施的相关活动。
那些至少对产品进行过一次修改的组织深刻理解发布管理在 DevOps 背景下的关键作用。如果正确执行，这一策略的实施有可能提高开发、测试和运营流程的效率。此外，这种发布管理策略有效减少了与返工相关的费用，增强了协作，并促进了高质量产品的成功交付。
这提升了组织对发布过程各个阶段的监督，从最初的开发到最终的交付。DevOps 发布管理已成为新产品发布或修改引入时的当代标准。根据团队的不同、他们偏好的实践以及组织的目标，DevOps 过程可能会略有不同。
通过采用 DevOps 发布管理，软件开发团队受益于将质量检查融入并左移，并在软件交付生命周期的更早阶段进行测试、自动化和 QA 程序。由于其在消除孤立团队成员的壁垒方面的实用性，DevOps 发布管理正在成为目前最受欢迎的发布管理策略。
总结
我们已到达本章的结尾。到目前为止，我们已经讨论了 IT 行业中八种最常见的发布管理模型。它们是 ITIL、瀑布、迭代、V型、螺旋、大爆炸、敏捷和 DevOps 模型。你现在应该了解每种发布管理模型的各种优缺点，并对为你的项目选择合适的模型充满信心。此外，你还了解了 DevOps 相较于之前的发布管理模型所带来的惊人好处。因此，你对发布管理的历史有了实际的了解，并能够对每种模型如何演变得出有根据的结论。
本章到此结束。在下一章中，我们将学习是什么使 DevOps 发布管理独特。这一点很重要，因为在本书的剩余部分中，我们将重点转向 DevOps 发布管理模型。
