Taking Application Release Automation to the Next Level
Join the DZone community and get the full member experience.
Join For Freewhether the driver is agile, cloud or devops 1 , or a “plain old” efficiency drive or process improvement initiative, forward-thinking organisations are currently looking for ways to improve their application release processes through automation. in an area where manual activities are still all too common, it’s unsurprising that the initial focus has been on automating the deployment execution – moving all the bits to the right places.
what early adopters have learnt is that, at the enterprise scale,
automating release execution quickly introduces a new bottleneck in
today’s dynamic it environments: continuous management of the deployment
plan definition. a new generation of application release automation
(ara) tooling avoids this pitfall by leveraging intelligence to automate
deployment
planning
as well as execution.
the state of ara

given how strongly our it industry is dedicated to the automation of
processes, it is nothing short of amazing how much of the deployment of
our own solutions
depends on manual actions coordinated more or less effectively between large groups of people.
indeed, a recent analyst report noted that the majority of large
enterprises were still relying on manual application release processes
or on in-house scripting understood by only a small number of
specialists, operated as a black box that – hopefully – will do its job
and will most likely necessitate a painful troubleshooting session if it
doesn’t.
with key it trends such as agile, cloud and devops dramatically ramping up the frequency of application releases in order to increase responsiveness to business needs and provide more and better services to customers, it’s clear that this situation cannot continue.
thinking of today’s common release processes, it is also hardly surprising that the initial drive has been to automate the actual rollout of the application itself: copying the files to the target machines, restarting the servers, running the sql against the db etc. using a defined workflow to organise these activities makes lots of sense: fewer failures, no more missing steps or steps executed in the wrong order, no more typos, better visualization etc.
lessons from the first generation

ironically, using one of these first generation ara tools at an enterprise scale quickly made it obvious to early adopters how much effort is required to maintain the substantial number of workflow definitions that quickly accumulate to support full deployments, partial upgrades, rollbacks, environment scale-outs etc. across an enterprise application portfolio.
of course, this is not a new challenge: ask anyone who has had to update 100 build job definitions in a continuous integration tool to change a compilation parameter, or 100 test plans in an automated testing setup to accommodate a different target browser, just how time-consuming and error-prone this type of maintenance is.
it’s not as though these modifications are unique per process . they tend to be systematic changes that reflect changes to the overall deployment strategy and/or context. the issue is that these first-generation tools, where all the deployment intelligence is stored in the power user’s brain, simply do not have enough internal knowledge of the structure of deployment to assist effectively.
the next level of application release automation

a new generation of application release automation includes this intelligence. these advanced tools 2 no longer require hand-holding by your power users every step of the way, and encode knowledge of deployment best practices and strategies to automate the planning and execution of deployments. 3
no pre-provided strategy can be a 100% fit in an enterprise environment, so the strategies must be configurable, of course. once your power users have fine-tuned them, however, all the individual deployment plans – initial installations, full and partial upgrades, downgrades, undeployments, scale-outs etc…easily hundreds across an application portfolio – are automatically tailored to your scenario.
this becomes even more efficient the fewer deployment strategies are in play, so these tools also motivate and reward increased standardisation of deployment procedures, in itself a valuable business goal. in fact, with a suitable interface and integrations into the development pipeline you essentially have an enterprise platform as a service , potentially on a private or hybrid cloud.
conclusions
with adoption of application release automation rapidly on the
increase, a new generation of solutions are appearing that automate
deployment planning as well as execution.
based on the challenges experienced in scaling the first generation of
ara tools to enterprise levels, these next generation solutions are
designed to eliminate “continuous expert hand-holding”, promote
standardisation and allow organisations to create a “software factory”
that continuously delivers business value.
-
my spelling preference is
still
for “devops” since the whole point is, after all, that dev and ops are
no longer
regarded as separate, but hey…
- like xebialabs’ deployit
- this advance closely mirrors the development of build frameworks from tools like ant to today’s industry standards like maven and on to the next generation of gradle , sbt and others.
from http://blog.xebia.com/2011/11/29/taking-application-release-automation-to-the-next-level/
Opinions expressed by DZone contributors are their own.
Comments