Deploying with confidence = A process to release updates and new features without uncertainty
The challenges of WaaS deployment
Perhaps you’re using Git to make sure everyone can build on the same code base. You might also use a provider like Github or Gitlab to automatically deploy your changes to your live environment. But how do you release changes to your live production environment WaaS with 100% confidence?
The larger you grow, the more complex your system becomes. Speak with any developer, and he will tell you that all code inevitably breaks. Partially, bug fixes, maintenance work is the reason why updates are required.
Systems are going to be woven into each other, updating one plugin could break something somewhere else. There’s no way to know how the update is going to take effect before you actually deploy it in a live environment. Even with the backup method, in the end, if something breaks, you inevitably have to spend resources to bring the system back up.
Your dev team is now in a heightened state, troubleshooting, stalling ongoing projects. Account managers are calling with customers to inform them of temporary downtime etc. When you’re just starting your WaaS journey, it doesn’t seem like a large task.
Though, the risk of having to communicate unplanned downtime to your entire client base every time a plugin is updated becomes a significant burden as you scale up. Moreover, it’s damaging to customer success if downtime is a common practice every time you deploy.
“Deploying without confidence has underlying structural consequences for your long-term competitiveness.”
It would be bad enough if there wasn’t more to it. Unfortunately, deploying without confidence has underlying structural consequences for your long-term competitiveness. Here’s how:
If your release pipeline is met with uncertainty, releasing updates is seen as a big event. Per definition, big events don’t happen often. It’s exciting, your team works tirelessly in anticipation of your monthly feature release.
The science of Lean Software and DevOps
The book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Forsgren PhD and co. (a must read for every tech founder or CTO) presents findings of research that lasted nearly a decade, and describes four distinctive domains to identify high performing tech organizations: delivery lead time, deployment frequency, time to restore service, and change fail rate.
In high-performing tech organizations, delivery lead time is fast, deployment frequency high, time to restore service is quick, and change fail rate is low.
If uncertainty exists in your deployment cycle, deployment is postponed, or releases are often batched, which naturally results in less frequent deployments. Deployment in high-performing teams is part of their culture, and can only be accomplished when there is zero risk in your release pipeline, otherwise, you’ll burn out your dev team in no time.
The best solution: have a separate environment to release your changes to.
This allows you to not only test your changes locally and in your release pipeline, but also in production, without risking outages.