Release Policy Planning (Part 3)
By Laurent Duenas, March 15th 2013
Possible ways for Release Policy
The complex part is to succeed in building coherent Release Units mixing application and infrastructure components, relying on a common schedule. This can rapidly turn out to be a puzzle, given the few links between for example change frequency on workplaces (physical or virtual) and on an application. Moreover, this association can turn out to be totally impossible because most of the time, infrastructure changes are transverse and force all businesses to evolve together. So, there is no other alternative but to have groups of components evolve according to various cycles.
Various approaches can be considered, from the most simple to the most complicated:
Avoid trying to imagine Release Units. The approach is only aimed at identifying release windows at regular dates. Those are used, depending to what extent change carried out has an impact. Change is planned, not according to its nature (infrastructure and application), nor to the IT Service concerned, but according to the number of Services it impacts. The larger the number of Services impacted, the more limited planning must be. The smaller the number of Services impacted, the wider change is possible. This approach lacks flexibility and can turn out to be very binding on change frequencies allowed.
Planning of Approach 1:
Find an alternative to the notion of Release Unit by creating a specific planning for each business, each one (and its Services) following its own pace of evolution, adapted to its constraints. This implicitly means that several infrastructure versions coexist, i.e. businesses that evolved and others. As a result, support is complex and cost higher. On the opposite, this approach can remain an option for distant environments with few shared infrastructures.
Planning of Approach 2:
As Approach 2 has little chance of being applicable within organizations, it is possible to sharpen the notion of windows of opportunity by separating business evolutions from infrastructure evolutions. The first ones are linked to constraints specific to the business, the second ones follow a set up and accepted evolution planning. They can also be adapted according to major types of infrastructures.
Planning of Approach 3:
► No link
Strive to set up Release Units by IT Service. Those integrate application, middleware and infrastructure components as far as they can, to keep the end-to-end vision. When this is not possible, infrastructure components evolve independently of centralized and shared component applications. Change frequency is defined according to business requirements specific to each business deliverable (supported by IT Service). For infrastructures that must be developed independently, change roadmaps are set up to follow actual evolution and corrective requirements, the best way to protect businesses from risks. It is also possible to combine a release unit approach for applications, with a “window of opportunity” approach for infrastructure. The model becomes hybrid.
Planning of Approach 4:
Copyright © 2014 - PRACT Publishing