The evolution of Software releases
If you haven't already noticed there has been a massive shift in how companies release software over the past 10-15 years. The popularity of Agile and its associated processes, the speed of the internet and the demand from the customers are amongst the factors that all contributed to the shift. We're no longer bound to the use of physical media such as a CD/DVD or a pen drive to get a piece of software to the end-user. We have come a very long way in a short space of time. I thought we could reminisce about the good old days and discuss the evolution of software releases, talk about where we got to as well as look at the future.
Software Release Waterfall

The past

For people who aren't familiar with the area let me explain: The average speed of a non-commercial internet connection was around 5Mb/s on a good day. The number of connected devices was close to zero unless of course, you've counted the PC that you've accidentally left switched on.

From a Software development perspective, there used to be at least 3 completely distinctive teams fulfilling different functions to get some new functionality to the customer. A team of developers, testers and operations people; often separated not only by dividers but by rooms and in some cases buildings. In a generic product development life-cycle the developers had a set amount of time - let's say 3 months - to implement some new functionality and fix any bugs that got brought into the "release". During their work, there would be regular demos no one else would see a working prototype of the product. Towards the end of the development, one of the developers would be nominated to follow the rigorous release process to compile the build ready for "release" to the test team.

With the "final" build in hand, the test team would be ready to install and test for about a third of that time the developers spent on it. In an ideal world, the test team would then sign off the release following a successful test cycle (that included a level of regression testing). It would be at this stage when the test team would hand it over throw it over the wall for the operations team to install it deal with it.

Firstly the operations team would read through the detailed upgrade manual vague release notes and request an upgrade time slot from the customer. Once they had an upgrade window allocated for X hours they would carry out the instructions and complete ahead of time nervously attempt the impossible challenge and with sweat and tears, they would finish a few hours past the deadline, causing an unexpected production outage. 

Of course, these were under "normal" circumstances without any hiccups at the development, testing or upgrade stages, without having to roll back production.


With the popularity of micro-service architectures and non-monolithic development came the big push for companies to release software quicker and with more confidence and less human error. Several pieces had to be in place to achieve the impossible; such as fully automated software testing, automated software builds and automated software delivery.

The aim was to do all of these in a quick and repeatable fashion in a "continuous" way. There was also a people aspect to all of this which meant that it made sense to create a team that was responsible for the software release from start to finish. The need to diversify people inside this team was also quite big, which led to a multi-disciplined team structure. And to add to the mix it was the idea to keep this team together for the duration of the project or at least the development life-cycle.

Having put most things in place it was then a question of further evolution to shorten downtimes using methods such as green/blue deployments, early access to features for privileged beta tester groups, feature toggles, and the eventual realisation that trunk-based development is far easier and cost-effective to maintain.

It all kinda makes sense in today's perspective, but it was a relatively long road for organisations and individuals to come to terms with Continuous Integration, Continuous Delivery and Continuous Deployment.

How does Dev(Sec)Ops fit in the picture?

As the abbreviation suggests it's Development, Security and Operations. Combining those different speciality areas under one hat.

With the evolution of the multi-disciplined teams and the use of cloud providers such as AWS and Azure, there was a sudden need for people who were able to fulfil multiple roles and in the lack of another name people started referring to it as DevOps or DevSecOps.

However, we have to make it clear that DevOps is not a role or a job title. It's a culture, that focuses on enabling the development team (or even a whole organisation) of being completely self-sufficient. The DevOps culture promotes all the building blocks (security, infrastructure, monitoring, planning for failure, performance, disaster recovery) of a successful software delivery team and it does that by leading by example. 

Software Release DevOps

The future

We can't predict the future, but as you can see the need is always to do things quicker, with less effort and to do that we going to see other trends emerging. There are still a lot of organisations that need assistance in improving their processes. Some companies are only just beginning their Agile transformation and we have helped many of them through it, both from a technical and a process point of view. If you or your organisation needs any assistance with agile coaching, automation or software delivery please don't hesitate to send us a message.