Deployment Automation

Automation has always been important to software development; it reduces time-to-market, allows more work to be done for less cost, and improves the quality of what is produced. Most organisations already have automation for compilation, packaging and some areas of testing, and are now looking to the newest automation frontier: deployment.

Improvements in deployment automation are being driven by organisations which operate the software they develop, typical of the software-as-a-service business model. Such organisations benefit doubly from deployment automation because it is used by both their development and operations teams. Additionally, if they are not delivering software to external clients, then they do not need to adhere to standards and norms for software packaging and delivery, which allows for more simplifying assumptions, making deployment automation easier.

Organisations delivering software to customers in a more traditional model can also benefit from deployment automation, but typically with greater cost. Even in this model deployment automation can benefit the vendor by reducing errors at customer sites and consequent support costs, and customer expectations are increasingly more likely to include some form of deployment automation.

Benefits

The benefits of deployment automation don’t need much exposition, they are similar to any other sort of automation. Primarily they are an improvement in quality and a reduction in cost. Removing manual steps means less opportunity for human error in the process, which improves quality; and less people hours spent on deployments which reduces cost, and allows software to be delivered sooner.

A secondary benefit of deployment automation is increased happiness. Developers typically don’t enjoy repetitive and rigidly defined tasks, and will be glad to have that burden lifted. Operations staff will be thankful to have a reduction in risk when doing deployments.

Challenges

Of course, there are impediments to achieving deployment automation, and the largest are before the work even starts.

Building knowledge and skills is often required. There are a number of tools available, both commercial and open-source, designed specifically for the purpose, however each tool has its own set of restrictions and differences, so a careful choice needs to be made. More challenging is that the concepts and thought patterns required for using these tools are typically quite different from those used in either development or operations, so it can be expected that existing staff will take some time to become proficient with them.

Part of the learning process is starting to use the tools, so at the beginning of the project false starts and rework are fairly likely results for people new to deployment automation.

Consequently, a difficult decision must be made before even getting started: should existing staff be trained existing staff or new staff with experience be recruited. Both options are naturally expensive and risky.

Conclusion

In the end whether deployment automation makes sense depends upon the circumstances of the organisation and project. If deployments are performed frequently (many times a day or more) then investment in automation is almost certainly justified, while those performed less frequently will take much longer to recoup costs.

For complex deployments the reduced costs of using automation are offset by the increased difficulty of automation, and they would probably benefit firstly from simplification of the deployment process before starting on automation.

Published: 2015-10-25