What is application release automation and what does it mean for your organisation?

1. What is application release automation
and what does it mean to your
organisation?
The CIO’s Guide
to Automated
Deployment

2. The CIO’s Guide to Automated Deployment 1
The CIO’s Guide to Automated
Deployment
When it comes to application build and deployment, organisations
historically rely on a wide range of different processes to manage this.
These processes are often manual or partially scripted, with different
parts of the organisation using different processes. The nature of this
approach often leads to errors, inconsistencies and mistakes in the
target environments. For example, if someone forgets to do part of the
process or mis-configures something, then what worked in a test
environment can fail in the production environment.
This does not have to be the case. By integrating the deployment
processes into a single, automated solution, it offers organisations a
number of benefits - including increased efficiency, reliability, audit,
speed to market and compliance, DR and governance. Automation
allows organisations to manage exactly what is released into the
environment and be confident that it will work.
What is Build Automation?
When it comes to build automation, the objective is to provide a
standard framework for different projects or departments within an
organisation to standardise the creation of deployable software assets.
For example, where the development team is using partially scripted
builds or manual builds from an IDE, which may differ between different
parts of the organisation, build automation aims to standardise and
automate these ad-hoc processes. The automation process itself caters
for the difference between each of the different types of assets being
built (i.e. web, database, business service, etc.) - but the overall
process itself is a common one
What we’re trying to do is bring all of these processes together, into a
single build automation process that everybody understands across
every project. Really, it’s a single process, a one best way.
In recent years build automation has matured significantly to a point
where there are now a variety of established patterns and tools, for
things like dependency management and continuous integration, with
tools such as Maven and Jenkins establishing themselves are market
leaders in this area.

3. The CIO’s Guide to Automated Deployment 2
2
What is deployment automation?
Historically, deployment automation is an area that has been tackled
less successfully than build automation. In short, it is how we automate
the deployment of the build components out into the target
environments. A secondary and less mature area of deployment
automation is the deployment of the configuration changes that the
application requires (such as connections to databases, web services
or other configuration). As this area matures vendors in this area are
looking at increasingly sophisticated ways to package application
components (such as WAR or EAR files) with the runtime
dependencies required by the application itself - to create a deployment
package that encapsulates not just the developed code but also a self
describing installation process for the code onto the servers
themselves.
The target environments, (or runtime environments) that we are
concerned with should be all the servers being deployed to from
development through to production. This route the deployments take is
sometimes referred to as the "path to production".
However more often than not, the majority of organisations are in the
dark ages when it comes to deployment - with many (and something of
the majority) of these tasks being carried out manually. Ask any human
to carry out a task dozens, hundreds or even thousands of times and
you will find there are inconsistencies / errors - which are further
componended by the fact that in most large organisations there are
different individuals and teams performing these tasks (most notable
the Development and also the Operations teams).
By automating that into a single process, we can be assured what we
deployed is always going to work. We manage and control all of the
items that are going to be deployed; that is the code but it also includes
the configuration. An important benefit to note about deployment
automation is that "you are not only testing the application code - but
the release process itself". A key objective here is we are increasing
our confidence in the release process - because we are testing the
same process time and again, to provide a much greater assurance
when deployed ultimately to production.

4. The CIO’s Guide to Automated Deployment 3
What should an automated build and
deployment tool provide?
First of all, if we’re looking to purchase an automated build and
deployment tool or maybe look at an open source tool, what we’re
really looking for is something that will provide good security. We need
to be able to secure who can do builds and deployments into targeted
environments, so it needs to be very fine-grained. A fine grained
security model also allows you to define different capabilities to roles
within your organisation - developer, release manager, operations, etc.
will all likely need to perform different functionality - whether its define a
new automation activity, release a version of and application or
approval a deployment to a production environment.
We also want it to be auditable, so we can see who has deployed what
to where and when. We also need to have a tool that has a friendly
graphical user interface at the front-end, ideally web-based.
We also want a tool that will support most of my organisation’s
technologies, out of the box. And, where it doesn’t support those
technologies, perhaps where we have some legacy technologies, we
want good integration points so that we can call existing scripts and
existing deployments processes.
We also want the ability to be able to extend the tool, so that we are
able to automate those processes that are bespoke to an organisation
or that are not handled out of the box.
What does an automated build and
deployment solution replace?
Many organisations have a combination of manual or partially scripted
processes for both build and deployment. Now, more recently, there
are a number of tools that have come on the market for build
automation and so that tends to be better done than deployment
automation.
When it comes to deployment automation, there are still a lot of manual
processes. This will typically be a number of scripts, which will be
written for a particular platform. These will be run manually, by
individuals, which results in a number of totally manual processes.
People may be typing something to come online or using a graphical
user interface to make some manual changes.

