An early believer in the ability of Java to deliver "enterprise-grade" software, Andrew Phillips quickly focused on the development of high-throughput, resilient and scalable J2EE applications. Specializing in concurrency and high performance development, Andrew gained substantial experience of the intricacies, complexity and challenges of enterprise application environments while working for a succession of multinationals. Continuously focused on effectively integrating promising new developments in the Java space into corporate software development, Andrew joined XebiaLabs in March 2009, where he is a member of the development team of their deployment automation product Deployit. Amongst others, he also contributes to Multiverse, an open-source Java STM implementation, and jclouds, a leading Java cloud library. Andrew is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. You can read more from them at their website. View Full User Profile

Release Automation: The Missing Step in Release Management

08.03.2011
| 4213 views |
  • submit to reddit

Across all industries, the services delivered by business applications have become an essential part of an enterprise's customer offering. Bringing new features to market quickly is thus a critical factor in determining a company's success.

In this post (an extended version of which is available as a whitepaper), we will outline today's Release Management challenges and discuss the need for Release Automation.

We'll identify key considerations for successful solutions and highlight why "Zero-Maintenance" is a critical requirement for Release Automation that provides the scalability required in an agile landscape and enables the delivery of continuous business value.

Business Focus: Accelerating Time-to-market

Across all areas of industry, IT has gone, in the past couple of years, from providing primarily backend support to being an essential part of an enterprise's customer offering. Whether it be your webshop, e-banking site or online trading platform; your online timetable or route planner or your city's self-servce portal - features and functionality delivered by IT are critical differentiators.

The speed with which your companies or organisations can make these new features available to your users can determine who will succeed in the market.

Development organisations, which are typically in closest contact with the business, have reacted to these needs by adopting agile methodologies designed to adapt to fast-paced change whilst regularly delivering value. With more than a 30% of recently surveyed companies already practising an agile methodology, and a continuing upward trend, agile has "crossed the adoption chasm" and is clearly here to stay.

As companies implement agile, they quickly discover that developing software quickly is only part of the challenge, however. In order to truly deliver continuous value to end users and the business, the entire testing, QA and production release lifecycle must be accelerated. In the words of a recent analyst report:

"As software becomes more embedded in the business, firms are discovering that the velocity of business change is now limited by how quickly they can deploy."

Release Management Challenges

Unfortunately, this accurate, efficient, self-service Release Automation process required to actually deliver on the promise of agile methodologies is a far cry from what is seen today: a mix of manual steps and opaque scripts operated by the few experts with access rights to the target machines.

With fewer than 5% of organisations currently operating release teams focused on continuous delivery, it's probably no surprise that 82% of organisations take at least 24h (with a mean closer to a week) to release even the smallest code changes to customers.

Fewer than 15% of those surveyed rated their satisfaction with release visibility, accuracy and speed at 80% or greater, so there clearly is significant scope for improvement.

Release Automation: The Missing Step

Given that Release Management has been strongly shaped by management- and process-focused methodologies such as ITIL, the relative lack of attention paid, until now, to the actual execution of the release is not all that surprising.

Indeed, looking at a generic release process definition

Plan Release – Build Release – UAT – Prepare Release – Deploy Release

the tendency has often been to view the deployment element as little more than “do stuff”. As companies are realizing, this attitude critically underestimates the importance of deployment for effective release management.

Firstly, the number of components and systems touched by today’s heterogeneous applications and distributed environments means that deployment has a far higher complexity than the preceding Plan to Prepare steps. In addition, as soon as organisations start looking at the figures, they realize that the number of deployments carried out is staggering, especially in environments such as Dev and Test where the preparatory phases of the release management process are often absent or reduced in scope.
With their focus on frequent iterative delivery, agile methodologies dramatically magnify this imbalance.

In order to meet this challenge and align release management with business need, companies are now evaluating and implementing Release Automation solutions, with analyst predictions that

"25% of large IT organizations will establish release teams focused on continuous delivery"

Key Considerations for Release Automation

A fundamental necessity for any Release Automation solution is that it support your target systems, provide insight into what components will be deployed where using which actions, in a secure and reliable manner.

Beyond that, though, there are a number of further considerations that are critical to ensuring the solution truly and reliably supports the fast pace of change demanded by the business:

  • Self-service: the enormous increase in releases, especially to Dev and Test, caused by agile means that your specialist middleware resource pool will always be overloaded if they are relied upon for all deployments.
    Your Release Automation solution needs to allow application users to deploy their desired release without requiring significant knowledge or experience of the target systems, and without granting these users access to the target systems and middleware.
  • Accurate: Release Automation that blindly executes a fixed sequence of steps without taking into account the actual state of the target environment is brittle in the face of change.
    Your Release Automation solution should not require the user to know the state of the environment and select the correct task or job accordingly.
    Rather, the context necessary to always do “the right thing” should be stored and maintained by the system.
  • "Zero Maintenance": With fast-paced change, the number of different deployment activities that need to be carried out – from initial installations and full and partial upgrades to in-place redeployments, rollbacks and incremental additions1 - dramatically increases.
    Add dynamic environments such as cloud, migrations and platform upgrades and it is quickly apparent that the a Release Automation solution that requires task definitions to be manually added or updated for each change will not scale.
    Your Release Automation needs to adapt to changes in application and environment components automatically, supporting the spectrum of deployment tasks in a manner transparent to the user.

Of course, XebiaLabs' Release Automation Platform Deployit implements these and other essential Release Automation Best Practices.

The full whitepaper can be downloaded here.

Footnotes
  1. in which the application is deployed only to additional infrastructure that has been provisioned to ease load or increase performance, and linked up to the already-running components

 

From http://blog.xebialabs.com/2011/08/03/release-automation-the-missing-step-in-release-management/

Published at DZone with permission of Andrew Phillips, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)