A Ranger4 Guide to

Application Release Automation

www.ranger4.com © Ranger4 2014 1

 Contents

1.0 What is Application Release Automation?

1.1 ARA and DevOps
2.0 Why should you do it?
3.0 What you should look for in a vendor
3.1 Repeats deployment process through Route-to-Live
3.2 Composite deployments
3.3 Graphical User Interface
3.4 Pre-built task library
3.5 Role-based security
3.6 Breadth of support
4.0 Considerations at implementation time
4.1 Cultural change
4.2 Process Change
4.2.1 Configuration and Build Management
4.3 Choose your project
4.4 Create a Production Like Environment
4.4.1 Shift Left
4.5 Practice production-style deployments
4.6 Design for production first
5.0 Ranger4 Recommendations

www.ranger4.com © Ranger4 2014 2

1.0 What is Application Release Automation?

Application Release Automation (ARA) refers to the process of packaging and deploying an
application or update of an application from development, across various environments
(through the ‘route-to-live’ - UAT, QA etc), and ultimately into production.

There are a number of activities that comprise ARA:

● Packaging - creating a collection of multiple configuration items that must be

deployed at the same time
● Dependency Mapping - modeling full application dependencies between components
of the application
● Software Deployment - using package contents to install applications and configure
their operating environments
● Promotion - delivery of tested packages to an environment of higher criticality
● Compliance - documenting adherence to processes and validating deployed
application configurations

1.1 ARA and DevOps

The DevOps movement has been born out of the increasing conflict between IT development
and operations teams as a result of businesses’ need to deliver more innovation to their
customers via applications and infrastructures of ever-increasing complexity. Where
development are all about change, operations are driven to control the stability of the
environments they manage and deliver the highest possible uptime to the business - and
change puts all of that at risk.

Release management is typically a task performed by operations teams and fraught with
opportunities for potential failure. In the past, releases have been performed manually,
although, over time, many organisations have written scripts to assist with these manual
tasks. Some organisations have even written their own tools; integrations to configuration
management and build systems, creation of GUIs etc. The problem with the manual and
script based approaches is that they are very time-consuming, often go wrong and are very
difficult to troubleshoot.

These problems heighten the conflict between the development teams (who want their
innovation out there) and the operations teams (trying to keep the systems up) and release
time becomes high pressure and high stress. ARA takes these problems away.

www.ranger4.com © Ranger4 2014 3

2.0 Why should you do it?

Automating the release process using an ARA tool has a number of high-level benefits:

- Hugely expedited release cycles (often from days to hours, sometimes to a matter of
minutes) that results in significant cost reductions
- Do more with less
- Enables higher frequency of release - scale
- Elimination of errors introduced by manual/scripting processes
- Fewer/no issues/outages - reducing risk
- Less time troubleshooting
- Instant rollback / redeploy - increased uptime
- Visibility of deployments
- Complete audit trail allowing for compliance

Typically, in the past, development teams have built their code, then ‘thrown it over the
wall’ into the operations team for deployment into production. This causes conflict where
the operations team have not had enough visibility of the release coming through (and
development want it live now because the business is putting pressure on them) and
operations struggle to plan it into their planned work schedule (often because they are too
busy with unplanned work/firefighting as a result of previously broken releases).
Additionally, code often behaves differently in production than in development and testing
due to environment configuration changes that are often difficult to identify.

ARA allows the development team to integrate the release tool to their build and
configuration management tooling, enables differences between the environments through
the route-to-live to be easily seen. ARA enables role based access so developers can have
access to their projects and environments and manage their deployments. Everything is
recorded, so if something goes wrong, it’s quick to redeploy the last known working release
and the auditors have a record of everything that happened too.

ARA enables development and operations to work together through the release process and
collaborate on every deployment. It eases the conflict between the teams by enabling rapid
resolution should there be an issue on release and encourages development to give
operations earlier visibility and schedule deployments.

www.ranger4.com © Ranger4 2014 4

3.0 What you should look for in a vendor

Many organizations have already tried to tackle release automation themselves to a greater
or lesser extent by building their own tooling. We see 5 steps on the ARA maturity scale:

1) All releases performed manually

2) Some scripts have been written
3) A LOT of scripts have been written
4) Some tooling has been written around the scripts to provide things like a GUI or
integrations to other tools e.g. for configuration management or build engines
5) A vendor developed tool is implemented

