The Case for Adopting a Continuous Upgrade Schedule

Management decrees that its time to finally “get around to it” and update the antiquated system to the latest and greatest so they can take advantage of the newest features.  You ask your boss what resources will be made available and how many people will be hired to support what you know to be a monumental effort, and after the raucous laughter subsides, you are told that you and your colleagues will now be handling retraining on the newest version AND testing in addition to the daily workload.  In the leadup and implementation of the newest version, nerves will be frayed and ultimately production time will be lost.

Meanwhile, on the provider end…

Your client, who had previously responded to repeated upgrade pleas with “we’ll get around to it”, decides its finally time to do it.  Their existing version is so dated that it was initially installed via notched floppy disk.  The client wasn’t doing continuous or even occasional upgrades, and now the program upgrade and data migration is such a huge effort that your support staff inevitably become inundated with tickets and in-turn the development teams scramble to handle the mountain of bug reports and other upgrade related headaches.

These are of course worst-case scenarios presented to make a case with a light dusting of comedic exaggeration, but I’ve personally been involved in an upgrade where the client waited roughly 15 years to do an update of their ERP software, which was not far off from the above situations.  The interface had changed from DOS to a modern Windows GUI, the database backbone was drastically different which of course makes data migration tricky, the related serial devices owned by the client were from the Dark Ages of the early 90s and no longer supported, the format for the tons of configuration files that were proprietary to that particular operation were unusable, and roughly half of the previous SOP process paths through the software had changed.  Rather than simply an upgrade, this undertaking was basically a fresh implementation to a company that didn’t expect that level of effort for an “upgrade”.

War broke out amongst engineers in ancient China when they were forced to upgrade straight from Abacus 1.0 directly to version 10.0; historians contend they should’ve been continuously upgrading.

When I refer to making the case for a “continuous upgrade”, I am not being picky on which release methodology is used whether it is “continuous delivery” where the release is manual or “continuous deployment” where everything is automated.  I’m also not specifically advocating that every available update, patch, or hotfix be immediately applied without question.  A tight incremental update schedule where the increments aren’t far apart, while arguably not seamlessly continuous or considered conducting “rolling releases”, should still reap most if not all of the benefits listed below.

In the warehouse management software world where customer demand requirements of supply chain and distribution channels can be uniquely challenging, unforgiving, and rigid, continuous upgrades paired with automated testing can prove to be especially beneficial by providing agility and freedom to safely mitigate risk by measuring the repercussions of system changes before going live.  Blue Yonder (formerly known as JDA) is an industry leading WMS solution provider.  Matthew Butler, the Director of Industry Strategy at Blue Yonder said, “At Blue Yonder, our customers yearn for a frictionless upgrade experience, one which can remove the overhead associated with cumbersome technology cycles while allowing rapid adoption of innovations entering the fold through our own development as well as our partner communities.  Automated testing is the key to that frictionless experience.”

Advantages

• Increase the time to value, and reap the advantages of the newest feature additions, performance tweaks, and bug fixes
• The system provider gets more timely feedback which ultimately helps make a better, more feature rich product
• Frequent, focused smaller updates and/or hotfixes are easier to manage than the rare gargantuan upgrade
• Faults related to updates are more easily isolated and in-turn easier to troubleshoot for both provider and client
• Feature additions are easier for users to learn when they are served in bite-size chunks, as opposed to delivered via gargantuan suite of new features and UI changes
• There is an ongoing and formal buildup of QA knowledge, as testing is performed regularly in a standardized fashion – while forced, it’s a good thing
• Test cases are easier to maintain when the repository is gradually tweaked, rather than a tidal wave of changes that comes out of a giant upgrade scramble
• The client in some cases may have to still tediously perform all of the small fixes and patches in the leadup to the giant update depending on the system provider’s program update and data migration scheme, as many will focus their testing on version A to B and not version A to Z, and in this case the client is essentially doing a continuous upgrade anyway but in a short hectic time-frame
• It is more likely to have subject matter experts and actual users involved with testing rather than a hastily assembled QA team who is seeing the standard operating procedures for the first time as part of a huge undertaking
• There should be no need to temporarily shutdown operations, which would be more likely to happen using the occasional, giant upgrade methodology
• It’s the future. Don’t fight the future. (half-kidding)

Requirements

• Dedicated QA staff focused on the latest updates
• Dedicated testing environment where the incremental change is tested before it hits the production environment
• Change management staff needs to be on the ball; prepared for UI changes, new data fields, and eager to take full advantage of the latest features
• The frequency of backups becomes especially critical in the event of an upgrade gone wrong
• Buy-in at all levels, as testing would now be built-in to the SOP
• Unsuspecting interns to blame in the event something goes horribly wrong

There are a variety of options on the market that make deploying and testing continuous upgrades easier to manage, drop us a line and we’ll recommend a low-code test automation solution tailored to your needs.

James Prior
Sales Ops Manager  James has been working in software pre-sales and implementation since 2000, and more recently settled into working with a pre-sales team and occasionally writing blog posts. Drop him a line at: james.prior[at]tryonsolutions[dot]com.