A Ranger4 Guide to Application Release Automation

A Ranger4 Guide to

Application Release Automation

www.ranger4.com © Ranger4 2014 1

http://www.google.com/url?q=http%3A%2F%2Fwww.ranger4.com&sa=D&sntz=1&usg=AFQjCNFVDEXbd4GQxVLiqSaw6TEFPEyAtQ

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-Live3.2 Composite deployments3.3 Graphical User Interface3.4 Pre-built task library3.5 Role-based security3.6 Breadth of support

4.0 Considerations at implementation time4.1 Cultural change4.2 Process Change4.2.1 Configuration and Build Management4.3 Choose your project4.4 Create a Production Like Environment

4.4.1 Shift Left4.5 Practice production-style deployments4.6 Design for production first

5.0 Ranger4 Recommendations



1.0 What is Application Release Automation?

Application Release Automation (ARA) refers to the process of packaging and deploying anapplication 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 bedeployed at the same time

● Dependency Mapping - modeling full application dependencies between componentsof the application

● Software Deployment - using package contents to install applications and configuretheir 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 developmentand operations teams as a result of businesses’ need to deliver more innovation to theircustomers via applications and infrastructures of ever-increasing complexity. Wheredevelopment are all about change, operations are driven to control the stability of theenvironments they manage and deliver the highest possible uptime to the business - andchange puts all of that at risk.

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

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



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 ofminutes) 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 thewall’ into the operations team for deployment into production. This causes conflict wherethe operations team have not had enough visibility of the release coming through (anddevelopment want it live now because the business is putting pressure on them) andoperations struggle to plan it into their planned work schedule (often because they are toobusy with unplanned work/firefighting as a result of previously broken releases).Additionally, code often behaves differently in production than in development and testingdue to environment configuration changes that are often difficult to identify.

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

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



3.0 What you should look for in a vendor

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

1) All releases performed manually2) Some scripts have been written3) A LOT of scripts have been written4) Some tooling has been written around the scripts to provide things like a GUI orintegrations to other tools e.g. for configuration management or build engines5) 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 forthe 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 ifin-house resources have already been applied to partly resolve the problem and we arewell-versed at Ranger4 in performing a gap analysis of existing capabilities to ARA vendortool 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 apackage of code and configuration that you can push through all of your environment stagesthrough 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 - forexample you might have a Java application running on an Oracle database in an IBMWebSphere Application Server cluster using IBM WebSphere MQ and Integration Bus. Youshould just be able to create one deployment of your application made up of its multiplecomponents.



3.3 Graphical User Interface

Not only should you look for an GUI (browser based) that is clean and easy to use, mostenterprises also will want tools that don’t require specific programming knowledge to useand that don’t use scripts. The GUI may also be able to help you graphically visualise yourenvironment 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 basedprocesses that are error-prone and difficult to troubleshoot and audit. Finding a tool thathas pre-built tasks that can be selected and added to a configuration package fordeployment provides a faster, more flexible and consistent release mechanism than adeployment framework product that relies on input of difficult to manage and unpredictablescripts.

3.5 Role-based security

One of the key benefits of an ARA tool is the elimination of bottlenecks as you allow yourdevelopment 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 theprojects and environments they are involved in - and not the ones that they aren’t. Thesecurity model needs to be fine-grained, customisable to your unique requirements and willalso provide be key to you being able to prove to your auditors that your process is fullycompliant (particularly around areas such as segregation of duty).

3.6 Breadth of support

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



4.0 Considerations at implementation time

Implementing ARA and DevOps requires change - and change can be painful and is oftenresisted. Here are some pointers on how to make your ARA implementation project gosmoothly.

4.1 Cultural change

When you implement your ARA solution you’re going to be asking some of your resources toperform more of the release cycle than they are used to, and others to let go of some oftheir 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 teammembers should be ready to adjust their methods and frequency of interaction. But you alsoneed to be sure that they will accept automation solutions and the new/adjusted roles thatthey will play within the organization.

You might find that you are meeting resistance from the team to take on the automationbecause 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 messagecommunicated is about the business working faster, better, with less risk and that theirtalents can then be fully harnessed to continue to deliver more value, faster.

Some organisations, particularly those that have been acquisitive, are able to forecast thatthey will have an increase in applications/releases/workload whilst knowing that theirheadcount is unlikely to increase, may even be planned to decrease. ARA solutions can helpteams 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 whenit’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 newprocess and then carefully monitor its introduction. It’s unlikely that everything will be rightthe first time and so you’ll need to manage expectations in this phase and create anenvironment of continuous improvement. It’s worth thinking about the DevOps tenets aboutnot fearing or punishing failure (but failing smartly) and about not allowing a culture of



blame.

4.2.1 Configuration and Build Management

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

4.3 Choose your project

One of the key benefits of an enterprise ARA solution is being able to use a single processand tool for deployment of a multitude of applications across multiple platforms - but it’sbest to choose one place to start. Here are some projects that are often used to kick off anenterprise 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 environmentas a starting point for development. This environment will likely be smaller but should usethe same operating systems, middleware, and configurations as the productionenvironment. UAT is one of the four typical environments of the SDLC and provides anopportunity to test in a production-like environment. Production resources that areunavailable to test environments should be simulated through service virtualization, ifpossible.

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

4.4.1 Shift Left



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

4.5 Practice production-style deployments

If the ideal state that you want to achieve is a streamlined release consisting of automateddeployments, you need a consistent, repeatable process. To achieve this process, start bypracticing production-style deployments that can be simplified for earlier environments. Theenvironments themselves should also be as similar to production as possible. In a newimplementation, 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 environmentsshould 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 stabilizingpreviously manual steps in a complex process and reduces unnecessary effort in futuredeployments through repeatable, consistent templates- Eliminate the disconnect in deployment process complexity between earlier and laterenvironments.

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

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



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

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



5.0 Ranger4 Recommendations

Ranger4 have heaps of experience with ARA solutions and are well-versed in identifying thebest fit tool-chain for your business - an enterprise designed tool from IBM (UrbanCode) orMidVision (RapidDeploy) or perhaps your technical resource profile and infrastructurearchitecture 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 workthrough a proof of technology or concept with you. We are also well-practised in writingbusiness cases with our customers wherever they start on the maturity scale and measuringprogress through and beyond the project.

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

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



A Ranger4 Guide to Application Release Automation

Technology

Transcript of A Ranger4 Guide to Application Release Automation