As a design and development agency, one of our favourite moments is the ‘go-live’. The deployment or release of a piece of digital creative – from a brand-new complex application, to a feature update, to simply making something slightly less blue than it was before.
All deployments carry some level of risk. It’s our job on a daily basis to manage that risk.
Deploying a system is also the end of the journey. It is the big go-live of all of our ideas that have been made real with code, and that happens with the push of that red button (yes, we do have a ceremonial red button at MMC!).
If this sounds familiar, the it is perhaps because it comes with the feelings many of us have when we share something digitally that we’ve put so much of ourselves into. We all have that slight nervousness around putting it out there.
Once it’s out there we invite reaction, which can be positive and occasionally not as positive. We can relate it to that fear of sharing a photo on Instagram, hovering over that ‘post’ button. Will anyone like it?
There’s also the process of sharing itself, hoping that goes as smoothly as it can and what is ultimately represented is what we intended. Strange autocorrects, typos or missed punctuation can make us feel like we have ruined the perfect email.
So how do we manage this risk at MMC for our deployments?
In essence, we manage firstly through preparation. We joke about our red button, but deployment goes beyond the simple press of a real or metaphorical button. To get to that point the update has gone through a suitable level of testing and has usually passed through the hands of many people who have signed it off. In preparation for go-live there may be dry runs of the deployment and lots of checks.
‘Go live’ might also be a journey itself that last several hours or several days. Deployment can come with other tasks, such as additional content updates, communications to users or technical processes that all need to work in tandem to tick that ‘it’s live’ checkbox
We then support each other, our partners, and our clients. Even if you have done all your preparation, and are confident in the click. Even if like at MMC, deployment is an automated process to reduce risk further, there can always be circumstances you can’t cover.
Maybe there is a difference in the server setup which is only realised at this moment. Maybe a particular test scenario was missed, out of hundreds of potential scenarios checked. Maybe you are not in complete control of hosting the application, and that partners have their own technical and human challenges that you cannot prepare for.
Or sometimes, a deployment could just fail because of that random 0.0001% chance of bad luck.
But when these events happen it’s not about the situation but how you react to it and how we support each other.
At MMC we work to ensure that as much risk is eliminated from the deployment process as possible, and are always working towards zero-downtime deployments. In a lot of cases, if a change is not obvious, deployments can happen with the majority of the users being none the wiser to the work happening behind the scenes.
Here are some of the techniques we employ:
- Where possible we develop our work in an environment closely matching the live environment to reduce these hidden problems when transitioning
- We deploy our applications to a staging environment for further review ahead of go-live
- We test fully in expected conditions through the different stages of the development and deployment process
- We automate as much of the deployment as possible to reduce that risk of human error
- If a deployment fails we are ready to revert to a working version at a click of a button
- All code, assets and other data are backed up and can be restored if the worst was to happen
- We monitor the effect of the deployment after it is set live with analytics, to watch for unexpected problems
And then the moment passes – the deployment is done; it all works great and the relief kicks in.
For all the potential risk that could happen, managing this correctly lets you focus on what is important – the pride and accomplishment of what has been produced, the happiness in knowing you’ve contributed with something to help make users or a client’s experience better in some way.
That’s what drives us when creating and sharing.
However, we do have one major rule which underlines the above – NO DEPLOY FRIDAYS!!
By Stephen Hanlon