Automating the Application Release Process: Build vs. Buy

Transcription

1 WHITE PAPER SEPTEMBER 2014 Automating the Application Release Process: Build vs. Buy Application Delivery

2 2 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Table of Contents Executive Summary 3 Section 1: Building the Release Process 4 Section 2: Executing the Process 7 Section 3: Managing Application Release Automation 10 Section 4: Conclusions 11

3 3 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Executive Summary Challenge As application complexity continues to increase, and the demands on business to improve their time to market continues to grow, Application Release Automation has become an important capability in IT. Rapid development cycles (fueled by development strategies such as Agile) mixed with the complexities of multi-tier applications distributed across multiple, disparate environments is further complicating application deployments and creating yet another bottleneck in the Application Lifecycle. Throwing more people at this problem to remove the bottleneck is not cost efficient. Today, we are seeing more and more companies adopting Application Release Automation to address this problem. For some though, the idea of Application Release Automation is simply a case of tasking their developers (or other employees with the relevant skills) with writing shell scripts that automate the deployment activities. Many times this is an approach that is recommended by the developers because they feel comfortable writing scripts They write code all day long, so why not do the same for Application Release Automation?, but sometimes is decided by management who have, understandably, no insight into the limitations of scripts ( You can do anything with a script, right, so let s do that. ). Either way, it is important to understand the limitations of a script-based approach to Application Release Automation so that you can make the right decision for the business. Below we will discuss those limitations and how CA Release Automation (formerly CA LISA Release Automation) can help overcome them.

4 4 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Section 1: Building the Release Process Time and effort Using scripts to build the deployment process means having to not only define and build the process itself, but build the underlying deployment capabilities as well. Scripting technology was not built with application deployment in mind, meaning each step involves not only thinking about what needs to be performed in the context of the deployment process, but also how that can be achieved in the chosen scripting language. Instead of this, why not take advantage of an Application Release Automation platform that has already been proven in diverse environments across the world? CA Release Automation includes over 80 Action Packs with over 1400 out of the box actions to integrate solutions and technology used throughout the application delivery tool chain. This by definition results in a significant time saving. Wouldn t it be more beneficial to have the developers of the scripts doing their day job, rather than building an application release automation platform that already exists? If the application developers are building the automation scripts then surely their time would be better spent developing the application itself, resulting in faster time-to-market and ultimately helping the business to compete and even develop a competitive edge. As an example of how CA Release Automation can help to save time, one of our large financial customers wanted to build a deployment process for 20 end of day servers. To do this manually it took four hours for each server, resulting in a total of 80 hours to complete the deployment. In comparison, using CA Release Automation, it took three hours (less than the time it took to deploy one server) to build the process, test it and run it against all 20 servers. Reusability and best practice The characteristics of scripting typically limits reusability and the implementation of application release best practices. The individuals building the script can literally do whatever they want. Even if that does not include basic best practices such as steps for checking the state of the application prior to doing a deployment, or verification of the process post-deployment. Re-use generally becomes a case of copying the script and making changes to the copy for a specific environment. This creates a major headache when scripts have to be changed to accommodate a new application release with a different deployment process. With CA Release Automation, actions are put together in flows (pieces of a process that achieve a specific task) and then everyone can use that flow in their process. If the underlying flow is modified (as the application evolves) then all processes using that flow will automatically use the updated flow. In this way, CA Release Automation helps you save time and to promote the use of application release best practices and reusability across processes. Cross-server synchronization A typical deployment process involves executing steps on multiple servers and server types. For example, it may be necessary to upgrade the database server first, and then move on to upgrade a number of application servers. With a script this is difficult to achieve. Scripts do not have a built-in concept of servers and dependencies between servers. How are two different scripts running on a number of

5 5 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com different servers synchronized? One way of doing this is to not perform the steps locally on each server but rather run them from a central server that remotely accesses each target server. This method leads to serialization of those specific steps, as opposed to executing the steps on all the application servers in parallel. This can often put maintenance windows under pressure. And once this serial browscript has been written, how easy is it to change if the deployment process changes? What if there is a distributed environment with multiple database servers each supporting their own application servers? How can these complex relationships be managed? Figure A. A multi-tier process showing crossserver synchronization With CA Release Automation, processes are created visually, dropping individual actions (steps) onto the relevant server type, and simply drawing links between those server types. This is done logically, without specifying which specific servers are involved in the process, so that changes can quickly be made to the servers and their dependencies as required, without having to modify the process.