We consider a vendor’s tool to be the optimum solution as organizations will benefit from:
- The many man-years of development the vendor has already expended on the product
- The vendor’s polling of customer/prospect base and analyst opinion for new features for
the product roadmap
- The vendor’s dedication to the product and its roadmap
- Taking advantage of new features added for new customers
- Formalised, enterprise-standard support and maintenance

We appreciate it can sometimes be difficult to justify further investment in tooling if

in-house resources have already been applied to partly resolve the problem and we are
well-versed at Ranger4 in performing a gap analysis of existing capabilities to ARA vendor
tool capabilties and working through a business case accordingly.

3.1 Repeats deployment process through Route-to-Live

A key benefit of ARA is consistency and predictability - you should be able to create a
package of code and configuration that you can push through all of your environment stages
through to production and know what, if anything, has changed between the stages.

3.2 Composite deployments

It’s likely that you’ll have complex application stacks with multiple technologies - for
example you might have a Java application running on an Oracle database in an IBM
WebSphere Application Server cluster using IBM WebSphere MQ and Integration Bus. You
should just be able to create one deployment of your application made up of its multiple
components.

www.ranger4.com © Ranger4 2014 5

3.3 Graphical User Interface

Not only should you look for an GUI (browser based) that is clean and easy to use, most
enterprises also will want tools that don’t require specific programming knowledge to use
and that don’t use scripts. The GUI may also be able to help you graphically visualise your
environment and application infrastructure aiding in ongoing architectural decisions.

3.4 Pre-built task library

As above, one of the key tenets of ARA is to move away from manual and script based
processes that are error-prone and difficult to troubleshoot and audit. Finding a tool that
has pre-built tasks that can be selected and added to a configuration package for
deployment provides a faster, more flexible and consistent release mechanism than a
deployment framework product that relies on input of difficult to manage and unpredictable
scripts.

3.5 Role-based security

One of the key benefits of an ARA tool is the elimination of bottlenecks as you allow your
development and operations teams to collaborate effectively through the release process.
This demands, then, that all of the characters (developers, system administrators, DBAs,
security, testers, release managers, configuration managers etc) have access to the
projects and environments they are involved in - and not the ones that they aren’t. The
security model needs to be fine-grained, customisable to your unique requirements and will
also provide be key to you being able to prove to your auditors that your process is fully
compliant (particularly around areas such as segregation of duty).

3.6 Breadth of support

Enterprises generally have heterogenous systems that have developed over time with
multiple integrations, application servers, different flavours of databases and a multitude of
applications. It’s important, then, that the tool you choose has support for all of the
application platforms that you deploy to, or a way of you to easily create the plugins you
need for them and the other components of your Continuous Integration (CI) server, DevOps
or Continuous Delivery (CD) toolchain.

www.ranger4.com © Ranger4 2014 6

4.0 Considerations at implementation time

Implementing ARA and DevOps requires change - and change can be painful and is often
resisted. Here are some pointers on how to make your ARA implementation project go
smoothly.

4.1 Cultural change

When you implement your ARA solution you’re going to be asking some of your resources to
perform more of the release cycle than they are used to, and others to let go of some of
their involvement and hand off some of the work to other members in the process.

If you’ve been working with Agile, taking a note from the Agile Manifesto, your team
members should be ready to adjust their methods and frequency of interaction. But you also
need to be sure that they will accept automation solutions and the new/adjusted roles that
they will play within the organization.

You might find that you are meeting resistance from the team to take on the automation
because they are fearful their roles may become redundant as a result. It’s important,
then, to work with all the individuals and management team to ensure the message
communicated is about the business working faster, better, with less risk and that their
talents can then be fully harnessed to continue to deliver more value, faster.

Some organisations, particularly those that have been acquisitive, are able to forecast that
they will have an increase in applications/releases/workload whilst knowing that their
headcount is unlikely to increase, may even be planned to decrease. ARA solutions can help
teams do more with less.

4.2 Process Change

At Ranger4 we live by the mantra “people > process > tools”. People come first, finally tools
- but just as tools are worthless without process, a process can only be fully optimised when
it’s automated using tooling.

Before you implement your ARA solution though, you need to review the process you have,
identify how it will look in the new world, document, mandate and communicate the new
process and then carefully monitor its introduction. It’s unlikely that everything will be right
the first time and so you’ll need to manage expectations in this phase and create an
environment of continuous improvement. It’s worth thinking about the DevOps tenets about
not fearing or punishing failure (but failing smartly) and about not allowing a culture of

