If you’ve worked in software development long enough, you’ll have lived through at least one “ropey” version release.
It could be version 2, or version 12 – but generally, the more complex a system gets over time, and the more features are added, the more likely you are to encounter an issue with a version launch.
And the larger a user base grows (on multiple devices, operating systems, browsers – you name it), the more opportunities there are for user error, bugs and incidents after a launch.
Sometimes, it’s inevitable; no matter how hard and diligently we work, we’re not perfect. But it’s frankly amazing how many issues can be avoided with a new version release – with simple, effective communication to your users.
Oh, and forget emailing your release notes, “HOT NEW FEATURES!” lists or press releases. Because half of the time, those emails go straight to spam. The rest either get ignored or misinterpreted.
Thankfully, there are better ways to communicate with your user base and ensure a smooth transition between versions – with fewer complaints and support tickets.
A major release can be gruelling, even before changes are committed and rolled out. But once users are in the application – things can get messy.
Sometimes, functions and features are moved to make room for other, newer or higher-priority features. If you haven’t effectively communicated this to your users, expect a bunch of support tickets asking why they can’t do “that thing” anymore.
Remember – not everyone has the time to sift through their emails and read version notes. Many inboxes will filter out mailer bots, especially in high-pace, high-stakes organisations. So, while an automated email is an easy and simple solution for you, the people who actually matter aren’t getting the information they need, or it’s being presented in a woefully ineffective format.
Absolutely – you need to have version release notes. But does everyone need to read them? Think about a few ways to improve the release experience for users:
To stay ahead of the game, check forums for common issues with other releases (not necessarily your own) and try to preemptively mitigate any issues you encounter in them.
Incidents happen. And they’re serious. Speed of response is your greatest asset during a major incident, so make sure you’re ready.
Connect your CI/CD pipeline to Jira Service Management (or other ITSM platforms) to give your team a speed advantage when identifying issues that have just been released to the live environment.
Good housekeeping is the key here; build categories using multiple attributes, so that high-priority items get noticed first. Set event thresholds on the number of linked incidents, and then define automated escalation paths.
Jira Service Management Service Centre and Confluence can work together to speed this up and communicate clearly during an incident. Use tags and keywords to raise content before a query is submitted.
When a high-level incident occurs, you will likely be following your major-incident process. Some of this will happen within your workflow, with automation and integration between your ITSM and documentation or collaborative workspaces.
Some of this will fall outside of ITSM; managing resources and relationships.
Senior leadership will be asking questions. Customers will be pushing back.
All the while, your dev team will be working hard, trying to resolve the incident. It can be tempting to bombard them with status requests when you’re getting the same. But be mindful of the impact this will have on their focus, their efficacy, and their wellbeing.
And be mindful of your own.
Major incidents are rare, but when they happen, you want to know you’re prepared to limit the fallout.
Is your Jira and Confluence set up to handle a major incident after a version release?
ClearHub specialises in finding the best Atlassian contractors in the world; vetted, skills-checked and ready to prepare your DevOps and ITSM platforms to handle anything.