5. The CIO’s Guide to Automated Deployment 4
4
These do not lend themselves at all well to
controlled deployments.
As a result, we’re often left with a situation where a deployment to a
production environment will simply not work. You’ll hear the expression,
“Well, it worked in my test environment. Why is it not now working in my
production environment?”
The reason is because somebody has forgotten to do something.
They’ve mis-configured something. This leads to all kinds of problems
and it leads to a lot of fear. A lot of managers fear deploying code to
production because they don’t know if it is going to work.
We want the ability for to be able to complete a build and the
deployment without understanding the underlying infrastructure, without
understanding the underlying code, without understanding the
underlying scripts, if there are any. It should be completely seamless
for that person. What we’re talking about here is the ability to
completely automate our process. We don’t want any jumping out to
run command-line scripts. We don’t want any manual intervention at all.
It should integrate well into a configuration management tool, so that
you can manage change over time, you can compare change over time
and you can compare change between environments over time. For
example, by taking a snapshot of an environment now and then
compare it with that environment in three weeks time.
Or I can take a snapshot of a test environment and compare it with the
production environment. In this way, I increase my confidence that my
deployable artifacts are always going to deploy successfully every time.
Do I need to use the same tool for both build
and deployment automation?
There isn't a single tool that provides all the capabilities an organisation
will requires and almost without exception there will be a requirement
for a separation of the build and deployment capability However, what
is important is that the tools and processes are tightly integrated.
The build of software or deployable assets is start of the release
process for operations teams. Conversely the release of these assets
to production should be the end of the cycle for the development team -
and as such the tools for the creation and release of assets need to be
closely linked. The idea that a Just In Time delivery system could run
efficiently if the warehouse and the store did not have integrated tools
and processes is easy for anyone to understand - but this analogy is all
too common for a lot of IT organizations where you will have silos
between the development team and the infrastructure team.

6. The CIO’s Guide to Automated Deployment 5
Quite often, the development team will build the code using whatever
build tool they’re using. Then they’ll throw that over the fence to the
infrastructure team, who will then deploy it.
There’s very little collaboration between the two, as they often don’t
know what configuration changes they should make. They might be
detailed in an e-mail. They might be detailed in a spreadsheet; it is very
easy to make errors.
If you’ve got large numbers of environments, it becomes very difficult to
manage. It’s extremely important that the build and deployment are
coupled together, as tightly as you can, so that you have a seamless
deployment process from the development of a piece of code right
through to that being deployed to the production environment.
What are the key benefits to a development
team of an automated solution?
Often, developers are really keen on doing development, but they’re
not really interested in managing code releases over time. They’re not
really interested in how that works in production. On the other hand,
infrastructure teams are very interested in this.
For a development team, having a build tool that they don’t really need
to think too much about is very good for them. They are just checking
their code. The build tool builds it automatically, it creates a label, and it
creates a deployable artifact that they’re able to then deploy. They don’t
want to be wasting time building code, making sure it works properly
when they could be going on with what they’re really interested in,
which is doing development.
What are the key benefits to my operations
team of an automated solution?
Efficiency and consistency are two key benefits operations team should
notice immediately. It would not be unusual where a set of manual
steps are followed for a release for this to take 30 to 40 minutes even
for a relatively straight forward application. When this activity is
repeated dozens or even hundreds of times - it is inevitable that
mistakes will occur. Conversely, an automated deployment solution
should not only reduce the elapsed time for a deployment to happen
significantly - but it should also but near guarantee that it occurs
consistently.

7. The CIO’s Guide to Automated Deployment 6
6
Really, the amount of time you spend is just clicking the button to do
the deployment. It then happens seamlessly. The other thing is we
don’t have to provide out of hours support because people can do a
self-service deployment. What we’re trying to achieve here is a
complete end-to-end solution that makes it very simple for them to do
deployments.
It means developers, testers, and
managers, depending on their role,
can do their own deployments in a
controlled manner to target
environments, without ever actually
touching any of those environments
themselves.
It also means we have a complete audit of what we’re doing. For
example, from a manager’s point of view, they can see reports over
time about how many deployments have succeeded, how many have
failed, how many deployments we’re doing.
Really, it’s removing the need for administrators to do the mundane
tasks of handling deployments, day in and day out, and freeing them up
to do value creating activities, such as designing new infrastructure and
building new environments.
What are the key benefits to IT
Management of an automated solution?
You will hear often hear the question, “Why can’t I deploy this
environment?” being asked. The answer will be: “Joe Blogs isn’t here
today and he’s the only one that knows how to deploy this environment
and it’s all in his head.”
Now, if we automate the solution, nothing is stored in anybody’s head.
Everything is stored in a configuration management tool, in files, in a
database. The knowledge of the application build or the application
deployment is there for everybody to see. Anybody can do a build and
anybody can do a deployment.
For a manager, this is fantastic because the last thing that they want is
single point failure, as that creates all kinds of problems. For example,
what happens when that person is on holiday? Or worse - hit by a bus!

