Please release me...

Intro

At the time of writing this article, I’m also working on updating a business-critical live system for one of our clients. This particular system is the lynchpin to my customers business and is in use 24/7/365.  As part of this latest update, we’re releasing some brand-new features and making some changes to existing features. Time for a cup of tea!

During this update, my customer’s system will continue to operate as normal. The changes we make to their servers and databases have no interruptions to their business and the system remains available throughout the process.

For PDMS this is our baseline for our software and services. Your software is only running your business when you can use it uninterrupted, new features should not come at the expense of your most precious commodity – time.

Embrace the change

A key point, some people might believe the only point to the software development lifecycle, is the delivery of software. It’s important to remember that analysis, design, planning, development and testing, also all form part of this lifecycle. All that effort means very little if the customer never gets the new features – it’s all about the delivery.

So how does software from our test systems get onto our customers live systems?

The old navy way

A long time ago our software releases would run along the lines of:

1. Keep a list of the upcoming changes, fixes and previous upgrades we’ve worked on, over a period of days, weeks, or even months, hopefully in a spreadsheet that everyone knows the location of
2. Plan what needs to happen on ‘Go Live’ day
3. Try testing the software release onto a copy of the live system ahead of the intended release and update the plan based on the test
4. Plan, plan and plan
5. Agree delivery dates and make sure the relevant people are in the office – no matter what the time of the day, everybody loves to work at 1 in the morning, right?
6. Some more planning
7. Make sure the system is either taken offline or made unavailable to users
8. The big day arrives, and everyone holds their breath as we step through the 27-point release plan we’ve created. Good luck everyone!
9. Start planning the next release

So, maybe the old navy way isn’t the best way…

While this method has worked and can still work, there are also downsides:

Creation of key dependencies. We can’t say to our clients “oh, Tim’s not in that week, so we can’t complete a release for you” or, “sorry the infrastructure team are unavailable that day”. Key dependencies increase planning and restrict when updates can take place. Cross training can cater for some of this but fundamentally it still relies on a steady hand on the day and a thorough plan.

Consumption of certain individuals time. A release can become time consuming for one or two key individuals with their focus and concentration on the release blocks out any of their availability to the rest of their team during software updates.

A culture of reluctance. This is due to a vicious circle of the effort involved and the dependencies it has. People become less inclined to update the software, which increases the size of the release and the risk involved. All the great features and updates we’ve developed sit on a shelf not adding value to your business.

Human error. That 27-point plan only works when it’s followed to the letter, assuming the letters cover every scenario!

Auditing. Everything that is released needs to be tracked and tied it into that release. Will a calendar appointment, with a long list of changes and fixes, be enough in 12 months’ time when you’re investigating the origin of a code change or are being audited?

The power of automation

By investing in automation, this does deliver substantial benefits including:

Cost reductions. To put it into context, in the last four years we have performed over 1,000 releases for this one customer alone. Before automated releases, this would take 1-2 hours per release. Over a year, this would have meant someone would be busy for 200 working days! Now, thanks to our investment in automated releases, each release takes a few seconds to queue and monitor. This has reduced the 200 working days down to a far more reasonable 50 minutes over the last four years.

Value. Automated releases mean that we can deliver newer features quicker, which helps our clients continue to deliver excellence.

Quicker to respond to change. Software quickly adapts to the changing needs of our customer’s business.

More frequent releases. There is no impending dread about releases anymore, we can queue or schedule a release and know it will work – we can even run a release from a mobile.

Quality and reliability. There is no relying on 27-point release plans to eliminating human error.

No relying on key staff. Everyone can release the software – the need for specialised staff is greatly reduced.

Self-documenting.  Step-by-step instructions are created for the release, so additional documentation isn’t needed.

Audit trails. Audit trails for builds and releases are associated with the changes and the work we’ve done automatically, we can see what was released and when without any overhead.

Going back to my client I spoke about earlier; the kettle has boiled, and the release is complete. A quick email to let my client know about all the new features and improvements now available. By using automation, the release hasn’t interrupted their business and what used to take months of planning and testing, now takes just a few moments.

Final thoughts…

At PDMS, we have different technical challenges around our projects and products. For every small Android app, there’s a business-critical system with dozens of servers. Each of them can have their own way to release changes, but, all them have one thing in common at PDMS. They’re automated.

The future of automation will continue to evolve and become even more ‘smart’. Combining automated testing and artificial intelligence, there may be a time in the future where I don’t even have to click a button for the release to happen. We change the software, the computers test and release for us. Software is no longer one big solid unchanging rock and automation allows us to change and change more frequently. Features can be rolled in and improved on the same day, allowing clients to adapt their process and know that software change comes easily. Even our software deployment tools are constantly updated and improved, giving us greater flexibility and choices when approaching new projects.

So, the next time your software provider asks you to log out of your system for an hour or two for a ‘quick update’ – is it time for some automation?

Learn more

To learn more, please contact Tim