2 Basic information
2.1 Purpose and description
| Key Information The purpose of release management practices is to make new and changed services and functionality available. |
Release management practices are best practices for ensuring that services are available for the organization and its service consumers in compliance with the organization's policies and agreements.
In traditional scenarios, service components (including infrastructure, software, and documentation) are visible and accessible to users. As the management of infrastructure and documentation becomes increasingly digital, methods and patterns of software management need to become more applicable to these types of service components, and affect the practice of software release and other practices in several key areas, such as service validation and testing, deployment management, software development and management, etc.
From a customer and user journey perspective, release management supports introductions and withdrawals. For users, this practice may support the first touchpoint interaction with the service provider. After the initial introduction is complete, this practice supports updates to service delivery, which is critical to the success of the practice.
2.2 Key terms and concepts
| release Make available a version of a service or any other configuration item or collection of configuration items. |
2.2.1 Release management and deployment management
Organizations should define best practices for release and deployment management and clarify its specific role in the overall organizational value stream and service relationship.
One approach is to combine release and deployment activities. Once the service component is released to the production environment, users can use it. Different versions of the same component in production rarely co-exist, and if at some point, it doesn't last long. There is no clear boundary between release and deployment activities (and the overall lifecycle of a product). This approach is typically applied to hardware service components and large stand-alone software systems.
The other works well with agile development patterns, modern architectures, and cloud-based solutions. With this approach, a new version of the software can be deployed to the production environment before the release campaign starts, and then released to some or all users. In this case, the release management activities only need to focus on enabling the service, and the purpose of the release can be easily achieved (for example, changing the state of the application in the repository, the specified user can perform the download operation), Also reduce the failure rate of complex manual operations (for example, training users to reduce risk and increase the effectiveness of releases).
| CI (Continuous Integration) / CD (Continuous Deployment) and Release Management Key concepts for deployment in Agile and DevOps include continuous integration, continuous delivery, and continuous deployment. Martin Fowler defines them as:
It is common and effective in organizations to use continuous deployment management of releases as a separate practice. New versions of software, documentation, and digital infrastructure configurations are deployed into operational environments as soon as they are ready, and then "turned on" for users using release management practices. If using Continuous Delivery without Continuous Deployment, deploying new and changed release components can be synchronized and managed as a single step in the corresponding value stream. Finally, release management activities are more likely to be used in conjunction with deployment management if the organization is not using continuous delivery or continuous deployment. |
The organization defines release and deployment management practices for all products and services or for each product. This is usually defined by the organization's product architecture (and its consistency across products) and the organization's approach to software lifecycle management.
2.2.2 Release management methods, models and plans
If an organization manages different architecture products, it may define different release management methods. Once a specific product is agreed upon, a product-specific release management model can be developed. This model includes but is not limited to:
- Agreed high-level method
- Set rules for users and publishing objects
- Publishing Units and Packaging Rules
- push/pull condition
- Verification and Acceptance Criteria
- Published Terms of Use for Hypothesis Validation and Experimentation
A product may have multiple release management models. For example, when a product is used to provide services in different markets, or for business and personal service consumers.
An organization's extent of control over a product is one of the factors that influences the development and practice of a release management model. When an organization controls the entire product lifecycle, including development and deployment, it has more freedom to define a release management model. Conversely, if an organization's services are based on third-party components, or if the development and deployment are managed by the vendor, this typically introduces constraints that the organization should consider. Organizations can still decide whether to include newer components in their services, but only to a certain extent (depending on whether the component's supplier allows continued use of legacy versions).
| Publication Unit A predefined collection of CIs, or portions of CIs, that is the base size for a publication to contain. |
2.2.3 Release unit
A release unit may include different types of software components, user equipment and other hardware resources, documentation. For new users, the publishing unit used for the initial publishing of a service may be different from the publishing unit used for updating the same service. However, certain combinations of components may be recommended or even mandated. For example, each update should include version release notes for users; however, in some cases, user devices should be updated after users initially use the release.
Some release instances may contain incomplete release units, but such cases should be treated as special cases: such as urgent releases (emergency updates), or release units that are too complex and impractical to have been defined.
It's important to remember that a release unit may be different from a deployment unit, which defines components that are typically deployed together. The release is user-oriented, and the definition of the release unit depends on which components of the service will affect the user's use of the service and the user's experience.
2.2.4 Push/Pull Conditions
One of the decisions that needs to be made during the development of a release management model is whether to push new versions of service components to users, to have users pull the latest version, or to use a mix of approaches.
The "push" approach means that new or changed components of the Service are enabled for the user without the user's specific permission and the user must use those versions. In contrast, the "pull" approach provides users with new components and services, but users can decide whether to use the new version or stick to the older version, or even not use the service directly.
Often, organizations don't take a single approach. Generally, a "pull" or "push" method is defined to better meet the working conditions. There is a lot of affinity for both internal and external users. This includes:
- Use a single version across the user base (maintainability, compatibility)
- More flexible user experience (better visualization, flexible pricing options)
- Provide the technical and organizational capabilities to manage multiple versions in an operational environment
- Critical changes (serious security bug updates are more suitable for "push" mode)
- Functionality and other customer needs (customer can ask all users to update if required new functionality is implemented)
- regulatory requirements
2.2.5 Hypothesis testing and experiments
Release management can be used to validate hypotheses and experiments. When an organization needs to test a hypothesis with a sample population of users, a testable service can be released to that sample group of users (sometimes called a treatment group). This approach is widely used by mass service providers such as social networks, but is also suitable for small user groups. Related techniques include blue/green releases, canary releases, and A/B testing.
These experiments require the participation of other practices. This includes but is not limited to:
- Infrastructure Platform Management
- Software Development Management
- deployment management
- Architecture management
- desk
- event management
2.3 Scope of practice
The scope of release management practices includes the following:
- Develop and maintain the organization 's release method for new and changed services and components1
- Manage and coordinate all release instances in accordance with a defined methodology during the stages of planning, implementation and review
There are many activities and areas of responsibility that are closely related to release management but fall outside the scope of the practice.
Some of these key areas are listed in Table 2.1, which includes references to this practice. Importantly, ITIL practices are collections of tools used in the value stream and they should be combined as needed depending on the situation.
Table 2.1 Release-related activities described in other practice guidance
| realize value | practical guide |
| Authorization for Changes/Releases | change support |
| Deploy new and changed components and services in the runtime environment | deployment management |
| software development | Software Development and Management |
| Develop and build infrastructure components | Infrastructure and Platform Management |
| User training support and operation and maintenance staff training | Workforce and Talent Management |
| Test and validate services and service components | Service Validation and Testing |
| Naming and versioning of service components | Service configuration management |
| Manage organizational changes associated with mass releases | Organizational Change Management |
| Manage projects | project management |
2.4 Practical success factors
The PSF is not just about tasks or delivering value, as it contains all the components of the service management 4D model. in practice,
| A practice success factor (PSF) is a complex set of functions necessary for a practice to achieve its purpose. |
The nature of PSF activities and resources may vary, but together they ensure that the practice is effective.
Release management practices encompass the following PSFs:
- An organizational approach to establishing and maintaining an effective set of services and service component releases
- Ensure effective publishing of services and service components within the context of the organization's value streams and service relationships
2.4.1 Establish and maintain an effective methodology for the release of services and service components in the organization
Release management practices include methods and models for establishing releases for new and changed services and service components. Organizations may combine approaches and define multiple release management models for each product they manage.
In addition to organization and product information, publishing models are defined by service relationships between organizations and their service consumers. These include the following factors:
- internal or external service consumer
- Personal or corporate service consumption
- Out-of-the-box or tailor-made services
For more details on how these factors affect service, see ITIL®4: Driving Stakeholder Value.
The approach and model of release management should allow some flexibility to adapt to changing circumstances such as scale, urgency or complexity. Each publish instance can be scheduled based on an agreed-upon model that reflects the details of the publish instance.
Published methods, models, and general practices should be subject to continuous improvement, continually finding ways to eliminate waste and increase effectiveness and efficiency.
2.4.2 Ensure that the release of services and service components is valid in the context of the organization's value streams and service relationships
To ensure efficient release, resources may need to be organized across all service management 4D models.
Depending on the release management model, the activities and resources required to implement a release instance vary widely:
- Release a new version of the mobile application for all users in a country, which can be performed by changing the previously deployed software version, related release notes, and user documentation; and notify stakeholders within the service provider organization without taking action further action.
- The installation, release, and upgrade of user equipment of a new custom ERP system can be managed as a large project involving many teams and practices inside and outside the organization.
Regardless, effective collaboration, the use of automation, and planning with a good release model from the early stages of the software lifecycle are critical to the success of a release.
Practices focus on identifying tasks and coordinating participants, and providing advice on the procedures and techniques used in the release process. Therefore, in the implementation process, it is necessary to effectively combine practice and team collaboration.
Effective coordination of software development and management, infrastructure and platform management, deployment management, service validation, and test and release management is especially important.
2.5 Key Indicators
The effectiveness and performance of ITIL practices should be evaluated in the context of the value streams each practice contributes to. As with any tool's performance or effectiveness, it can only be evaluated within the context of its application. However, the design and quality of tools can vary widely, and these differences define the different capabilities of tools during use.
The same is true for practices, whose effectiveness should be assessed in the context of the value stream, but whose capabilities are determined by the design and quality of the resources. See the Measurement and Reporting Practice Guide for metrics, key performance or performance indicators (KPIs) and other techniques that can help achieve this goal.
Key metrics for release management practices are mapped to PSFs. They can be used as KPIs in the context of value streams to assess the contribution of release management to the effectiveness and efficiency of these value streams. Some examples of key indicators are given in Table 2.2.
Table 2.2 Examples of Key Indicators for Practice Success Factors
Proper selection of metrics and aggregation/categorization of metrics into different combinations/layers makes it easier to manage them on an ongoing basis and apply them to value streams, regular assessments and continuous improvement of deployment management practices.
There is no single best solution; metrics will be defined based on the overall context of the organization, the service strategy and priorities of the organization, and the goals of the value stream to which the practice contributes.
3 Value streams and processes
3.1 Contribution of value stream
Like other management practices in ITIL, release management contributes to multiple value streams. Importantly, a value stream is never formed by a single practice. Release management practices work in conjunction with other practices to provide high-quality service to consumers.
The points at which release management practices contribute to the service value chain are shown in Figure 3.1.
Figure 3 1 Heat map of the contribution of release management to the value chain
The main value chain activities to which the practice contributes are:
- plan
- design and conversion
- get or build
- Delivery and Support
3.2 Process
| A process is a set of interrelated or interacting activities that transform inputs into outputs. A process takes one or more defined inputs and transforms them into defined outputs. A process defines the sequence of execution of actions and their dependencies. |
Each practice may contain one or more processes and activities that may be necessary to achieve the practice's objectives.
Release management practices form two processes:
- release plan
- release coordination
3.2.1 Release Planning
The process focuses on the development of release methodologies, patterns, and complex release instance methods, as well as the continual improvement of release management practices. It is performed on a regular basis and triggered by events or requests, with periodic reviews every two to three months or more frequently depending on the effectiveness of the model and procedures. The process includes the following activities and transforms the following inputs into the outputs shown in Table 3.1.
Table 3.1 Input Activities and Outputs of the Release Planning Process
Figure 3.2 shows the workflow of the process
Figure 3.2 Workflow of the release planning process
Table 3.2 provides examples of process activities
Table 3.2 Examples of Release Planning Process Activities
3.2.2 Release coordination
The process includes the activities shown in Table 3.3 and transforms inputs into outputs.
Table 3.3 Inputs, Activities and Outputs of the Release Coordination Process
Figure 3.3 shows a flowchart of the workflow
Figure 3.3 Workflow diagram of the release coordination process
Table 3.4 shows the release coordination process activities.
Table 3.4 Release coordination process activities
4 Organization and personnel
4.1 Roles, competencies and responsibilities
The practice guide does not describe the roles of practice management, such as practice owner, practice leader or practice coach. Practical guides focus on hands-on experience in each specialized role. Roles may be named differently in each organizational structure, so any recommended roles defined in ITIL are not mandatory. Remember, roles are not jobs. One person can assume multiple roles, and one role can be assigned to multiple people.
Roles are described in the context of processes and activities. Each role has a capability profile based on the model shown in Table 4.1.
| Capability code | describe |
| L | Leader Makes decisions, delegates authority, oversees other activities, provides motivation and motivation, and evaluates results |
| A | Administrator Assigns and prioritizes tasks, keeps records, reports on an ongoing basis and initiates fundamental improvements |
| C | Coordinator/Communicator Coordinate multiple parties, maintain communication among stakeholders, and conduct outreach activities |
| M | Method and techniques expert Design and implement job techniques, cultural procedures, process consulting, job analysis and continuous improvement |
| T | Technologist Provides technical (IT) expertise and performs assignments based on expert experience |
Table 4.1 Capability code and information
The practice of release management in an organization has a specific role: the release manager. This role is often introduced in organizations that release a large number of products, especially where release actions need to be planned and executed manually. In other organizations, a product or service owner may assume the role of a release manager.
4.1.1 Release Manager Role
Where the release manager role is defined, this role is typically assigned to an expert with in-depth knowledge of the organization's business, products and services, technologies, platforms, frameworks, and processes. This role requires comprehensive planning and project management skills as well as authority to coordinate teamwork.
The competency requirement for this role is AMCT. This role is typically responsible for planning, managing, and coordinating the entire release management practice and individual release instances, including:
- Review and develop release methodologies and models
- Facilitate adoption of approved release management methodologies and patterns across the organization
- Planning complex publishing methods
- 管理和传达发布日程
- 确保实践与其他实践保持一致性和协调性
- 审查并不断开发新实践
在某些复杂的组织中，发布经理的部分职责可能委派给发布协调员。
4.2 发布管理中涉及的角色活动
表4.2中列出了发布管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
表4.2 发布管理活动涉及的角色示例
4.3 组织架构和团队
只有在发布任务量巨大，或发布场景复杂的组织中，才适合建立指定的发布管理团队。大多数情况下，发布管理不需要专门的团队，只需建立临时的项目团队，或者将发布管理实现高度自动化就可以满足需求。
但是，在许多情况下，发布经理的角色仍然有用。该角色可以充当教练，以确保发布实践被整个组织采用。根据组织对发布管理的处理方式，此角色可以与部署经理的角色结合。
5 信息和技术
5.1 信息交流
发布管理的效果取决于所使用信息的质量。该信息包括但不限于以下信息：
- 生产架构
- 服务消费组织和用户
- 软件开发和管理实践
- 计划的和正在进行的部署
- 正在进行和过去的事件
- 新兴的发布管理技术
该信息可以采用各种形式。实践的输入和输出的详细列表在第3节中列出。
5.2 自动化和工具
在数字化工作环境中的发布管理是高度自动化的。但是，即使在传统环境中，发布管理实践也可以从自动化中显著受益。在表5.1中，有很多可行且有效的解决方案。
表5.1 发布管理活动的自动化解决方案
6 合作伙伴和供应商
只有很少量的服务是完全由组织自己的资源提供的，绝大多数需要依赖于外部服务。这些外部服务通常是由组织外的第三方供应商提供的（请参阅“ITIL Foundation 2.4：服务关系的模式的ITIL 4版）。
As mentioned earlier, the roles played by partners and suppliers are related to the level of control an organization has over its product and service components. When an organization controls the entire product or service lifecycle, including development and deployment, it has greater latitude in making decisions about release management. Conversely, if an organization's product or service relies on third-party components, or if development and deployment is managed by a vendor, then typically, the organization must consider the implications of the constraints introduced. While organizations can decide whether to introduce newer components in their services, there are some restrictions to a certain extent.
Organizations can sometimes outsource some aspects of release management. For example, user communication, marketing of releases, user training, collecting feedback during hypothesis testing, etc. Organizations should properly manage those partner and supplier activities, as they directly impact user satisfaction and payment for the service.
Relationships between organizations may involve various levels of integration and forms. (For more information on the relationship between organizations, see Table 3.1 of the ITIL® Foundation: ITIL 4 Edition). The level of integration with partners in release management depends on the form of collaboration, which should be determined and managed through release management, supplier management, relationship management, service level management, and other related practices.
7 Important Reminders
Much of the Practice Guide should serve as suggestions for different areas that organizations can try when establishing and cultivating their own practices. A practice guide is a catalog of things an organization can try, not a list of answers. Organizations should always follow the ITIL guiding principles when using the content of the ITIL Practice Guide:
• Focus on value
• Start where you are
• Iterative advancement based on feedback
• Collaborate and improve visibility
• Thinking and working holistically
• Keep it simple and functional
• Optimization and automation