Waiting for permission to launch.
The Staging Environment serves as a place to hold tested applications until deployment schedules are established. It is possible some customers will not want a certain release. It is also possible that customers cannot accommodate a release as soon as it is available. The staging server is like a refrigerator where certified applications may wait until the details of their deployments are decided and scheduled.
Many companies do not maintain staging servers. I hold this to be a mistake. Keeping certified releases and deployment packages on the quality assurance server quickly leads to a situation where it becomes difficult or even impossible to determine the difference between certified and non-certified applications. This location acts more like a file server and should be configured accordingly. The most important item for staging servers is to insure the network connections to production are broad enough to accommodate cost effective deployments.
Deployments can be executed automatically if the steps have been reduced to a common process. Manual deployments are not preferred, but necessary where no common process is in place or if the deployments are custom. Avoiding serious issues with custom or manual deployments two items are necessary. The first of these is a deployment package that is certified by the quality assurance team and contains every item necessary for a successful deployment.
The package includes the code (example: *.war file for Java applications) and all the DB scripts, listed in the order in which they must be run. The package should also contain a document detailing the steps required for the deployment. No step may be omitted from this document and the steps must be arranged in order. This detail is derived as a result of the quality assurance team testing each step of the deployment before moving the package to the staging server. The quality assurance team is also required to add post deployment certification tests in the deployment details. A typical deployment document contains the following:
- How to prepare the environment(s) for deployment.
- Taking the system offline.
- Backing up the database.
- Removing the previous application.
- How to deploy the code.
- How to run the DB scripts.
- How to certify or test that the deployment was successful.
- How to report the result of the successful deployment.
A solid roll-back policy is the second important item if custom or manual deployments are necessary. This policy must contain the exact steps the deployment team must undertake to roll-back the deployment incase the system will not come up after the deployment, or if DB scripts fail to run as expected. The policy must also contain steps for certifying or testing that the roll-back was successful. A typical roll-back policy contains the following:
- How to roll-back the code.
- How to roll-back the DB changes.
- How to document the issues necessitating the roll-back.
- How to certify or test that the roll-back was successful.
- How to report the failed deployment.
Automated deployments are preferred, but it is important to understand there are trade-offs. Even if an automated solution is used, configuration is required and at times that configuration can be extensive. However, once the deployment application is set, deployments and roll-backs become much more reliable. Database script deployments and roll-backs can be conducted by using Red Gate SQL Compare or having tested roll-back scripts available.
There are several tools for application deployment. Some of these are, Urban Code, BMC and Dynamic DevOps.
Click here for part six (final) – “Production Environment“