Fred Kouwenberg, Sales Director at Logicalis SMC looks at a key challenge today’s agile organisations pose for operations teams - deploying new releases to production immediately after development and testing is completed – arguing that an automatic and transparent process, agile deployment, is required if applications are to be delivered successfully.
The highly competitive nature of the enterprise software industry has forced many organisations to adopt software production methodologies that ensure rapid delivery of new services to production. But that truncated development process has created a series of challenges - in order to meet business objectives, organisations must fulfil customer expectations for constant improvement by establishing short feedback loops between the market and the development teams.
That has given rise to the “agile” approach; which aims to shorten the software development lifecycle by taking an iterative and incremental approach. The basic principle of iterative and incremental development is software development moves forward in small cycles, or iterations. Each iteration is a micro-implementation of the overall software development lifecycle. It starts with planning, continues to development and testing, and ends in deployment.
Tremendous Challenge
This cyclic approach enables organisations to be more receptive to their customer base, since user feedback on each iteration impacts the development course of subsequent ones. At the same time, the business value of the application increases because its functions are constantly being evaluated, modified and perfected. However, an agile organisation poses a tremendous challenge for operations teams: How do you deploy new releases to production, where they can be reviewed by users and possibly generate revenue, immediately after development and testing?
The solution is to ensure that the deployment process is fully automatic and transparent. We refer to this integration of the deployment station with the iterative and incremental approach as Zero Touch Deployment. In its extreme form, release to production is automatically triggered by the successful promotion of a new build from the acceptance testing station.
The Complexities of Deployment Automation
However, automating the deployment of large-scale data centre applications is not easy to achieve, especially if we set out to provide a complete answer to the deployment needs of agile organisations. One complexity arises from the different types of deployment events agile organisations produce – they can range from a full installation of the application to a minor update or even a single configuration file update and each requires the creation and maintenance of a different automatic deployment process.
As a result, an automatic deployment system must be able to simplify application deployment tasks and mitigate risks; turning what would otherwise be complex, manual operations into reliable, repeatable and error-free processes.
All this means that any automatic deployment process must be comprised of separate deployment flows, one for each application component or tier. Therefore, to enable the deployment of multi-tier applications, an automation deployment system must be able to capture the tier-based architecture of the deployed applications:
- An automatic deployment mechanism to coordinate the execution order of co-dependent tier-specific deployment flows.
- A script-based system can use a build management tool to coordinate between the execution of the different tier deployment scripts.
- An automated release platform can enable the user to specify the co-dependent relations by drawing connectors between nodes representing the different tier-dedicated flows.
Dedicated grid
On top of this, an automatic deployment system must manage multiple deployment destinations. This is driven by a number of factors – not least the rise of online applications serving a global user base, accompanied by the spread of virtualisation and cloud-based technologies, which has increased tenfold the number of instances targeted by a single application release. Consequently, an the system has to execute one deployment event across hundreds or thousands of servers residing in multiple data centres each with its own configuration information; and that demands an ability to support clean separations between the deployment process and configuration information. To support such a separation, a script-based system would have to set up a strict configuration management policy. An automatic release platform, on the other hand, has a dedicated grid that maps and represents the environment in which the application is deployed. Each physical, virtual or cloud server is represented graphically in the context of its environment, as well as in its relation to the deployment process. The configuration information of each server is represented, stored and maintained in the context of this representation. In this way, automating deployment along the principles of Zero Touch Deployment can help organisations fulfil the objective of the deployment station in an agile framework - namely, to deploy new code to production immediately after it has cleared the development and testing stations.
Same automatic process for development, testing and production
That is not the end of the story however. An automatic deployment system that is comprehensive, adaptive and robust enough to face the challenges posed by an agile organisation must be constantly tuned and perfected.
For this reason, the use of the automatic deployment process must not be limited to the deployment station at the end of the iteration. On the contrary, the same automatic process should be used to deploy to the development and testing environments throughout the iteration. This ensures that the deployment process is tested extensively before release day, to avoid any last-minute surprises.
The development team should use the automatic process whenever they need to deploy the application to their local development station, and the testing team should also use it when they create their testing environment. This way, any negative impact of the new code on the automatic deployment process is discovered early, when it is relatively easy to correct.
Clearly, because development and testing environments are different from production environments, some modifications should be implemented to make these environments more ‘production-like’. These modifications may incur some costs, but they will be minimal in comparison to the cost of unsuccessful release days.