Once developers have written code for a site, they need to place it on the web servers. That process is called code deployment.
“Code complete” is a common saying among software developers when they have finished a development project.
But code complete doesn’t mean everything is done. Once developers have written code for a site, they need to place that code on the web servers. It’s called code deployment. It can include code that fixes bugs, adds new features, or upgrades the underlying platform. Frequently it’s a combination of all three.
Until the new code is deployed, visitors to a site won’t be able to use it or benefit from it.
Deployment Risks
Downtime is often the main risk with deployments. Some sites can accept new code quickly and use it within seconds. Others need a planned maintenance window, with the help of dozens of staff members over many hours. I’ve heard of stores that deploy only a couple of times each year. Those tend to be massive undertakings that greatly impact the business.
A related risk with a deployment is that new bugs will be introduced. Depending on the quality and quantity of testing prior to the deployment, bugs can be discovered in new features or in existing ones. Depending on the severity of the bugs and how impactful they are, sometimes a deployment might need to be reversed. This is called a rollback. It removes all of the new code and goes back to the old version.
How successful a rollback is depends on how the developers planned the deployment. A well-planned deployment can usually be rolled back easily. But some deployments cannot be rolled back at all.
High Stress
Deployments are often highly stressful. A failed deployment could cause the store and the entire business to suffer, and even fail. There are a many ways to make them simpler, safer, and less stressful.
Indeed, the best way to make them safer and less stressful is counter-intuitive: Do them more often. The more often a deployment is done, the more experience the team receives. With repetition a team can improve its deployment skills, even when mistakes occur.
A side benefit of deploying more frequently is that the amount of code, per deployment, reduces. For example, say a company has 60 code changes to build and deploy this quarter. The company could write the code for all 60 changes and then deploy at one time. But that’s risky, as 60 simultaneous changes have a higher potential to cause problems.
Alternatively, the company could deploy once per month. That’s 20 changes per deployment, which are fewer changes to, potentially, troubleshoot. Or the company could deploy weekly. That’s just five changes per deployment.
Many cutting-edge companies deploy even more frequently, often multiple times per day. Amazon, for example, reportedly deploys every 11.6 seconds.
The biggest benefit of deploying code more frequently is that it helps your customers. If the new code is for them, it makes sense to deploy immediately. And the benefits — such as a better checkout, improved product recommendations, or even a new menu — should help the business, too.
My Deployment Process
By way of example, my process for code deployments to my Shopify app is as follows.
Once I write and test a single code change, I deploy it. There might be one deployment per week or upwards of six deployments in a day.
Since each deployment is for a single change, it’s easy to detect if something breaks or underperforms or otherwise causes a problem with the rest of the app. Sometimes the deployment is just preparing the system for a later changes. These aren’t always visible to a customer.
This process has greatly helped customer service, as an app user can submit an idea and by the end of the day that idea might be live.
Key Questions
Starting a conversation with your team about their deployments is the best way to understand the process. Ask two questions, to start:
- “How long does it take to perform a deployment?”
- “How often do deployments occur?”
Typically, if it takes longer than 60 minutes to perform a deployment or if they occur monthly (or less frequently), there’s much room for improvement. Always ask “why?” and, importantly, “how can it be improved?”