Deployment - Organization and preparation

Most deployments should be a click of a button or an execution of a single command that’s a “fire and forget” type operation. This section covers deployments that are atypical and need some hand-holding.

What customers should be involved in the deployment?

Keep in mind customers here could mean coworkers in your company. However, it could also mean an actual paying customer who is directly impacted by the change. Consider what the purpose of the change is, how the deployment works and who needs to do what. Bring those people into the conversation and confirm they understand their purpose and expectations.

What’s the rollback process?

If something goes significantly wrong, you may need to revert your changes. You should be aware of what that process looks like in general and specific to this deployment. If this deployment involves updating data, how does that get reverted? If the deployment involves maintaining backwards compatibility, does the rollback process also support full compatibility?

Sometimes, a deployment can’t be rolled back (or is very difficult). For example if you’re dropping a column on a table, you’re more likely to “roll forward” with a hot fix. If things are extremely wrong you would have the option of reverting to a backup, but you would lose any data between now and when that backup was created. That data loss is what pushes the hot fix option forward¹.

Does the change require monitoring?

Monitoring here can mean multiple things. It could be as straight-forward as measuring performance of the application. It could mean keeping track of a long-running process that’s updating data. It could also mean identifying usages of a deprecated user flow to identify when it’s safe to remove some functionality. You should consider what change is being deployed, the purpose of it and what information you’d like to gather as a result of the change and deployment.

Do you need to notify customers of the change?

This requires an understanding of your customers’ needs and tolerance threshold. If you’re new, you should talk to someone more experienced and get their advice. If a change significantly impacts a customer, you should notify them somehow. For example, if you have an API you should notify consumers about the changes. Changelogs, deprecation notices, and mailing lists are all good things to have for an API.

Perhaps your change involves some downtime on your application. How can you let your customers know that this is going to happen or is currently occurring?

Should the deployment occur after hours?

Ideally your changes should be able to deployed at any time on any day regardless of how many users are accessing your system. However, some deployments do require downtime. When there is downtime, you should consider scheduling it during a period of low activity to limit the impact on your customers. This requires you to have some understanding of when customers are accessing your system.

Another reason to schedule a deployment after hours would be if it’s particularly risky. A common example in the web application world is if you need to change your domain’s nameservers. Theoretically it should go off without a hitch. But if something is misconfigured there could be a significant outage for a lengthy period of time. Depending on how critical your uptime is (if someone is paying on your for their business, you’re pretty critical) the risk alone of a change may dictate whether you deploy a change after hours.