6 6 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Figure B. Environment configuration A list of servers in that environment and their relationships with each other is maintained (e.g. which database server works with which application server). Out-of-the-box integrations Scripting languages were not built with application release automation in mind. Therefore they only include capabilities for basic steps such as copying files, running external commands etc. CA Release Automation has over 1400 action types available out of the box. These include actions for basic file and folder management, string/parameter manipulation, package installations (e.g..exe,.msi and rpm s), reading and writing to/from XML and INI files, command line execution, SOAP calls etc. In addition there are specific actions for technologies such as manipulating VM environments, working with EC2, F5 Big IP, WebSphere, Weblogic, databases etc. As well as actions for integrating with other tools in the Application Lifecycle (e.g. Subversion, TFS). Multiple environments When working with scripts, it is not unusual to find the server names embedded (often in multiple places) within those scripts. If the script is then to be used in a different environment, a new version of the script must be created with different server names. This takes up additional time to both create and maintain those scripts in the future. CA Release Automation on the other hand, deliberately separates the logical process from the actual servers on which the process will be run. The process is joined with the environment information at the very last moment, at run time. Therefore, deciding to run the process on a different environment is a simple task of defining the environment within the user interface and pointing the process to run in that environment. There is no need to go back and modify the actual process itself to accommodate the new server names. As well as saving time, this allows the process to be matured through the pre-production environments, so the same process can be confidently deployed into production.

7 7 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Section 2: Executing the Process Multiple environments During execution of a deployment process, it is important to understand what happens at each step along the way. There needs to be a clear view on what steps work, and most importantly what steps do not work. A script is a black box. In the event of a failure, doing something simple such as determining which step failed is not easy and therefore not quick. Significant time can be lost just finding this out. Where there is output from a script it is generally in techie speak rather than in human language. With CA Release Automation the process is shown during execution, with each action changing color as it is performed, clearly showing which steps passed (green) and which failed (red). Each action has a human readable name such as Copy Release Package, so in the event of a failure it is instantly clear what step in the process has failed. Figure C. Process execution

8 8 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com A failure is clearly and instantly recognizable and can be dealt with either by building in a failure path (as in the example above) or by pausing the process at that point and notifying someone of the problem, so they can fix-forward. Pause/resume When a script is run it is either left to finish of its own accord, or aborted part way through at a random place (depending on when the operator pressed CTRL-C). Once aborted the script has to be started again from the beginning. With CA Release Automation it is clear to see the stage the process is in during execution and an operator can press the Pause button at any time. As discussed above, a failed step can also automatically trigger a pause. Once paused, the process can be resumed, and the operator can decide whether the current step should be performed again, or if it should be skipped. There is no need to restart the process from the beginning. Execution time Typically a script is written to handle one piece of an application. A deployment can then involve someone running a series of scripts in a given sequence, waiting in between for each script to finish. This is a very inefficient approach. CA Release Automation provides a single run button to execute the entire process, encompassing steps on multiple servers and including synchronizing those steps as discussed earlier. File distribution In a traditional script approach, if the process was to copy a package of 100 application servers then that file would need to be copied 100 times from its source location to each of the target application servers. CA Release Automation architecture allows for one copy to take place from the source location to the nearest Execution Server, the file can then be transferred once to another execution server and then copied locally to each target application server. By placing the Execution Servers in the right place network bandwidth utilization can be reduced. This is particularly useful if the copy needs to go over a restricted bandwidth connection.

9 9 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Figure E. CA Release Automation architecture. Reporting Being able to perform a deployment is one thing. Being able to capture all the results, provide the reporting information and prove compliance is more difficult. Basing application deployments on scripts will not address the reporting requirements. CA Release Automation on the other hand, stores all the information in one central repository. This will include information about each execution, such as: Who ran the process, what process was run and in which environment, how long the process took, a complete drill down to each step of that run with a timestamp and status information, and also server by server information. This information is available in detailed reports as well as a more management-friendly dashboard. With this information all the stakeholders can be kept informed of what is happening in the application environments, and use this information for compliance related purposes when required. Queue management When performing a deployment it could be disruptive, if not disastrous, if another process was run on those same servers at the same time. What happens if one process tries to use a file that it copied to that server, but in the meantime another script has replaced that same file with a file of a different version? With the use of scripts there is nothing to stop a conflicting script being run at the same time. CA Release Automation provides a built-in queue management feature designed to prevent a process requiring the same resources from running at the same time. A process which requires the use of a server that is already running an application release process is automatically queued until the previous process is finished. In this way the context of each execution is maintained for the duration of that execution.

10 10 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Who runs the process? In order to understand exactly what caused a script to fail it is often necessary to involve developer(s) of the script. Someone who is not familiar with the script or the scripting language will find it difficult and therefore time consuming to find the root cause of the problem. CA Release Automation provides clear information about what is happening in the process, which helps the user to clearly see the step that failed (if any) in an easy to understand way. Therefore, the developers are not required to be involved in the deployment process to each and every environment in order to interpret the results. Section 3: Managing Application Release Automation Access control Once a script has been built, how can usage of that script be controlled? More importantly how is access controlled in such a way that it is restricted by user, by application, by environment and by process? For example, it may be okay for the development team to use those scripts to deploy applications into their own development environments, but for Staging and Production environments that process is usually controlled by someone else. This is hard to control when relying on operating system level access rights to the scripts, and it is easy to lose track of who has the rights to each script in each environment. With CA Release Automation, granular permissions can be set for each user, restricting them to specific applications, environments and processes. Therefore it is easy to control who can do what and where. This can be particularly important in environments that dictate that a single person should not be able to deploy into both pre-production and production environments (often called separation of controls ). Figure F. Permissions management

