在软件工程领域，新软件产品或改进后的软件产品通常被称为“发布”。这包括开发过程中所有相关的程序和工件。
发布是软件开发和工程过程的高潮，它代表了产品的一个全面且功能完善的迭代版本。在软件产品向公众发布之前，通常会经过 Alpha 和 Beta 测试阶段。发布通常是指软件的最终精致版本，但它也可以用于描述 Alpha 或 Beta 版本的首次亮相。在讨论发布时，你可能还会遇到“发布”（launches）和“增量”（increments）等术语。
大多数公司使用顺序编号或字母系统为其发布版本标注。这个命名约定被称为软件版本控制。每个组织都会始终如一地应用其内部标准，但语义版本控制 (semver) 是整个行业的通用标准，用于确定这些唯一 ID 应如何从一个版本演变到下一个版本。
在本章中，我们将定义发布管理并了解其文化意义和技术视角。此外，我们还将回顾发布管理的简要历史，并了解其多年来的发展历程。最后，你将了解任何发布管理模型的标准六个阶段。需要注意的是，瀑布模型是最初的发布管理标准，但使用瀑布模型并不是强制性的。发布管理与所选择的模型无关，且可以适应多种 SDLC 模型，我们将在第三章中进一步讨论这些内容。
本章我们将涵盖的主要主题包括：
- 什么是发布管理，以及它是如何发展的？
- 解剖发布管理生命周期
什么是发布管理，它是如何演变的？
发布管理是一套全面的活动，包括战略规划、概念化、调度、严格测试、无缝部署以及对软件发布的有效控制。其主要目标是通过软件开发团队快速向客户交付重要的应用功能和改进，同时保持既定生产环境的完整性、机密性和可用性。
在竞争激烈的商业和 IT 环境中，缺乏质量或功能的产品发布是让竞争对手获得优势的最快方式。现代企业是动态的，众多变化以不同的速度完成。企业需要发布控制和部署自动化来协调所有这些变化，以便最终产品能够为客户提供他们所期望的卓越价值。成功的发布管理能够提高发布的频率，并减少质量问题的发生率。这样，企业可以更快地提供软件，同时减少相关风险，从而提高生产力、沟通和合作。
由于这些改进，团队现在能够在更短的时间内持续生成高质量的软件，从而使组织能够更迅速地响应客户需求或运营环境的变化。发布管理的另一个好处是可以标准化和简化开发和运营过程。团队建立了可审计的发布控制，这样所有发布都可以从一个中央位置检索。通过为所有发布建立标准的书面程序，组织的成熟度也得到了进一步提升。团队可以从过去的发布中学习经验，并将这些知识应用到未来的迭代中，如果他们标准化并专注于产品。
运营与开发人员之间的改善沟通得到了广泛的认可，因为它减少了意外情况的发生。现在，跨职能团队不必担心由于发布后遗漏的最后期限导致运营部门不得不进行补丁和祈祷或处理紧急问题。结果是，有更多时间可以用于自动化业务流程或修复开发和生产环境中集成配置的不兼容性。
定义
让我们快速定义一些你在本书中可能会遇到的关键术语：
- 补丁和祈祷：在软件开发中，“补丁和祈祷”战术指的是使用脆弱的解决方案（有时称为“补丁”）来解决缺陷或漏洞，而不解决问题更深层的根源。众所周知，组织会使用这种技术来赶紧完成严格的最后期限、优先处理其他活动或弥补资源不足；然而，这种策略可能会导致长期的技术债务和严重的安全问题。
- 灭火：在计算机科学领域，灭火涉及分配资源来解决意外问题。这个词通常指的是寻找错误而不是集成功能。灭火可能包括增加工程师来修复软件开发过程中在产品发布截止日期临近时发现的代码问题。许多企业已经为灭火情况做好了准备，但反复出现的紧急情况表明计划不周或效率低下，浪费了本可以用于其他地方的资源。全面的灾难恢复计划（DRP）可以预见并可能防止灾难，从而最大限度地减少灭火。
- 抛过墙：这是商业术语，指的是完成项目的部分工作后将其交给下一个团队。这个短语通常在两个团队之间沟通较少或在新部署前没有时间进行技术简报时使用。
简而言之，发布管理促进了 IT 公司内部各部门之间的合作。这允许对产品分发过程进行更全面的改进。
现在你已经了解了发布管理的含义，让我们进一步探讨这个主题。在接下来的部分中，我们将回顾发布管理的历史，看看新的模型是如何随着时间的推移而出现的，以及它们如何与当时的现代软件开发理念相契合。最后，我们将通过审查任何发布管理模型应包含的六个标准阶段来结束本章。
发布管理简史
软件工程从基于项目的产品向基于产品的产品转变是发布管理日益重要的原因。发布管理从一开始就任务是在项目开发范式的框架内执行的。在这种方法中，软件开发人员将每个发布视为一个独立的项目，而不是一个产品。一旦软件开发完成，通常就标志着开发人员在过程中的角色结束，然后他们就会解散。
随着时间的推移，软件开发过程逐渐演变得更加类似于产品周期，在这个周期中，产品在其较长的生命周期内经历支持、改进和多次重新发布。在这种结构中，开发的主要目标不是发布本身，而是发布标志着支持和修订活动的开始。由于这种复杂性，阶段协调变得比以往任何时候都更加重要。因此，现代发布管理借鉴了以业务为导向的产品管理理念，包括售后支持和增强。
从软件到发布管理的演变
1948年，英国计算机科学家汤姆·基尔本 (Tom Kilburn) 创建了第一段软件，他使用了8个字的工作存储和17个字的指令，总共25个字。自那以后，软件开发过程取得了显著进展。
尽管他的同事嘲笑他，保罗·尼奎特 (Paul Niquette) 在1953年提出了一个计算机概念，该计算机的程序可以与设备的物理组件分开存储。从那时起，这彻底改变了人们对计算的看法： “当我第一次大声说出‘软件’这个词时，我周围的人说，‘什么？’从一开始，我就觉得这个词太不正式了，无法写下来，而且说出来也很尴尬。然而，尽管怀着不安的心情，我还是在五十年代的演讲、讲座和媒体采访中偶尔提到‘软件’这个词。” （保罗·尼奎特，《软件时代简介》）
在20世纪上半叶，当诸如电子数字积分器和计算机（ENIAC）等发明加速了计算的发展时，软件还不够复杂，不需要像软件开发生命周期 (SDLC) 这样的框架。早期的软件实现中使用了诸如 go-to 语句和 if/then 表达式等简单工具。最终，开发模型的需求导致了 SDLC 的产生，而 SDLC 又受到了结构化编程思想的启发。
结构化编程是一种编程范式，通过使用结构化控制流组件（如选择 (if/then/else) 和重复 (while 和 for)），以及块结构和子例程来提高计算机程序的清晰度、质量和效率。1950年代后期 ALGOL 58 和 ALGOL 60 编程语言的出现标志着这一领域的重大进展。值得注意的是，ALGOL 60 在1960年引入了对块结构的支持，进一步增强了其功能。
通常被称为 SDM 的软件开发方法直到1960年代才开始实践。系统开发生命周期 (SDLC) 可以被视为最早发布的管理方法和框架，用于构建大型计算机和其他模拟信息系统，早于软件开发生命周期。系统开发生命周期的主要目标是系统地、细致地追求信息系统的开发。这需要严格按照生命周期的每个阶段进行，从最初的构思到最终在所采用的特定框架内交付系统。值得注意的是，通过将系统替换为软件，一种新的 SDLC 形式诞生了。它旨在成为行业的权威标准，详细说明了创建和维护软件系统所涉及的输入、输出和步骤。
瀑布模型这个术语在其正式的 SDLC 规范发明多年之后才出现（你可以在第三章的图3.2中看到瀑布发布管理模型的六个阶段的插图）。1956年6月29日，赫伯特·D·贝宁顿 (Herbert D. Benington) 举行了关于在软件工程中使用瀑布阶段的第一次已知演讲，尽管当时并未使用“瀑布”一词。瀑布模型的最早正式、详细的插图可以追溯到温斯顿·W·罗伊斯 (Winston W. Royce) 1970年的一篇文章，但罗伊斯的文章中并没有使用“瀑布”这个名字。据说“瀑布”一词最早记录在1976年由托马斯·E·贝尔 (Thomas E. Bell) 和 T.A. 塞耶 (T.A. Thayer) 发表的一篇研究文章中。到1985年，美国国防部在 DoD-STD-2167A 中将瀑布发布管理方法正式编纂。国防部与软件开发承包商合作的标准中指出，“承包商应实施一个软件开发周期，包括以下六个阶段：软件需求分析、初步设计、详细设计、编码和单元测试、集成和测试。”
从1960年代 NASA 的水星计划 (Project Mercury) 开始，迭代和增量开发 (IID) 是瀑布发布管理的最早且最接近的竞争对手之一。水星团队的一些成员后来组成了一个新的 IBM 子公司，该子公司负责为航天飞机创建核心航空电子软件系统，该系统从1977年一直运行到1980年。在31个月的时间里，团队进行了17次 IID 迭代，每次迭代平均持续约8周。他们决定不使用瀑布开发方法，因为航天飞机项目的需求在软件创建过程中间已被广泛认识到会发生变化。
1986年，巴里·勃姆 (Barry Boehm) 在他的研究中首次概述了螺旋模型，并提供了现已广为人知的图表，该图表已在讨论螺旋模型的后续出版物中多次使用：
IT基础架构库 (ITIL) 于1980年代开始，作为对数据中心分散化和地理上多样化架构使用的回应。这种行为导致了流程和部署的变化，从而在企业内部导致了不一致或不满意的IT服务管理。英国中央计算机和电信局 (CCTA) 认识到将信息技术视为一种服务的重要性，并在整个信息技术服务生命周期中使用一致的程序。因此，CCTA 建立了政府信息技术基础架构管理方法。到1989年，CCTA 发布了 ITIL 第1版。
V模型概念几乎同时在德国和美国独立出现，在1980年代后期。美国的V模型在1991年全国系统工程委员会 (NCOSE) 会议上被概述，自1995年起改名为INCOSE，专门为涵盖硬件、软件和人机交互的卫星系统设计。德国的V模型最初由位于奥特布伦的研究与开发组织IABG与科布伦茨联邦国防技术与采购办公室合作制定。这个联合工作由联邦国防部主导。1992年夏天，联邦内政部接管了民用公共机构的领域。
雅各布森 (Jacobson)、布奇 (Booch) 和鲁姆堡 (Rumbaugh) 于1999年在他们的书《统一软件开发过程》中引入了统一过程的概念。这本开创性的著作首次提出了一个敏捷框架用于软件开发。
敏捷发布模型的起源可以追溯到2001年在犹他州斯诺伯德著名度假胜地的一次聚会。当时17位著名的软件工程师聚集在一起讨论轻量级开发方法，最终共同制定了《敏捷软件开发宣言》（即敏捷宣言）。2009年，敏捷宣言的共同作者罗伯特·C·马丁 (Robert C. Martin) 及其团队提出了扩展的软件开发原则，即《软件工艺宣言》。这个宣言旨在指导敏捷软件开发实践，使其符合专业行为和精通的原则。
2007年，IT顾问帕特里克·德波伊 (Patrick Debois) 在意识到开发 (Dev) 和运营 (Ops) 团队之间合作不够有效后，创建了DevOps方法。尽管他一直对开发和运营之间的差距和争议感到不满，但他在一个大型数据中心迁移项目中负责测试时所经历的持续来回切换和折腾让他特别沮丧。有一天，他完全沉浸在敏捷软件开发的流程中。第二天，他却陷入灭火中，亲身体验了传统运营带来的不确定性。他确信，肯定有一种更有效的方法。
2008年，安德鲁·沙弗 (Andrew Shafer) 在敏捷会议上组织了一次“志同道合”的小组讨论，主题是讨论敏捷基础设施。安德鲁认为不会有人来参加这次会议，所以他自己也没有参加。当帕特里克·德波伊出现在会场时，他立刻去找安德鲁讨论敏捷基础设施，认为这可以使运营像开发人员一样敏捷。这正是DevOps运动的起点。
在2009年的Velocity会议上，约翰·奥尔斯波 (John Allspaw) 和保罗·哈蒙德 (Paul Hammond) 发表了题为《每天部署10+次——Flickr的开发与运营合作》的演讲，此后这一概念在开发团队中逐渐流行开来。这个讨论让人们看到了使用这些早期DevOps方法所能实现的可能性。此外，帕特里克还组织并主持了首届DevOpsDays会议，该会议于2009年10月在比利时的根特举行。会议被称为“将开发与运营结合在一起的会议”。这也是“DevOps”一词首次在公开场合提及。如今，DevOpsDays会议已经成为一个定期在世界各地举办的区域性活动。
在下图中，你会看到发布管理历史的时间线。它始于1953年“软件”一词的出现。从那时起，你可以看到从瀑布模型到DevOps的演变。无论是讽刺还是巧合，直到今天你仍然会看到这两种模型被使用。需要注意的是，进展随着时间的推移而加速，从几十年缩短到仅几年。了解过去的经历是理解你现在所处位置的关键。发布管理的历史最终促成了DevOps的诞生。了解这一点对于理解为什么DevOps成为软件开发历史上被广泛采用的发布管理模型之一至关重要。
到目前为止，你已经了解了发布管理的目的及其历史。你现在知道了新模型是如何随着时间的推移而出现，以及它们为何反映了当时的理念。现在，让我们通过分析任何发布管理模型应包含的六个标准阶段来结束本章。
解析发布管理生命周期
发布管理生命周期包括几个不同的阶段：
这个过程的可变性取决于所选择的发布管理模型、产品设计、团队和组织，因为这些因素都受到项目特定需求的影响。然而，无论规模大小，组织和团队都必须遵循一套普遍适用的程序，以实现财务可持续性并向用户提供高质量的成果。
现在，让我们来看看发布管理标准程序包含哪些内容。
请求
发布管理过程的第一步是对新功能或当前功能修改的请求。不能保证所有请求都会导致新的发布。每个请求都会被分析，以确定它是否合理、是否可以实施以及当前版本的应用程序是否可以修改以适应它。
无论你是从头开始还是希望改进已经建立的产品，了解客户的期望至关重要。不要假设你已经知道客户希望在应用程序或相关产品中包含哪些功能和特性。例如，客户可能要求你在他们的移动应用程序中添加新功能。你需要与他们坐下来开会，以充分了解他们的需求、愿望和动机。
无论你的目标是什么，在进入规划和开发之前，务必彻底理解它。如果有任何疑问，请在继续之前与团队或客户商讨，以制定适当的发布策略，以满足需求。
规划
在你完全了解发布需求后，下一步就是规划。为了构建并发布你打算做的事情，你需要根据所有相关方的需求进行详细的规划和准备。在技术、截止日期、人员和资源方面，你的准备工作需要合理和切实可行。例如，如果你正在开发一个新版本的应用程序进行发布，你需要在发布给客户之前，在各种平台和设备上对其进行彻底测试。
如果你与客户保持定期联系，规划会更加容易。可以讨论项目进度表和成品的预计交付日期。你不能承诺一个不可能的截止日期。在确认截止日期时，考虑到可用的资源（资金、时间和人力）。此外，在发布之前，明智的做法是考虑将要使用的技术并相应规划。考虑你的选择是否具有成本效益、是否符合预算，并利用团队的才能。选择能够让你快速轻松设计出高质量产品并将其发布给客户的工具。规划还要求有效分配和利用可用资源，以防止浪费并确保产品的高效构建。
你有多种选择来概述你的计划，其中之一是使用发布管理清单。流程中的角色和职责应按时间顺序列在清单中。你的团队查看清单时，他们应该能够轻松确定自己当前处于哪个阶段以及在流程中所承担的任务或职责。为了制定一个稳固的发布计划，你可以与开发和运营团队开会，讨论需求、障碍以及克服这些障碍的策略，包括最有效实现目标的方法。如果有疑问，可以让客户参与讨论。
设计和构建
在策略完成后，下一步就是设计和开发产品。针对这些特定需求制定的计划和策略现在可以付诸实施。为了完成这一步，程序员需要编写代码，这些代码最终将转化为你计划添加到产品中的功能或特性。
这个阶段在整个发布周期中可能会多次重复，就像 DevOps 中的持续开发策略一样。在开发人员完成代码编写后，可能会出现许多需要测试的问题、错误和缺陷。在最终接受之前，代码将进行多轮测试。开发人员应得到需要解决和优化的问题列表，以便他们能够优先处理待办事项并开发出按预期运行的软件。Bug 跟踪工具（如 FindBugs、Eslint 和 Sonarlint）可以帮助实现这一目标。
测试
如前所述，代码测试是必要的，以确保没有错误或缺陷会影响软件的功能、速度或安全性。手动测试比不测试要好，但在可能的情况下，应实施自动化测试。
功能测试和非功能测试有时被错误地用作可互换的概念。如第一章所述，可以执行许多不同类型的测试，通常它们都属于这两类之一。当发现问题时，代码会被送回开发人员，以便他们修复问题并重新提交代码以进行进一步审查。
用户验收测试是发布软件产品给最终用户之前的最后一步，在此期间，客户将验证其是否满足需求并按预期运行。接下来的步骤取决于用户的验收情况。否则，将根据用户的反馈修改代码，然后进行进一步测试再发布。
部署
在软件开发团队确认产品已经按照规格开发且无错误后，他们将准备将其发布给公众或部署给客户。
此外，QA 团队将负责执行最后的测试，以确保成品满足所有产品发布计划的业务需求和最低标准。然后由管理层或产品负责人审查，以确保产品可以发布。
在这一点上，帮助其他开发人员理解软件和学习如何使用的软件文档已经完成。此外，团队完成了所有必要的文档，以将成品移交给客户。除此之外，公司还应考虑为客户或员工提供关于如何使用新产品的培训，以便他们能够高效地使用它。
部署后
无论发布是为内部使用还是为客户开发的，其相关任务都不仅仅限于部署阶段。无论软件的当前效率和功能如何，定期维护都是必要的，以确保最佳性能。
此外，安全问题随时可能发生。当这种情况发生时，可能会对公司及其声誉造成毁灭性影响。许多不同的事情可能会影响你的软件，导致性能问题、崩溃、安全漏洞、可用性问题等。因此，即使软件已经向终端用户开放，你也不应停止对其进行监控。你需要留出一些时间来调查系统的性能、安全性、可用性和稳定性，以识别并解决问题，在它们影响用户之前进行修复。
从最初的构思到最终的部署和维护，这就是发布管理过程的样子。
总结
现在我们已经到达本章的结尾，让我们快速回顾一下本课的主要收获。你现在了解了发布管理的含义及其历史。
理解你在发布管理过程中的位置至关重要。你应该从定量和定性两个方面来分析这一点。收集一些基本数据，例如平均发布时间、发布的类型和优先级、错误的数量以及延迟发布的次数，是定量分析过程中的一个重要步骤。这些数据用于确定性能基线以及当前的发布管理状态。在信息质量方面，与参与发布管理过程的人进行交谈，特别是在开发与运营互动的领域，了解他们的想法。他们能够指出数据和统计中未能清晰反映的实际情况。
建立定期的发布周期可以创建一致性，使你能够更好地控制发布管理任务和职责。与其一开始就着重建立文化，不如实施轻量级的发布流程。这样，你可以在早期阶段设置发布的基础设施，进行测试，并根据需要进行调整。随着时间的推移，最有效的流程将最终成为你组织的标准。在完成最初的研究后，你将更有能力启动更严格的质量标准并提高效率。减少停机时间和回归测试是减少发布对用户影响的两种方法。在那时，你还可以开始考虑规范化和自动化程序，例如测试和验证，这两个步骤在开发过程中都至关重要。
真正的协作性发布管理文化需要时间来成熟，并且需要良好管理的基础设施作为成熟的基础。你可以通过投资团队和发布管理工具以及方法来培养这种文化，这些工具和方法使人们能够以整体视角看待发布管理过程的每个阶段。这两种类型的投资将帮助你建立卓越的文化，并使工作更具可见性。
本章到此结束。在本章中，我们从文化和技术角度了解了什么是发布管理。然后，我们探讨了发布管理的简史以及各种模型随着时间的推移如何出现。最后，你了解了任何发布管理模型应具备的六个标准阶段。
在第三章中，我们将深入探讨最常见的发布管理模型的机制。这里要指出的一个重要观点是，如果你不熟悉之前的发布管理模型，几乎不可能完全理解 DevOps 的意义。