www.ranger4.com © Ranger4 2014 7

blame.

4.2.1 Configuration and Build Management

It’s important to check your configuration management process and tools and the same for
build before you embark on your ARA implementation - you will want your release and
deployment processes to pull quality assured, version controlled code from these
repositories.

4.3 Choose your project

One of the key benefits of an enterprise ARA solution is being able to use a single process
and tool for deployment of a multitude of applications across multiple platforms - but it’s
best to choose one place to start. Here are some projects that are often used to kick off an
enterprise ARA deployment:

- Building a PAAS
- A major middleware upgrade
- Application server/platform migration
- Critical business application update
- Application migration/integration through acquisition
- Rearchitecture for DR/HA

4.4 Create a Production Like Environment

As soon as you have your project in mind, you should design a production-like environment
as a starting point for development. This environment will likely be smaller but should use
the same operating systems, middleware, and configurations as the production
environment. UAT is one of the four typical environments of the SDLC and provides an
opportunity to test in a production-like environment. Production resources that are
unavailable to test environments should be simulated through service virtualization, if
possible.

A production-like environment improves the accuracy of your testing for both the
application and deployment processes. You can simplify your environments as you work your
way back to earlier environments and remove unnecessary components.

4.4.1 Shift Left

www.ranger4.com © Ranger4 2014 8

Involve your operations teams as early as possible - don’t save the critical final deployment
to production for last and hope for the best. Allowing these teams to step in at the
beginning of the software development lifecycle allows the development teams to develop
and test their builds and leaves the operations teams free to test and deploy the
applications. It also ensures a self-designed environment to keep a working application in
working order. Shifting some of the business responsibilities to development (shifting left)
improves coordination between development and operations and expedites the whole
process.

4.5 Practice production-style deployments

If the ideal state that you want to achieve is a streamlined release consisting of automated
deployments, you need a consistent, repeatable process. To achieve this process, start by
practicing production-style deployments that can be simplified for earlier environments. The
environments themselves should also be as similar to production as possible. In a new
implementation, finding a project that can adapt to this criterion is key.

4.6 Design for production first

Since production is the most complex environment, deployments to earlier environments

should be designed as simpler versions of production deployments.

Designing the process for production first enables teams to:

- Practice before the critical final deployment

- Have a template for the processes toward the beginning of the development lifecycle
- Refine and further streamline the process. Automation furthers this goal by stabilizing
previously manual steps in a complex process and reduces unnecessary effort in future
deployments through repeatable, consistent templates
- Eliminate the disconnect in deployment process complexity between earlier and later
environments.

Starting the design process in development prevents alignment with the goals of the
operations teams, since a self-designed, self-tested process cannot reach the level of
complexity that operations teams need.

Developers focus on testing their individual contributions and the representative piece of the
entire application that applies to their function in the project. For this reason, developers
often don’t take into consideration (or don’t know what’s needed) to keep production
environments stable and functional. Due to the magnitude and scale of what needs to be

www.ranger4.com © Ranger4 2014 9

tested and functional in production, the deployment process shouldn’t be designed by teams
that aren’t familiar with the production environment. This is inevitably why allowing
developers to design a Continuous Delivery process as an extension of Continuous Integration
stops before Production and hits the wall of Operations.

To fully align your teams and facilitate collaboration from the start of a project, it’s
essential to acknowledge the importance of starting with the most complicated processes
and removing steps to simplify them. It’s easier to remove steps than to add them during
an outage.

www.ranger4.com © Ranger4 2014 10

5.0 Ranger4 Recommendations

Ranger4 have heaps of experience with ARA solutions and are well-versed in identifying the
best fit tool-chain for your business - an enterprise designed tool from IBM (UrbanCode) or
MidVision (RapidDeploy) or perhaps your technical resource profile and infrastructure
architecture means that Puppet or Chef or Ansible also suit you.

We can make recommendations for you based on what we learn about your profile and work
through a proof of technology or concept with you. We are also well-practised in writing
business cases with our customers wherever they start on the maturity scale and measuring
progress through and beyond the project.

We often find that ARA is one solution of several that will help an organisation benefit from
a full-blown DevOps implementation and have developed our DevOps Maturity Assessment
which baselines and scores an organization’s current capabilities on our DevOps Maturity
Index and provides a fit-assessed roadmap to a desired future state.

To find out more, please visit www.ranger4.com.

www.ranger4.com © Ranger4 2014 11