Software modernization, particularly in complex organizations, today requires an approach in which DevOps release management is central.
Over the years, the development of activities has evolved thanks to the success of application platforms. The term “platform” can be applied to various situations, such as office solutions or finance. By this term, Sorint.lab means a group of applications operating in the same domain, receiving huge benefits from the innovative DevOps approach, which addresses the software lifecycle by merging development and operation teams.
Sorint.lab is aimed at a universe of medium/large companies, for which it sets up and manages a software life cycle and modern, future-oriented change management. The central fulcrum of this activity is release management.
In developing a new project, a first distinction relates to the degree of maturity of the company towards software development. The difference is between companies that have a culture and/or tools that have already been active for a long time, and between organizations that have a free hand in the architecture to be developed.
In the first case, an incremental approach is defined that starts from what is there and gradually evolves towards a modern approach.
In the second case, however, a workflow is defined and automated.
The first case occurs frequently, but after an initial assessment it is directed towards a structuring which gradually becomes similar to the second case.
A case study: platforms for a bank
It is very common to be directly in the second case, where the company puts itself in conditions of maximum freedom.
A real-life case addressed by Sorint.lab involves a large Italian bank that decided to overhaul the way it thinks, makes, and releases software. 8 platforms have been developed, a large number that measures the size of the bank in question. Each platform is made up of a certain number of microservices which in turn are based on home-made libraries. The release method is of the type “assisted continuous delivery”: each platform provides a new release every 15 days, and since there are 8 platforms there is a new release approximately every two days.
In this article we see what happens in the second case, the one in which we start from scratch.).
DevOps from onboarding to versioning
In the traditional approach to software development, the central part was an equally traditional document which in fact also sanctioned the separation between dev activities and ops activities, preventing the release in continuous integration and continuous delivery, CI/CD for short.
With the DevOps approach, this separation has been eliminated, but without losing track of what is being done. Of course, there is no longer an overall document, but that information is divided into two parts: the initial onboarding document and the incremental versioning document (with associated accountability guidance).
The centrality of devops release management
DevOps release management deals with governance, which consists of ensuring coordinated, semi-automatic and verifiable collaboration between devs and ops. The ultimate goal is the acceleration of delivery, always documented and controlled.
To achieve the desired results, a complete collaboration cycle must be achieved that ensures all phases, including by resorting to automation. Communication and release must take place in computer mode, not as in the past when an integrated system was missing and most contacts took place by e-mail or telephone.
In the experience of Sorint.lab, however, the start of the project is best developed with one or more face-to-face meetings, or at most on video. This is where objectives and functions are specified. In theory, even one or more start-up phases can be developed with asynchronous collaborative tools and not in person, but it is reasonable to think that this is not the way to obtain the best results.
Multi-pipeline is served
Once objectives and functions have been established, we can move on to the implementation of the agreed development and release workflow. Sorint.lab implements highly engineered solutions and processes for end use to be simplified and guided. The first stage is the onboarding of new applications/microservices which results in the census of project specifications in a dedicated and versioned file. In the second phase, depending on the configurations, a pipeline is activated with the appropriate languages, workflows, automations and everything that is required for the specific project.
Contact between dev and ops is implemented with two essential tools: a sharing space for the steps leading to approvals and a control tool that carries out automatic end-to-end testing.
A relevant part of the project KPIs is collected and compared at this stage. At the end of the cycle, the specific release is approved (OK) or rejected (KO), with rollback to the previous version. And that’s it.
Conclusions: competitiveness today and tomorrow
The evolution of software leads to information systems divided into complete platforms to rely on from the beginning to the end of the specific task. The transition from monolithic solutions to tailor-made platforms passes through the division of each platform into microservices, components that are easy to handle and for which constant updating is required which does not create problems for the activity of the other services. DevOps release management deals with the governance of the continuous development process, keeping under control the results that impact present and future activity.