Practice_Release management 发布管理实践
本帖最后由 FYIRH 于 2022-8-10 17:29 编辑返回 ITIL 4理论与实践整体知识体系中文版发布文件汇总
最新消息：本实践中文翻译发布版已经推出，请点击 http://ITIL-foundation.cn/thread-140678-1-1.html 下载。
需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“发布管理”即可。
发布管理实践确保可使用符合组织及其服务使用者之间的组织的政策和协议的服务。
传统上，服务组件对用户是可见的，并且可供用户访问，包括基础结构，软件和文档。随着基础架构和文档越来越数字化，软件管理的方法和方法变得更加适用于这些类型的服务组件。这会影响发布管理实践和其他实践，而这些实践的重点是服务，验证和测试，部署管理和软件开发和管理等软件。
从客户和用户的旅程角度来看，发布管理支持引入和撤销。对于用户而言，此实践可能支持最早的接触点并与服务提供者进行交互。初始引入完成后，此实践支持交付服务更新，这对于实践的成功至关重要。
2.2 关键术语和概念
2.2.1 发布管理和部署管理
组织应该在组织的价值流和服务关系中为发布和部署管理实践及其角色定义高级方法。
一种方法是将发布和部署活动结合在一起。一旦移至运行的环境，服务组件便可供用户使用。运行环境中一个组件的不同版本共存的情况很少，并且不会持续很长时间。发布和部署活动（以及生产生命周期的步骤）之间没有明确的边界。这种方法通常可以应用于硬件服务组件和大型整体软件系统。
另一种方法适用于Agile 数字化环境，现代架构和基于云的数字化解决方案。通过这种方法，可以在发布活动启动之前将新版本的软件部署到运行环境，然后再发布给所有或部分用户。在这种情况下，发布管理活动专注于启用服务的使用，并且可以非常简单和技术化（例如，在存储库中更改XTC64211的状况，以便可以下载）。
（由选定的受众群体）或复杂且以人为中心的内容（例如培训用户以降低风险并增加版本对版本的更改）。
CI / CD和发布管理
敏捷和DevOps中部署的关键概念是持续集成，持续交付和持续部署。Martin Fowler 将它们定义为：
• 持续集成通常是指在软件开发环境中集成，构建和测试代码。
• 持续交付扩展了该集成，涵盖了生产部署的最后阶段。持续交付意味着内置的软件可以随时发布到生产中。
• 持续部署是指通过流程并自动投入生产的更改。这样可以每天进行多个生产部署。持续交付意味着可以进行频繁部署，但是部署的决定要视具体情况而定，这通常是由于企业更喜欢部署的速度较慢。持续部署要求完成持续交付。
在组织中，使用持续部署和管理作为单独的实践发行是普遍且有效的。新版本的软件，文档和数字化基础结构一准备就绪，便会立即部署到实时环境中，然后使用发布管理实践为用户“打开”它们。
如果使用不带持续部署的持续交付，则部署和新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
最后，如果组织不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
组织根据生产定义所有产品和服务的发布和部署管理实践的方法。这通常由组织的生产架构（及其跨产品的一致性）和组织对软件生命周期的管理的定义。
2.2.2 发布管理的方法，模型和计划如果组织管理不同的架构产品，则可能会定义发布管理的几种方法。一旦为特定的生产达成协议，就可以开发特定于生产的发布管理模型。模型包括但不限于：
● 商定的高级方法
● 针对用户的发布对象和用户启用规则
● 发布单位和包装规则
● 推/拉条件
● 验证和客户或用户体验旅程
● 假设，验证和实验的发布使用条款。
生产可能有多个发布管理模型。例如，当使用生产在不同市场上或向业务和单个服务消费者提供服务时。
影响发布管理，模型和实践的开发的因素之一，是生产的组织的控制范围。当组织的控制是完整的生产生命周期（包括开发和部署）时，它在定义发布管理模型方面拥有更大的自由度。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常会引入组织应该考虑的约束。它仍然可以决定是否在其服务中包括更新的组件，但是只能在一定程度上进行决定（直到组件的供应商允许继续使用以前的版本）。
2.2.3 发布单位
发布单元可能包括不同类型的软件组件，用户设备以及其他硬件，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户发布的发布注释；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
某些发布实例可能包含不完整的发布单元，但应作为一个例外：发布紧急（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。版本面向用户，发布的统一定义取决于服务的哪些组件通常会影响用户使用服务和用户体验的能力。
2.2.4 推/拉条件
发布管理模型的开发期间做出的决定之一是将服务组件的新版本推向用户，由用户拉动还是将多种方法混合使用。
“推”式方法意味着在未经用户特定许可的情况下为用户启用了新的或更改的服务组件，并且用户必须使用这些版本。相比之下，“拉动”方法为用户提供了新的组件和服务，但是用户可以决定是否更喜欢使用这些新版本，坚持使用较旧的版本或根本不使用服务。
通常，组织不会采用单一方法。相反，他们定义了“拉”或“推”方法更好地工作的条件。注意事项对于内部和外部服务提供是通用的。这包括：
● 在用户基座上只有一个版本的好处（可维护性，兼容性）
● 允许用户拥有更多自由的好处（更好的图像，灵活的定价选项）
● 技术和组织能力来管理运行环境中的多个版本
● 关键更改（删除关键安全脆弱性的更新可能会被“推送”）
● 职能型和其他客户的要求（如果实现了必需的新功能，则客户可以要求所有用户进行更新）
● 监管要求。
2.2.5 假设测试和实验
发布管理可用于验证假设和实验。当具有样本用户受众的组织需求到测试成为假设时，可以将可测试的服务发布到样本组（有时称为治疗组）。这种方法已被大众服务提供商（例如社交网络）广泛使用，但也适用于小型用户组。相关技术包括蓝色/绿色发行版，金丝雀发行版和A / B测试。
这些实验需要其他实践的参与度。这包括但不限于：
● 基础设施和平台管理
● 软件开发和管理
● 部署管理
● 架构管理
● 服务台
● 事件管理。
The release management practice ensures that services are available to use in line with organization’s policies and agreements between the organization and its service consumers.
Traditionally, service components are visible and accessible for users including infrastructure, software, and documentation. As infrastructure and documentation are increasingly digitized,software management methods and approaches become more applicable to these types of service components. This affects the release management practice and other practices with significant focus on software such as service validation and testing, deployment management, and software development and management.
From the customer and user journey perspective, release management supports onboarding and offboarding. For users, this practice may support the very first touchpoints and interactions with the service provider. After initial onboarding is complete, this practice supports the delivery of service updates, which is important for the success of the practice.
2.2 KEY TERMS AND CONCEPTS
2.2.1 Release management and deployment management
Organizations should define a high-level approach to release and deployment management practices and their role in organization’s value streams and service relationships.
One approach is to combine release and deployment activities; once moved to the operational environment, service components become available to users. Co-existence of different versions of one component in live environment is rare and does not last long. There is no clear border between release and deployment activities (and steps of a product lifecycle). This approach can often be applied to hardware service components, and large monolithic software systems.
Another approach is applicable to the Agile digital environment, modern architecture, and cloud- based digital solutions. In this approach, new versions of software can be deployed to the live environment before release activities start, and then released to all or some of the users. In this case, release management activities are focused on enabling service usage and can be very simple and technical (such as changing application’s status in a repository so it is available for download
by a selected audience), or complex and human-focused (such as training of users to reduce risks and increase effectiveness of the version changes).
CI/CD and release management
The key concepts for deployment in agile and DevOps are continuous integration, continuous delivery, and continuous deployment. Martin Fowler defines them as:
• Continuous integration usually refers to integrating, building, and testing codes within the software development environment.
• Continuous delivery extends this integration, covering the final stages for production deployment. Continuous delivery means that built software can be released to production at any time.
• Continuous deployment refers to the changes that go through the process and are automatically put into production. This enables multiple production deployments a day. Continuous delivery means that frequent deployments are possible, but deployment decisions are taken case by case, usually due to businesses preferring a slower rate of deployment. Continuous deployment requires that continuous delivery is being done.
In organizations, using continuous deployment management for releases as a separate practice is common and effective; new versions of software, documents, and digital infrastructure are deployed to live environments as soon as they are ready, and then release management practice is used to ‘switch them on’ for users.
If continuous delivery is used without continuous deployment, deployment and new and changed release components may be synchronized and managed as a single step in respective value streams.
Finally, if an organization does not use continuous delivery or continuous deployment, release management activities are more likely to be combined with deployment management.
Organizations define the approach to release and deployment management practices for all products and services, or per product. This is usually defined by organization’s product architecture (and its consistency across products), and by organization’s approaches to management of software lifecycle.
2.2.2 Release management approaches, models and plans
If an organization manages different architecture products, it is likely that several approaches for release management will be defined. A product-specific release management model can be developed once an approached is agreed for a specific product. This model includes, but is not limited to:
● agreed high-level approach
● target user audience of releases and rules for user enablement
● release units and packaging rules
● push/pull conditions
● verification and acceptance criteria
● terms and conditions of release usage for hypothesis verification and experimentation.
It is possible to have more than one release management model for a product. For example, when a product is used to provide services on different markets or to business and individual service consumers.
One of the factors that is affecting the development of the release management model and the practice, is the organization’s scope of control of the product. When organization’s control the full product lifecycle, including development and deployment, it has more freedom in defining release management models. In contrast, if the organization’s services are based on third-party components, or the development and deployment are managed by a supplier, it usually introduces constraints that the organization should consider. It still may be able to decide whether to include updated components in its services, but only to a certain extent (until components’ vendor allows to keep using previous versions).
2.2.3 Release units
Release units may include different types of software components, user equipment, and other hardware, documents. Release unit for the initial release of a service to new users, can be different from release unit for updates of the same service. However, some combinations of components may be recommended or even mandated. For example, every update should include published release notes for users; however, in some cases, user equipment should be updated after its initial release to users.
Some release instances may include incomplete release units, but should be an exception: either a release is urgent (emergency update), or too complex and an impractical release unit has been defined.
It is important to remember that a release unit may be different from a deployment unit, which defines components that are normally deployed together. Releases are user-facing, and the definition of a release unite depends on which components of service affect users’ ability to use the service and user experience in general.
2.2.4 Push/pull conditions
One of the decisions made during the development of the release management model is whether new versions of service components will be pushed to users, pulled by users, or there will be a mix of the approaches.
A ‘push’ approach implies that new or changed components of services are enabled for users without their specific consent, and users are obliged to use these versions. In contrast, the ‘pull’ approach makes new components and services available to users, but users can decide whether they prefer using these new versions, stick to older ones, or not using the service at all.
Typically, organizations do not apply a single approach; instead, they define conditions where the ‘pull’ or ‘push’ approach would work better. Considerations are common for internal and external service provision. This includes:
● the benefits of having a single version across the user base (maintainability, compatibility)
● the benefits of allowing users to have more freedom (better image, flexible pricing options)
● technical and organizational ability to manage multiple versions in a live environment
● critical changes (an update removing critical security vulnerability is likely to be ‘pushed’)
● functional and other customer’s requirements (if a required new functionality is implemented, customers may mandate the update for all users)
● regulatory requirements.
2.2.5 Hypothesis testing and experimentation
Release management may be used to validate a hypothesis and an experiment. When an organization needs to test a hypothesis with a sample user audience, testable services may be released to sample groups (sometimes called treatment groups). This approach is widely used by providers of mass services, such as social networks, but also applied to small user groups. Related techniques include blue/green releases, canary releases, and A/B testing.
These experiments require the involvement of other practices. This includes, but not limited to:
● infrastructure and platform management
● software development and management
● deployment management
● architecture management
● service desk
● incident management.
申明：
本文档由长河（微信achotsao）在机译的基础上经初步整理而成，精细化翻译工作正由ITIL培训基地组织的ITIL专家团队进行之中，预计将于2020年年底之前全部完成。需要下载最终翻译版本请关注微信公众号：ITILXF，或访问www.ITIL4hub.cnorITIL-foundation.cn。
ITIL培训基地专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
发布管理实践
发布管理实践
页:
[1]