After all your hard work in development, system deployment is the crucial stage at which your users are exposed to your application.
It is absolutely vital to get this right.
Many otherwise technically excellent systems have been set back by a poor deployment strategy.
The user community can be unforgiving, so if there are any glitches, the new system can suffer from poor acceptance.
In some cases this will lead to the system being rolled back and users reverting to a previous system for their day to day work. This can cause a serious loss of confidence in the new system, something it might take a long time to overcome.
Using development, staging and production environments
In order to give the new system the best chance of acceptance, system deployment should be seen from the outset as part of the wider development workflow, not as a a ‘tacked-on’ activity at the end of the development cycle.
In the case of an application or website development, the developers usually work in three environments: that of development, staging and production.
In a git environment, developers often work on features and bugs in different branches. Here, smaller updates can be committed direct to the development branch.
When features are implemented, they are then merged into a staging branch, from where they can be deployed into the staging environment to be quality assured and tested.
When testing has been completed, the feature branches are merged into the development branch.
When release is agreed, this development branch is merged into production, then to be deployed into the production environment.
At release date
There are some simple but useful tips for a successful deployment.
The first concerns timing.
It is a good idea to consider exactly when to deploy the new software. Clearly, choosing a time when the application is usually in low demand is a good strategy. This will give a gentle introduction and allow for stress testing as demand ramps up. If problems do occur, it will be less disruptive to rollback the new release and address any issues.
The clever developer will, however, also consider the wider needs of the business. It is a good idea to choose a time when the business is quieter and avoid peak times with lots of customer activity or deadlines such as month or quarter ends, when colleagues may be more stressed.
It can also be a good idea to consider a phased roll out, if possible, using a trusted pilot population to try out the new software.
Timing can also be as simple as choosing an appropriate time of day. It is probably not a good choice to deploy new software towards the end of the day or week, just before support staff are leaving work.
Dealing with problems
Despite your best efforts, it is quite possible that problems will occur and in this case you might want to consider rolling back the application.
Care needs to be taken though and a few questions answered before taking any action.
Firstly be sure that the problems are actually due to the code that has been deployed.
Next, make sure that the deployment can be rolled back.
In some cases, such as where database structures have been altered and are incompatible with the previous system, rollback may not be possible.
At all stages, keep the user population informed look for feedback on any issues.