11 11 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY ca.com Process lifecycle Once a script has been built there is little to stop it from being run. With CA Release Automation we separate design from execution through a Publish capability. The ability to publish a process can be restricted to specific people, and therefore introducing the concept of approving a process before it is published and available to use in the environments. Collaboration platform Following on from the above, CA Release Automation provides a collaboration platform that is not possible when using scripts. Different people can share the responsibilities across the process lifecycle, and be restricted to which parts of that lifecycle they participate in. For example, the developers may build the individual steps (actions) and flows (as discussed earlier), while a process expert puts the process together, a Release Manager approves and publishes the process, and the Environment Owner performs the actual execution. This separation is not imposed; the administrator defines the roles and permissions as required. This means the ability to get involved in application deployments is not restricted to those who can build or understand the scripting language. Locking down an environment In order to run a script the operator needs to have the relevant username/password to run that script on the target server. With CA Release Automation the credentials to each server can be kept private, instead users login to Release Automation and their specific permissions enable/restrict them to only what they are allowed to do. All deployments performed are tracked (with time stamps, user associated with the execution, etc.). By not giving users direct access to the environment, configuration drift is minimized or even eliminated, and the risk of service levels being affecting by a new application deployment can be significantly reduced. Section 4: Conclusions Once the concept of automating the application release process has been embraced, the next question to be answered is how to go about achieving the automation desired. It is not uncommon at this stage for the suggestion to be raised to use in-house skills and harness the power of scripting for this task. On the surface this may seem like a sensible approach. There are often skills in house proficient in scripting languages so why pay for a new product and the training involved to use the product. It is important to stand back, and take a wider look at automation. For some reason, scripting can often be seen as the safe choice simply because it is a known entity. But surely, wouldn t the safe choice be to rely on a product developed specifically for the task in hand? Any automation solution needs to be widely accepted by the organization, not just the domain of specific technical people who understand how to write scripts. The solution also needs to be versatile, promote reusability and best practices, and support complex cross-server dependencies and synchronization, while at the same time allowing users to easily understand the state of the release at each stage. A viable solution also needs to enable non-developers to get involved in the application deployment activities, and control with confidence who can do what in each environment. It also needs to support the reporting needs of all types of stakeholder across the business.

12 12 WHITE PAPER: AUTOMATING THE APPLICATION RELEASE PROCESS: BUILD VS. BUY More than that, the solution needs to be proven in diverse environments, giving peace of mind that as your requirements change and your technology platforms evolve (as they always do) the chosen release automation platform will support those new requirements while providing the capability to integrate with other tools within your application lifecycle. An application release automation solution needs to do all the above, without taking up an organizations valuable resources to build and maintain that automation capability. Time better spent focused on delivering the innovation the business requires to be successful. In-house developed scripts will not do this. CARelease Automation will. CA Release Automation CA Technologies, is a provider of application release automation solutions aimed at automating application release deployment and other operational service tasks essential for releasing and managing the production of distributed, multi-tier data center applications. The company s solution allows IT operation teams to model application release workflows across various application tiers and environments, enabling automatic deployment for application changes, maintenance, troubleshooting and rollbacks. Workflow execution is performed across a heterogeneous data center infrastructure, providing an accurate and flexible model for managing application change across physical virtual and cloud servers. The application-centric approach to data center automation from CA Technologies consolidates application service knowledge across application silos, including development QA, and operations, affording centralized control over application operations. Connect with CA Technologies at ca.com CA Technologies (NASDAQ: CA) creates software that fuels transformation for companies and enables them to seize the opportunities of the application economy. Software is at the heart of every business, in every industry. From planning to development to management and security, CA is working with companies worldwide to change the way we live, transact and communicate across mobile, private and public cloud, distributed and mainframe environments. Learn more at ca.com. Copyright 2014 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational purposes only and to the extent permitted by applicable law, CA provides it as is without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or noninfringement. The information in this document is based upon CA s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, business interruption, goodwill or lost data, even if CA is expressly advised in advance of the possibility of such damages. CA does not provide legal advice. Neither this document nor any software product referenced herein serves as a substitute for your compliance with any laws (including but not limited to any act, statute, regulation, rule, directive, standard, policy, administrative order, executive order, and so on (collectively, Laws )) referenced herein or any contract obligations with any third parties. You should consult with competent legal counsel regarding any such Laws or contract obligation CS