Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Ranger4 Guide to Application Release Automation


Published on

In this Guide from Ranger4 to Application Release Automation (ARA) we cover:
1) What ARA is
2) Why you should have it
3) What to look for in a vendor
4) Considerations at implementation time
5) Ranger4 recommendations

Published in: Technology
  • Be the first to comment

A Ranger4 Guide to Application Release Automation

  1. 1. A Ranger4 Guide to Application Release Automation © Ranger4 2014 1
  2. 2. 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 © Ranger4 2014 2
  3. 3. 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. © Ranger4 2014 3
  4. 4. 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. © Ranger4 2014 4
  5. 5. 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. © Ranger4 2014 5
  6. 6. 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. © Ranger4 2014 6
  7. 7. 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 © Ranger4 2014 7
  8. 8. 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 © Ranger4 2014 8
  9. 9. 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 © Ranger4 2014 9
  10. 10. 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. © Ranger4 2014 10
  11. 11. 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 © Ranger4 2014 11