8. The CIO’s Guide to Automated Deployment 7
Secondly, the manager really wants to know what’s happening in his
deployment estate and he really doesn’t want to have to get down to
the nuts and bolts of logging onto servers to try to find out. If we can
have a comprehensive suite of management reporting that will show,
for example, where a particular version of code has been deployed to
over time. Or, for a particular environment, what versions of code have
been deployed to that environment over time. A whole set of
management information becomes available, enabling a better
understanding of when things are going wrong.
What business benefits does an automated
solution give me?
With an automated solution, the ultimate benefit is cost-saving, which
will be visible in terms of time to market. It enables testing cycles to be
done more quickly, allows for faster deployments, and provides greater
confidence about deployments. Also, if I have a fully automated
solution, I can manage my environments much more effectively.
I can leave code on expensive infrastructure for shorter periods of time
and I can reuse that infrastructure much more efficiently and, therefore,
save an awful lot of money. Infrastructure costs can be so high for large
organisations managing that infrastructure effectively is very, very
important.
Do I need to adopt different Automation
approaches for different technologies?
Ideally, it’s better not to use different approaches for different
technologies. What we really want is a single deployment and a single
build solution that can be extendable to multiple technologies. That will
mean it will have many different integration points with those
technologies.
In any case, the graphical user interface, the management, the
security, the auditing and the actual deployment onto the target servers
should be the same. It is only when we get down to the integration point
of the individual application that it will be slightly different.

9. The CIO’s Guide to Automated Deployment 8
8
What are the key steps in implementing an
Automated solution?
The first thing to do is to establish what the existing processes are in
place. Is it entirely manual? Do they have some existing scripts? Do
they have some existing deployment process? It’s possible that some
of those scripts, if they exist, which they probably will, could be reused.
We do need to consider if this is the right thing to do? Should we reuse
those scripts or are they actually a problem in themselves and should
we completely rewrite the solution or use the solution that comes out of
the box with the tooling? That’s the first thing.
Secondly, and very, very importantly, we need to get a key stakeholder
buy-in to making a change to the process. It is often quite a radical
change in process that’s required. We need the development teams to
buy-in. We need the management teams to buy-in. The testing teams,
the infrastructure teams also have all got to be onboard with this.
Otherwise, it’s really going to go nowhere and you could end up
throwing an awful lot of money at this problem to no great benefit.
Once we’ve got those two things sorted out, we need to choose a tool
that we’re going to use. You’ll need to prove that the tool can be
extended for all your technology types; it should cover most of the key
technologies that you use. As we spoke about before, it really needs to
be able to encompass your entire technology stack, not just a small
part.
We then need to run a proof of concept, usually, find out if it does
actually work and then stage implementation. Normally, that would take
the form of implementing on one project, perhaps a key project that
you’ve got. You can try the implementation on that, run it parallel with
the existing methodologies and, once it’s proven, then you would role
that out to the entire estate.

10. The CIO’s Guide to Automated Deployment 9
Are there any particular considerations if an
organisation has already written some
automation scripts?
In this case, we need to consider whether those scripts are still fit for
purpose, whether they can be integrated into the tool or whether we
should look at those scripts and rewrite them based on the new
deployment tool that we’re going to use. This will be the case in a lot of
organisations.
They will often spend a lot of money developing a suite of scripts and
there will quite often be resistance to having those scripts removed
because of the people’s investment in time and money in producing
them. Really, we need to look at this in a dispassionate way and
decide: Is it time now?
It’s time to move away from using scripts and move towards using tools
that have been designed and built entirely with automation in mind, so
that we can remove those single points of failures, remove those cases
where everybody has tried to reinvent the wheel in every different
organisation and move to an industry best practice where we know that
we’re going to have success from day one.
How complex is it to automate build and
deployment activities?
This varies depending on which approach you’re going to take. If you
decide to stick with the bespoke scripted solutions, then this is
obviously very complicated. You need to get people that are skilled.
You also need to consider platform support.
Am I going to write scripts for Unix and then have a requirement to this
capability on Windows? Am I going to need to run on AS400? You
need to consider all of the technologies that you need to support and
you need to write the bespoke scripts for all of those.
You need to think about all the processes you’re going to implement. It
is very, very complicated and very, very time-consuming.

