Do you know the process required to deploy your application, or do you build it and hand it over to an operations team?
The less you know about the deployment process, the more issues the deployment of your app is likely to have. However as a developer, you dont want to divert a lot of time to deployment and other operational tasks as you have lots of development to do already.
Lets look at some typical process of deployment, highlighting common issues along the way.
You may have a very well organised IT operations team that have the deployment process for your app very well defined and even automated. However, many IT operations teams have a 6 months plus backlog of work, so not everything gets as automated as it could.
Deploying to your own data center can can take time and several tries to get your application deployed successfully. Some of the issues you may experience are:
Using a hosting company is different from your own data center in that the ops team you have to work with will be remote and you probably have limited communication with them except email or an issue tracking system.
You may experience the same issues deploying here as with your data centre.
The challenge as a developer is that you often end up doing a lot of IT operations work, rather than getting on and developing your app.
Your deployment should not have any dependency on the underlying operating system or tools - it will be harder to maintain a consistent deployment process if you rely on aspects of the operating system that could easily change without you knowing (security patches, OS updates, new build processthat deploys different components of the operating system, etc).
The deployment process should be documented so everyone knows how it works, however the deployment process should be as automated as possible to avoid human error. This will create a highly repeatable process
The deployment process should log details of every step taking, preferably in one place so you can easily track down issues and understant the root cause of any problems quickly.
There should be a robust rollback proceedure, again as automated as possible, with full details being logged so that a root cause analysis can be done.
See the 12 Factor guide for more details on creating deployable applications
Last updated: Mon 12 Jan 2015 08:51:49 GMT