The last agile mile
So you are a developer who has adopted agile development methodologies, you use a continuous integration server and you have started down the path to continuous delivery. Congratulations, you are moving in the right direction to fully recognize the benefits of agile. What I often call ‘the last agile mile.’ Like any ‘last mile’ this one can be a bit steep. As a developer, you adopted agile so your cool new software features can be moved into the production environment as quickly as possible. But the last mile has some real barriers to achieving this goal, specifically your data center team must also become agile.
The touch point in which the data center becomes involved in the continuous delivery process is in the management of the IT Stack and the final deployment of application code to the production environments. In order for production deployments to move at the speed of agile, the production teams must be ready and able to sustain the faster pace. To get the data centers to become leaner, both cultural changes and tool changes must be made, but not so much that the organization as a whole must be re-configured.
Cultural changes to be addressed
Let’s first look at the cultural changes and belief systems that must be addressed. Data Center teams have always seen ‘frequent’ code changes equal to ‘unstable code’ and ‘high risk’ code. In other words, if developers are making code changes on a frequent basis, then they must have lots of issues. Data Center teams need to understand that the practice of agile is to reduce risk by introducing fewer changes on a more frequent basis.
The second challenge is purely a sustainability issue. Consider the process that most data centers have been designed around – waterfall. In the waterfall approach, each application team moving code to production does so once a quarter or even twice a year. If the data center is supporting 25 teams, they are doing at most 100 deployments a year – or two per week. This luxury of time allows them to develop their own deployment scripts for each application team, tweak them as needed, update the IT stack if required and generally plan around the release schedule.
Now let’s look at that from an agile perspective. Let us assume that each agile team is going to do a new release every 2 weeks (not uncommon). Now the workload for the data center team has just gone from 100 deployments per year to 625 deployments per year. This is a huge increase in their workload; however they have not been given extra budget or extra staff to sustain this new pace.
Built for stability not agility
The third challenge is traditional release solutions are not built for agility, they are built for stability. This requires that the data center teams begin the process of looking at new ways of managing software deployments. Their habit is to look at ‘legacy’ systems that often require a big budget and big buy-in from the entire organization. Data center teams may be resistant to installing a Continuous Integration ‘slave’ or ‘agent’ on every production endpoint preventing them from participating in the Continuous Delivery process. So instead of adopting the developer’s solution, they begin looking at their own solution.
This buying process can be slow and risky due to the potential cost of a legacy purchase which often leads to buying inertia, waiting for all teams to agree on a single solution ‘to rule them all.’ The result, nothing is done and great code languishes in a ‘staging’ area. Developers don’t wait for the data center they instead build out the CD process with a ‘staging’ area. Developers do all they can to move cool new features out to testing, and then they stage the updates allowing the data center teams to determine when the new code will be moved to production based on end user demands and the data center team’s tight schedule.
This mixed method of Continuous Delivery with a ‘staged’ area for production is a hybrid of both agile and waterfall methodologies where developers and testing are pushing the agile envelope and the data center is doing their very best to keep up.
Continuous delivery – the goal
The ‘last mile’ of agile faces some real challenges. The ultimate goal is to allow the continuous delivery process to move past the testing state and into the production environments. In order to achieve this, the underling process of software deployments must be automated and model-driven. Traditional deployment approaches from both sides, development and production, must be re-assessed with a strong consideration for real automation, not just one-off scripts. This is the purpose of Application Release Automation and software deployment automation solutions in general. The trick for developers is to drive the automation process by selecting a tool that can be easily integrated into the continuous delivery pipeline and adopted by production. This also encourages collaboration and the sharing of responsibilities across the continuous delivery pipeline.
Summary:
Continuous Delivery – Challenges for the Data Centre
As a developer, you adopted agile so your cool new software features can be moved into the production environment as quickly as possible. But the last mile has some real barriers to achieving this goal, specifically your data center team must also become agile. The touch point in which the data center becomes involved in the continuous delivery process is in the management of the IT Stack and the final deployment of application code to the production environments. In order for production deployments to move at the speed of agile, the production teams must be ready and able to sustain the faster pace. To get the data centers to become leaner, both cultural changes and tool changes must be made, but not so much that the organization as a whole must be re-configured.