11. The CIO’s Guide to Automated Deployment 10
10
Then, of course, you’ve got the option to
move to an automated tool. Now, if you’re
going to move to an automated tool, this
should simplify the process considerably.
It will depend on whether that tool is going to cover all of the
technologies that you expect to have to deploy or whether it will just
cover some of them. It’s key when choosing the tool, that it is easily
extendable.
You need some kind of orchestration process that enables you to carry
out business processes over and over again, so they are repeatable
and have easy extension points out to your various tools. This would
include scripting, perhaps a Java API, any other kind of API that might
need to be supported.
Is deployment automation only applicable
to large organisations?
Arguably, deployment automation is
applicable to every organisation,
irrespective of its size. Clearly, in a large
organisation, it is vital. In smaller
organisations, you’ll often find that the
build and deployment role is done by
people who are not naturally suited to or
employed for that role.
For example, developers will be doing builds and then you might have
a Unix administrator whose day job is to manage the Unix estate, who
is also doing deployments. That is not their key job. They don’t really
want to do it. They haven’t put a lot of effort into it.
In those scenarios, taking on board a deployment tool or a build tool will
free those people up to do the job that they’re supposed to do. Plus, it
will mean the deployments and the builds are done in a consistent
manner. Presently, this might not be the case because the person is
doing it as overtime or not part of their day job; they’re just filling in
every now and again.
For example, you get the scenario where, somebody says, “I need to
deploy this code,” and the Unix person who’s doing his Unix job says,
“I’ve got these four jobs to do and then I’ll get around to you this
evening at 5:00,” instead of that person simply being able to go deploy,
clicking on a button, it’s all done.

12. The CIO’s Guide to Automated Deployment 11
Are specific technologies more suited to
automated deployment?
I believe almost all, if not all, technologies can be automated. Normally,
most enterprise technologies will have a scripting interface or some
other interface that allows them to be controlled in an automated
fashion. Many other technologies via scripting can be automated in
some way.
I don’t believe I’ve really ever come across anything that couldn’t be
automated in one way or another. Even if it comes down to copying
files and performing search and replace on the target servers, usually
something can be done.
What are the different types of automation
tools available?
IBM Rational and Atlassian are two key significant vendors in the
provision of commercial build tools. Hudson / Jenkins and Maven have
are particularly dominant in this space - and for good reason! There are
also numerous other opensource tools available.
The key opensource projects / tools for deployment automation are
Puppet and Chef. There are others but these two are market leaders -
and focus on the automation of opensource targets such as Tomcat,
MySql, etc. At this time they do not provide any significant capability for
commercial middleware and database platforms (i.e. WebSphere,
Oracle, etc.).
Of the large providers IBM and BMC are more established in this space
- although more recently HP and others are developing their
capabilities.
There are a number of niche vendors specialising in Deployment
Automation - most notably UrbanCode, Noliosoft and MidVision. These
vendors focus more on enterprise / corporate middleware platforms
(WebSphere, WebLogic, etc.) and differ from the open source vendors
in that they are easier tools to adopt - with a quicker / simplier adoption
process focusing on the 80 / 20 rule of benefits / time invested.

13. The CIO’s Guide to Automated Deployment 12
12
What is the future for Automated
Deployment?
I think where we’re going with automated deployments is more around
the entire environment lifecycle management. At the moment, people
are concentrating on taking a piece of code and deploying it through
environments to production.
Where I think this is going to go is doing that is a part of much bigger
process. This would involve somebody requesting an environment in
the first place, that environment being approved, built on a target set of
servers, and then going through an entire lifecycle of deploying
versions of code over time.
In this space, we start to talk about environment leasing. A project in a
large organisation may lease an environment for a period of time. Once
that environment lease has run out, they stop paying their lease cost,
that environment is deleted. That really focuses the mind for a project
manager. “Do I really need this environment? I have to pay for it. Do I
need it? Can the infrastructure be reused?” It helps to make the
environment more fluid.
There are many more environments built over time. It also means that
you’re making best use of your infrastructure, which is a high cost in
most organisations.
Who should be involved in a build and
deploy automated deployment solution?
The teams that need to be involved in doing the complete end-to-end
automation are going to be the development team and the
infrastructure teams and also the testing teams.
Really it’s a whole organisational shift to
move away from having a siloed approach
to development and deployment, to a
mindset to say, “We have a single solution
that everybody uses.”
The developers buy into it. The testers buy into it. The infrastructure
teams buy into it and it’s a seamless end-to-end solution and that does
require the whole organisation to think about the way they currently
work and perhaps consider moving to a new way of working.

14. The CIO’s Guide to Automated Deployment 13
Have you got further questions about
automated deployment?
Do you still have unanswered questions about automated deployment
and how it would work in your organisation? Please get in touch with
MidVision and we’ll be more than happy to answer questions for you.
www.midvision.com
+44 20 7643 1621