Understand and Manage Software Release Cycles

The historical approach for issuing new releases of software has been to bundle all enhancements into a single, new release which is then distributed to users. Today, however, a growing number of cloud software suppliers and internal IT groups that work in methodologies like Agile, issue new software enhancements continually, and they do so as soon as changes are available.

There are pros and cons to each method, and IT needs to approach these two styles of enhancement distributions differently.

Here are some best practices for software releases, including bundled software releases and continual software releases:

1. Set a goal for excellence (general)

In the back of our minds, all of us who are IT professionals want installations of new software to go well. However, in all the time I have been in IT, including years leading it, I have never seen an IT department articulate a set of aspirational goals for installing new software.

Those goals should be to install a new software release seamlessly, without disruption to the end business or to IT systems. The new software release should be immediately productive and should add value for users. This software should consistently perform well every time, and both IT and end users should already be familiar with the new capabilities that the software release contains.

2. Always read the release notes first (bundled)

The software release documentation provided by software vendors usually is verbose and poorly written. It is small wonder why the natural inclination for IT and end users is to not read the release notes at all.

What usually happens is that release notes are skimmed, with the hope that major concerns or changes are identified and planned for. A better, albeit more cumbersome, approach is to carefully review the notes, making sure that end users also receive relevant documentation pertaining to them with the new release. If there are questions, contact the vendor for clarification.

By doing this, IT can obtain a better understanding of what a new release contains, and how it might impact other systems. End users get a preview of new software capabilities that they can plan to insert them into their business processes.

3. If a software release packages a series of enhancements, regression test those first (bundled)

A new software release of a major database or an ERP system bundles numerous enhancements into the release that touch many different corners of your systems and applications. New releases of major operating systems can have the same effect.

For this reason, a “rip and replace” approach that simply installs the new software release without first verifying performance and integration with the systems around it in a test mode can be a recipe for disaster.

The best approach for a major software release is to first trial it in a test environment that emulates your production environment. This enables you to check for any impact on processing and transaction speeds, or “breakages” in integration that occur because of new code that has been introduced, and other issues.

Until a new release of a major piece of software is thoroughly and successfully tested in a test environment that emulates production, don't install it in production.

4. Have a ‘backout’ plan (continual software releases)

The goal and the benefit of continually releasing new enhancements as soon as they are ready is that users get immediate value from them. So they don’t have to wait weeks or even months until a large, bundled software release is ready for distribution. The downside of piecemeal releasing new enhancements as soon as they are available is that system integration might not be well tested. This can cause disruptions in service.

One strategy for dealing with the installations of one-off enhancements is to have a “backout” plan. In other words, if the new enhancement unexpectedly and adversely impacts other systems and functions, it can be backed out immediately, with systems being restored to what they were before the install. Several steps are involved in this.  First, the software enhancement being installed should be structured in such a way that it is easy to install and de-install. Second, users should be informed of the backout strategy and how and when it will be used. In this way everyone understands and agrees with the backout approach.

5. Talk to your software vendors (continual software releases)

Before signing a contract with a vendor that uses a continual release software strategy, interview vendor customers about the success (or lack of it) that they’ve had when the vendor installed piecemeal software enhancements. Have these enhancements worked without a glitch? Have users been able to immediately use the new functionality? How does the vendor notify customers of new and coming enhancements?

Even in continuous release software deployments, it’s good for both IT and users to have a “heads-up” before an enhancement takes effect.

If the vendor has a reputation for poorly developed or communicated continual release enhancements and you still want to use the vendor, you can work out an agreement that gives you the option of selecting when you want to implement each enhancement.

6. Know when to be “agile” with Agile (continual software releases)

What’s great about Agile and DevOps application development is that users and IT work together and can agree when a new app should go live. There are times when users are perfectly satisfied to start using an “imperfect’ app, as long as they can obtain enough functionality to make it worthwhile.

As long as users and IT are in agreement about using an imperfect application, it’s fine, especially if all that is being addressed is a frontend GUI (graphical user interface) to an application. However, once you get into the backend integration that a GUI or app requires with other systems, that integration must be tested, and it should not be installed in production until it works perfectly.

What to Read Next:

Google Cloud to Offer Security-Vetted Open-Source Software

How DevOps Teams Can Help Create Top Agile Teams

Ground Rules for Open-Source Software Management