INTRODUCTION
Deployment needs to be managed and communicated properly. A deployment can either be a brand new application or an update to an existing application/system. If we are not managing this properly, we will lose track of what is deployed in the server. These include any third party DLLs, applications, etc. And also, your business may also suffer from any downtime that may be caused by the deployment.
NOTE: Cowboy-style deployment is not welcome.
Therefore, in this article I would like to share with you few tips that I normally use to administer a deployment.
COMMUNICATION IS KEY
Communication is key in a successful deployment. Communication happens in the following ways:
– Between your team
– Between you and the client
– Between the client and the rest of the organisation
Between your team
Ensure that you and your team knows what it is that you are deploying eg. what version of the application and where to grab it from.
Use the Deployment Guide document template to list any files and dependencies that you are willing to deploy.
Ensure that all test cases have been approved and passed.
Between you and the client
If the client has a team that will do the deployment, make sure that you send the Deployment Guide document together with all the packages to them.
Then – depending on the client – you also need to fill in the Change Control document. The Change Control document details the business-level delivery (eg. business risks) while the Deployment Guide is detailing the technical delivery (eg. third party DLLs, the package details, etc).
Some clients (especially the small ones) don’t have any change control procedures meaning that you can deploy whenever you like. This is not a good practice. If the client hasn’t had any procedure, it may be helpful – as a value added – that you introduce them to one.
Between the client and the entire organisation
Make sure that everyone in the organisation is aware of the deployment that will take place especially if it will affect the system that they are using daily. The last thing you want to have is phone calls on the next morning asking why the menu has changed or why the system is down, etc.
Therefore, email them ahead of time that a deployment will take place and what changes they will expect to see.
Depending on the audience that may be affected, you may not need to send an email to everyone in the organisation but only to the list of people who will be affected by the change.
BACKUP, BACKUP, BACKUP and ROLLBACK
Make sure that you can always rollback to previous version in the case of a failed deployment.
The easiest way is to ensure that backup is done. The least you can do is the last-night data needs to be backed-up.
The last thing you want to have is, the deployment failed and you have nothing to restore from. A failed deployment can bring an entire system down for hours if not days. Make sure that this doesn’t happen at your organisation.
