Agile Development, but what about Agile Deployment?

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.

About Fred Kouwenberg

Fred is Director Sales at Logicalis SMC. He joined the company in 2006, where he fulfilled several sales roles including Solution Consulting and Sales Support.

Prior to joining Logicalis SMC Fred has worked for several software companies including CA Technologies, Peregrine Systems and IBM Software Group.

As an IT fanatic with over 20 years of experience in sales and the ITSM market, Fred has a wealth of sales insight and a vast commitment to customer success.

4 Responses to Agile Development, but what about Agile Deployment?

Hi Fred,
I really enjoyed reading this article on agile & zero touch deployment. There is a lot of traction on the topic of DevOps and Agile amongst the digital and startup communities and this article follows perfectly with their manifesto. I think it is also critical to build out strong process hand-offs between Release and Change management and utilize the best of both process areas together to have better transition and coordination between the Development and Product teams when planning deployment to Production. Thank you for posting on such a hot topic right now.
Chris G / Chicago

“That has given rise to the “agile” approach; which aims to shorten the software development lifecycle by taking an iterative and incremental approach”

The SDLC is in my experience not shortened, this isn’t exactly precise. The duration for completing the feature may now be broken into several user stories, however, at the end of the day the ‘whole’ feature is delivered to the customer. The estimate provided by the engineer (jr level or sr level), is tracked via the burn-down.

So, it is not likely the developer suddenly can deliver a feature any quicker, regardless of the development methodology. This is relative to the domain expertise of the engineer.

As Logicalis heads to the Hannover Messe industrial technology show to demonstrate IoT infrastructure in actions, we look back at 13 articles about IoT. Back in 2012 we suggested CxOs start asking questions about how it might benefit their customers. Enjoy. The Industrial Internet of Things (IIoT) – A Trillion Dollar Business One of the hottest […]

Tom Bale, Business Development and Technical Director for Logicalis Channel Islands, explains how to defend yourself from Cyber predators. Is it time to stop ignoring cyber-security and actually tackle the beast at your door? The online predators stalking us may be harder to spot than the ones with teeth faced by our ancestors faced at the cave mouth several million years ago, […]

Every minute, hour and day we are generating huge volumes of data, which means ever more sophisticated and powerful tools are required to analyse it if meaningful insights are to be delivered. One such tool is machine learning – but what is machine learning? What is machine learning? In order to more efficiently spot patterns […]

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 […]

A research white paper published today by Ovum and commissioned by Logicalis, reveals some interesting statistics about the willingness to use, and readiness to deploy, BYOD in the workplace. Ovum’s multi-market Q4 2012 BYOD survey gathered responses from 3,796 consumers who work full-time in organisations with more than 50 employees across 17 different countries. Respondents […]

We recently announced at Logicalis that we are putting together a team to explore the immediate and future impact of Software Defined Networking. But to the non-technical CXO, what is an SDN? Gary Thomas explains. For the average technically minded executive many new concepts are understood by a form of osmosis coupled with a core […]

Joanne Nelson, VP of International Market for Logicalis Group, revisits Software Defined Networking (SDN) for non-technical executives. Two years ago we published a post called Software Defined Networking (SDN) for the non-technical CXO. The post was popular and cited by one pundit as the best analogy to explain SDN. This week we have condensed it in to […]

Chris Gabriel looks at how a UK city is deploying SDN to create a technology-agnostic citywide network that will allow driverless car experiments, traffic and environmental sensor networks, and smart energy grid management. Since we started talking about Software Defined things, we have moved, along with the rest of the IT industry, from using the […]

Chris Gabriel explains why the SDN (Software Defined Networking) naysayers are wrong, and why they’d be mad to ignore a technology model that will change everything. A colleague grabbed me last week with a knowing look on his face. “Chris,” he said. “You know you have been pushing this SDN thing with a bit of […]

Eugene Wolf, CEO of Logicalis SMC, looks at potential barriers to both SDN adoption and to the realisation of its true transformative value, and concludes that one stands head and shoulders above the rest – skills. Logicalis SMC recently took a lead role in a global Logicalis initiative designed to assess the future impacts of […]