The responsibility of the product owner is to set the release requirements. The result of the team's work will depend on the competent and clear statement of these release requirements. After all, the development and testing teams will follow the requirements set by the product owner in charge.
The quality manager has a very important role to play. It is his responsibility to ensure that the acceptance criteria is met with the requirements set by the product owner. This enables the accuracy of the tests, as well as the minimization or elimination of false positives. All of it is the responsibility of a quality manager specialist. Additionally, it also notifies the development team about bugs.
DevOps is a very important part of the entire company. Experts are involved in setting up continuous integration and deployment. With these settings, developers can iterate efficiently. The testing department will also have the assurance in these tests. So, they know that tests from the development phase are carried over to the production environment. The DevOps team ensures the quality availability for a production deployment. This can reduce the time spent on new deployments.
Release Management Best Practices
As stated above, release management continues to evolve in parallel with the evolution of technologies. Therefore, we can say that it is impossible to single out a single clear process as a best practice. Even though release management is an important part of the SDLC. Each company adjusts the process itself based on their requests and needs. All of these practices can be used in companies implementing DevOps. Let’s consider a few basic traits of them.
ITIL - IT Infrastructure Library
Many people define ITIL as a methodology aimed at debugging, improving and managing an IT business. As a library, ITIL offers a varied collection of books on IT Business Process Management. ITIL is the most widely used IT service management guide. ITIL's focus is on integrating business and IT. The ITIL library consists of the ITIL core. This is a guide to using the leading experience for companies providing services to business. In addition, there are many diversified tutorials in the library. It provides more constructive comments on specific industries and operating models. At the core of the library, there are 5 books on services. These books are about strategy, design, transformation, operation and continuous improvement. Each of the 5 books is a guide to providing release management services. The books explain processes such as planning, monitoring, implementing, operating, maintaining and improving.
ITIL version 3
The third edition was released in 2007. It has completely redesigned and reorganized sections. The goal was to support the new service lifecycle format approach. The third version also contains 5 books. 4 functions are in-service operations. This includes the management of applications, technologies, operations and the Service Desk
ITIL version 4
This is the latest version released by AXELOS Ltd. Version 4 focused on capitalizing on changing technologies. The prioritized component of the 4th version of the framework is the Service Value System and the 4 dimensions model. The utmost vital component of ITIL defines the service value chain. This is a sequence of actions that must be performed, in order for a company to provide a valuable and effective project or service.
The service value chain includes planning, improvement, interaction, design, assembly and support.
In addition to the value chain, ITIL also has a service value chain - SVS. It is a combination of activities that provide a model for developing, delivering, and maintaining services.
Release Management in DevOps
Release management is important in DevOps as it involves developing a non-stop process in a production environment. This is what DevOps as a service strives for, by aligning work within the company and the organization. However, DevOps release management is different from other practices. Companies that implement DevOps are also implementing continuous integration. Most often, continuous integration is implemented in tandem with continuous deployment. However, release management only uses continuous integration. This maintains the level of centralization. The release policy supports the RASCI requirements -a requirements definition matrix.
DevOps focuses on loop improvements through constant feedback. The approach is also focused on reducing software changes, to shorten the risk of interruption. It is also worth noting the typical processes for DevOps. Namely, automation at all levels - integration, assembly, and testing. This affects the reduction in human resources at each release. The release management team works with product owners. Whilst the product owner acts as a liaison between the business, development, and product.
This is a noted project management technique. It implies an even transition between stages without having to revert back to previous steps. Moreover, the transition to a new stage is possible only if the previous one is completed. This approach works perfectly when the software requirements are well defined in advance. This approach implies 6 stages (or more) of software development:
- Definition of product requirements
- Analysis in the form of models and business plans
- Product design: both external components and product logic
- Writing program code
- Software testing, product check for defects
- Operations: adaptation for different operating systems, product updates. Also, improvement and updating of functionality, technical support
Furthermore, the advantage of this practice is simple - it is within the uncomplicated structure of the software development process. Clear reporting that makes it easy to track requirements, risks and challenges. Goals and objectives are set at the very beginning of the project and do not change during the work on it.
Although, the lack of flexibility may be one of the main disadvantages... Because you often have to fix bugs after release. This then brings huge financial expenses and time costs. Also, there is no way to optimize the project in any way after the work has begun.