The Software Release Life Cycle in DevOps: Why Reinvent The Model?

In my previous and the first article in this series, I presented a new form and model of DevOps and described its essential components and workflow.

Rethinking DevOps: What is it all About?

A new model you can adopt that simplifies how those DevOps tools we talk about can be made and managed by the DevOps community.

Linux HandbookAvimanyu Bandyopadhyay

In this article, I'm going to explore the significance of the release cycle of an application and the important role it plays in our DevOps model.

But before I begin, it is necessary that I briefly recollect a few essential sections from my previous article, particularly SDLC and also re-look into a fact that many of us in the computer science academia might have been inadvertently following for decades.

I'm not going to detail the steps again, as the previous article has already been linked here. But I'll take a look at the SDLC diagram once again in a moment.

Significance of the Software Release Life Cycle in DevOps

The Software Release Life Cycle, or SRLC in short, is a mandatory procedure carried out during the development of any application. It is a crucial necessity because quality software ensures quality DevOps. That can be ensured effectively only when its various phases are progressed efficiently.

The Software Release Life Cycle

A Software Release Life Cycle or SRLC is the sequence of various stages through which a software's development evolves from a pre-alpha phase into a production phase. It is a continuous process because any software will always have its updated version until and unless it reaches end of life(EOL).

The names and practices can vary from developer to developer. But in general, there are five essential phases involved:

1. Pre-alpha: The first phase in software releases that only includes primary functionality and is most likely to have the maximum number of bugs. It is only tested by developers and testers.
2. Alpha: The second phase in software releases is considered feature complete and is still likely to have bugs but much lesser than pre-alpha. It is tested by developers and testers. But depending upon diverse NDAs, it can be made available to the public as well selectively or worldwide.
3. Beta: The third phase is primarily focused on fixing bugs and issues that were encountered in the previous two phases. Like pre-alpha, availability of beta software is also based upon NDAs.
4. Release Candidate: A release candidate version of the software is a pre-release version which has potential to be final stable product. In general practice, a release candidate version no longer receives any new source code to the program. Changes to source code are only made when errors are still encountered when it undergoes production level testing.
5. Production Release: As it's very evident, a production release is the final product that is made available to the general public as a stable product.

Note: The concept of NDAs do not carry much value in the field of Open Source Software because of a transparent model.

Based on our new model, SRLC actually works under two stages:

1. Development Release Stage in ADLC

The application becomes its very first version in this stage and progresses through a majority of release phases(mentioned above) as it becomes more mature and feasible. Bugs are gradually reduced and efficiency increases as time progresses.

2. Stable Release Stage in SDLC

This is the production stage of SRLC where a development release becomes its first available stable version ready for use by clients and users.

Why is it a "Life Cycle"?

For decades, in the academic subject of Software Engineering, the Computer Science curriculum in different universities have mentioned the software release process model as a cycle. But the diagram that is depicted is quite contradictory. Typically, it is described in the following manner:

Based on a simple observation, it is very evident that the diagram above does not show any "cycle-like" properties at all. Based on this conventional model, it's called a cycle even though the diagram shows no such characteristic…it cannot be called a cycle… it's a flowchart.

To make it look like a cycle, the production phase would need to go back to the pre-alpha phase and that would make no logical sense, unless the entire scenario is critically reviewed once again altogether:

You can clearly notice that the stable release is where the software has reached its full potential and capable of deployment in production. Even though it doesn't show in the diagram, why is it then being referred to as a "life cycle"?

Here's the reason

When the production release has been adopted by users/clients, the developers of the software are still making improvements in it by adding more features, tweaking existing ones, fixing bugs and security glitches while in production and any other changes that would be necessary through time. Therefore, there is always a development version consistently at work behind the scenes.

However critically tested a software may be, there are certain flaws that would reveal themselves only in a real world scenario, and these flaws are fixed in the updated version of any production release.

Let us think about it for a moment. Can a production release really be called a final product if the software is continuously under development in the form of updated versions?

How to review the diagram and its scenarios as a real cycle?

To be able to perceive this process as a cycle, we need to revisit our new SDLC model described previously:

If you want to look at it only with a software release perspective, the SDLC model can be transformed into SRLC:

A software application is regarding its development alone, whereas a software system is regarding the development of both the application and the systemic processes under which it is deployed and maintained. If we further simplify, we can re-envision it as follows:

Let us zoom into the Development Release(s) zone to look at what is actually going on and derive our "Life Cycle":

Here, you can observe that the first four essential phases are now represented as part of an actual cycle. Each of these phases also undergoes application development based on ADLC(labeled in the diagram as ADLC) as they move on to the next phase. Once the software development exits the release candidate stage, it undergoes system development based on SDLC(labeled in the diagram as SDLC) to finally become a stable release that would be active through production deployments such as end-users' and clients' environments.

Why must now a stable release go back to a pre-alpha state? Just to represent itself as a life cycle? Definitely not.

A stable release must re-undergo pre-alpha level screening in order to consistently sustain the highest possible quality.

Since the product has already been released as a stable version, debugging and testing under pre-alpha, alpha and beta phases do not take very long. So, you must keep in mind that after a new product is released to the public, it quickly approaches the release candidate level of screening after it is actually deployed and audited by every kind of user.

Real-time production level bugs are inevitable and however there nature may be, it is necessary to re-assess them with a pre-alpha approach. Only then can quality software be consistently ensured with optimum speed and efficiency.

Therefore, this revised model can now finally be referred to as an actual cycle and not the conventional flowchart that many of us in the development community might have been following inadvertently for decades! It is a continuous process which is why it's called a Software Release "Life Cycle".

If there are any suggestions, feedback or comments on this topic, please let us know in the section below. We'd love to see you get involved in such interesting approaches. Stay tuned for the next article in this series :)