Software deployments are a necessary part of the software development cycle. Although deployments always come with a bit of risk, there are tools and protocols that can help ensure a smooth process. Below are some good practices to implement in order to avoid the bad deployment blues.
Communication 
Deployments can often involve a number of people and different teams to make sure things go smoothly. It’s important to make sure to communicate effectively to all of those involved in the deployment to ensure everyone is on the same page. A deployment can quickly be derailed by a network change or server configuration that didn’t happen. Here are a few ideas for effective communication:
- Have a pre-deployment meeting to make sure that everyone knows the plan.
- Send emails to everyone involved and make sure to ask for a response from those that have action items necessary for the deployment.
- During high-risk deployments it may be a good idea to have a video chat or conference call during the deployment so that all the parties involved can be a part of the process and provide input.
Documentation
Documentation can sometimes feel like a tedious task. However, it can save you from having to delay or cancel a deployment. Although the deployment may rest on the shoulders of very capable and responsible people, it can be foiled by technical gremlins, personal emergencies or even an expired password. If the deployment process is well documented, a team member can take over for someone who may not be available at the designated deployment time.
Another aspect of documentation are release notes. It’s a good habit to send out release notes before the deployment to keep everyone in the loop about the changes and defects that are addressed in the release. Sending out release notes to all of the team members in a deployment can also have the added benefit of additional testing, as some would like to verify the changes for themselves. Release notes can also be a method of managing expectations for the end users and can lead to exposing issues with the deployment quickly since users are aware of what is being changed.
Testing/Staging
It goes without saying that testing is vital before deploying code into a production environment. Before introducing new code, features and changes need to be sent to a staging environment. A good staging environment should mimic the production environment as closely as possible and be kept updated according to the changes made in the production environment. It’s understandable that the staging environment and the production environment will not be identical; however, it can provide a realistic test before deploying software to production.
Another part of testing that may be overlooked at times is performance and load testing. A deployment may take significantly more time or resources in a production environment as compared to a test environment. Performance and load testing in the staging environment can expose issues before a possible failed deployment.
Because unforeseen factors can derail even the most well executed deployment, testing the rollback plan is critical. When testing, the rollback process should be deployed to the staging area to verify that it will work. The rollback process should also be well documented so that it can be done by any available resource.
Verification/Lessons Learned
It’s important to have monitoring in place to determine whether a deployment is successful. It’s beneficial to have monitoring set up on the server side and the client side so that you can observe performance after a deployment. There are even some monitoring tools that will alert you via email or SMS if the performance levels are outside of a set threshold and may indicate a problem.
User feedback after a deployment is also a good way to gauge whether a deployment is successful. When that feedback is not positive it’s time to start determining what went wrong. It’s important to get as many details as possible so that the issue can be reproduced and investigated. It’s also important to communicate to the stakeholders as soon as possible that the problem is being investigated and a fix is being worked on.
Despite your best efforts sometimes deployments go bad. The most important thing you can do after a failed deployment, outside of fixing it, is to learn from it. It’s important to make sure that you don’t make the same mistakes again. In future deployments make sure that you account for the scenarios that caused previous deployments to fail.
Conclusion
Preparing for a good software deployment may not guarantee things go smoothly but adds a great sense of comfort in knowing that you have planned for common pitfalls. Thorough testing, documentation and communication can significantly increase the chances of a successful deployment and avoid a deployment disaster.
