Market Overview: Application Release Automation Toolsdocs.media.bitpipe.com/io_12x/io_125060/item... · Hp, IBm, Inedo, octopus, serena software, Xebialabs, and Zend technologies

Forrester Research, Inc., 60 Acorn Park Drive, Cambridge, MA 02140 USA

Tel: +1 617.613.6000 | Fax: +1 617.613.5000 | www.forrester.com

Market Overview: Application Release Automation Toolsby Amy DeMartine, January 29, 2015

For: Infrastructure & Operations Professionals

Key TaKeaways

Unleash your ability To Release software That your Company Depends OnSoftware is enabling enterprises to create products and processes to win, serve, and retain customers, and thus you must release software rapidly and continuously. ARA tools model, package, and deploy application releases and their associated configurations as the business technology solution progresses through the life cycle.

software-Powered Businesses Need your speed, Confidence, and ReliabilityARA tools give you control over how you create and deploy environments and how and when to deploy releases. The management of consistent environments is critical to ensuring that what you develop and test is the same as what you deliver to customers in your production environment. This control, coupled with automation, gives you the ability to release software quickly and reliably.

enable Control and support Frequency Of software Releases For your BT agendaThe ability to release software confidently and automatically into different environments is a key part of the software development life cycle. By automating and integrating this function, ARA tools can increase the flow of the overall life cycle while ensuring the reliability of these releases.

www.forrester.com

© 2015, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To purchase reprints of this document, please email [email protected]. For additional information, go to www.forrester.com.

For InFrastructure & operatIons proFessIonals

why ReaD This RePORT

Releasing software packages between environments such as development (dev), test, and production (prod) is a necessary part of the modern delivery life cycle. Application release automation (ARA) tools help firms release software consistently and in an automated fashion to these different environments as a key part of getting business technology solutions to end customers. Various levels of abstraction exist in ARA tools to define models of the hardware and software required by the business technology solutions, giving you the flexibility to deploy the software packages on-premises and in various cloud instantiations. These levels of abstraction, along with key integrations with other tools in the modern service delivery life cycle, complicate the decision factors for choosing the right ARA solution for your needs. Potential clients of ARA tools need to look for vendors that can automate modeling, packaging, and deployment of application releases and their associated configurations and that have built-in connections with existing modern service delivery tools.

table of contents

Break your Operational Paradox Of The Pre-Digital age with aRa Tools

Begone Those Dreaded scripts!

The Key Criteria That Make Up Leading aRa Tools

The aRa Landscape Offers Varied support Of Requirements

recommendatIons

Choose a Vendor That Makes Modern service Delivery Real

supplemental Material

notes & resources

Forrester interviewed 12 vendor and user companies: attunity, automic software, Bmc software, ca technologies, electric cloud, Hp, IBm, Inedo, octopus, serena software, Xebialabs, and Zend technologies.

related research documents

What makes modern service delivery modern?december 3, 2014

Gear up For modern service deliverydecember 3, 2014

seven Habits of Highly effective devopsoctober 2, 2014

Market Overview: application Release automation Toolsunleash Your agility With release automation For Better Business resultsby amy demartinewith Kurt Bittner, Glenn o’donnell, eveline oehrlich, and michelle mai

2

8

5

4

15

16

JanuarY 29, 2015

www.forrester.com

http://www.forrester.com/go?objectid=RES118424




http://www.forrester.com/go?objectid=BIO7024





Market overview: application release automation tools 2

© 2015, Forrester Research, Inc. Reproduction Prohibited January 29, 2015

BReaK yOUR OPeRaTiONaL PaRaDOx OF The PRe-DigiTaL age wiTh aRa TOOLs

In the pre-digital age, we made choices between speed, quality, and cost: to achieve two of these goals, we had to sacrifice one. In the digital age, customers use digital devices and expect digital services that they will get either from you or your competitors.1 By using automation and changing the way we develop and release digital services into smaller and faster releases, we can achieve speed, quality, and cost objectives at the same time.2 The role of tools in the modern service delivery life cycle is to automate processes to increase the quality and speed of delivery of business technology solutions while reducing cost. ARA tools are converging workload automation and release management tools, as they create release packages of business technology solutions that then are moved between different phased environments, such as dev, test, and prod. This sounds deceptively simple. However, the devil is in the details, and you must first understand the full stack, from infrastructure to your application, and decide how much of the stack you will govern to understand which features of ARA tools you require.

aRa Tools Create Release Packages

On the surface, creating release packages sounds simple. ARA tools model and package software code to be released on a specific set of hardware. However, these packages are deceptive. How much governance you are able to exert over your release package depends on how you create your model. Your model can:

■ Support modular design of the application. The business technology software may be created in a modular fashion and may therefore have a design to make parts of the software reusable and to hide complexity.3 Therefore, you must decide on what software to include, where to get it from, what order to install it in, and any dependencies you need to create a complete application model.

■ Define configuration. You can model configurations to show how the application, the middleware, or the infrastructure must be modified from their out-of-the box state to function properly. For example, any modifications to the OS or web servers fall into this category. These configurations can also define the login password and location of any systems of record that need to be integrated into the configuration.

■ Manifest middleware. Many applications require middleware. Middleware software packages also have release versions. Applications can depend on certain features or bug fixes of a particular release version of middleware. Pairing a version of the application to the right versions of middleware ensures that you have the right building blocks for the application.

■ Model infrastructure. The underlying infrastructure can also have a modular design. Modeling what the infrastructure contains can be as simple as the system the application runs on to the entire ecosystem of infrastructure, including the network, integrations to be modeled by service virtualization tools, and systems of record.




Release packages can contain a combination of these components but must include a model for the application itself. The most basic release package model would include a bill of materials of the different prebuilt software components and the order in which to install them. The more you put into your model, the more you can understand the scope of what is required to run your business technology solution. In this case, your model is like the graphics resolution of a TV: the more detail, the higher the resolution. When you pair a version of the application model with the configuration, middleware, or infrastructure model, you have defined a version of the release package (see Figure 1). You can then make changes to any of these components to make the next version of the release package.

Figure 1 Release Packages Are A Manifest In A Snapshot Of Time

Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.119004

Applicationversion A.1

model

Con�gurationmodel

Middlewaremodel

Infrastructurecon�guration

model

Sample release package




aRa Tools Move Release Packages Between Phased environments

As a version of the business technology solution moves through the life cycle, it typically starts in the dev environment, moves to the test environment, and then into the prod environment. Using continuous development techniques, versions can be in various stages of the life cycle at the same time (see Figure 2). Once you’ve defined a release package, you can deploy it on-premises or on any variation of cloud platform. You can create dev and test environments at will using these release packages.

Figure 2 ARA Tools Create Release Packages And Move Them To Support The Life Cycle


Testenvironments

Productionenvironment

Developmentenvironments

VersionB.2

VersionB.1

VersionA.3

VersionA.2

VersionA.1

VariousD

versions

VariousB and Cversions

BegONe ThOse DReaDeD sCRiPTs!

Even though releasing code into different environments as the life cycle continues seems like a simple problem to solve with scripting, it will only get you so far in your ability to continuously release code in a reliable and cost-efficient manner before you need a tool. Because release packages are moving through the life cycle continuously, you need to automate this process to accommodate many packages moving through different stages of release. Could this be handled by scripts? Yes. Scripts can very effectively accomplish the basics of ARA functionality. However, there are several drawbacks to using scripts for this process, such as:

■ The inability to visualize what release package is in which environment. Each release could have a different version of the environment that it is using. For example, a new web server could be used in version B.1 versus the A.1 version in production. Scripting makes it difficult to see these release package and environment pairs and understand where each version is running.




■ Difficulty in scaling. In a continuous delivery model, release packages are small, and many are deployed in various stages from dev, test, and production environments. Each of these release packages could be using a different version of the environment. Scripts would need to be modified for each release package and environment pair. As the number of release packages increases, the number of changes required in scripting can increase to an unmaintainable state.

■ The inflexibility of environment location. Each environment could be hosted in a different location, such as on-premises, private cloud, hybrid cloud, or public cloud. For example, the prod environment may be located on-premises, the testing environment in a hybrid cloud, and the development environment hosted in the public cloud. Developers of the scripts would need to understand and script to each environment and understand how to create release packages that install in each environment. This inhibits the flexibility to deploy different environment locations.4

■ The inability to easily interpret models that determine actions. Because scripts are procedural, they can be effective for driving action sequences. With more complex services, however, simple sequential execution is rarely effective and maybe even impossible. You need your tools to interpret the descriptive service and application models and then take the appropriate actions as needed to create a new reality as defined in the model. Scripts are inadequate for such model interpretation as decision triggers.

■ Unwieldy support burden. Scripts are tough to manage when the authors are totally dedicated to script coding and support. This is almost never the case. Because scripts tend to be a part-time job, even the authors find it difficult to return to the script code for enhancements or debugging. If the author leaves the organization, any knowledge of the script usually disappears with that person, rendering support extremely painful. Commercial tools are far superior in this dimension.

The Key CRiTeRia ThaT MaKe UP LeaDiNg aRa TOOLs

The two main basic capabilities of ARA tools are creating release packages and moving these packages between phased environments. For both of these basic functions, ARA tools will allow scripting to extend the out-of-the-box functionality. Don’t fall into the scripting trap inside the ARA tool. Focus on out-of-the-box functionality to limit your exposure to maintenance and development of scripts.

Criteria That support Creation Of Release Packages

Release packages are a set of models that define the manifest of the hardware and software required by the business technology solution. The more you put into this model, the more governance you have creating the environment as well as maintaining the integrity from drift and being able to roll back in case of failure. The complexity of creating and versioning these release packages means:




■ You must have governance over all release package models. The first level of governance is the definition of the model, so that no matter where the model is deployed, all environments are configured according to that model. This eliminates issues caused by drift of the environment. The second level of governance is being able to version the models. Versioning allows you to track which changes in the environment match specific versions of the application. If issues occur, you can track exactly what changes were made to pinpoint the problem and resolve it.

The requirements for ARA solutions: ARA tools must model the application even when the application is built in a modular fashion. A key capability is assembling the application from multiple builds. Additionally, ARA tools must allow for version control of the application release along with creating and versioning a bill of materials so that you can track all the component versions of the application and any middleware. You need to version the hardware environment that the application runs on as well as any infrastructure and configurations. Understand your needs for governance today and in the future to decide which tool has the right features for your business technology solution. If another tool owns the release pipeline management, the ARA tool will need to be kept in sync with this higher-level model, preferably through an open application programming interface (API) with appropriate security.

■ You must be able to roll back to a previous working state. If a newly released application package doesn’t work properly, the quickest path to getting back to a working state is to roll back to a previous working version. One part of the business technology solution you do not want to roll back is the customer data, which would cause customer satisfaction issues when customers have to re-input information. You want the capability to roll back the release package but also to keep customer data, called roll forward.

The requirements for ARA solutions: ARA tools are limited to rolling back only what is in the model. Anything else must be manually rolled back, thus opening you up to human error and insufficiently rolling back all of the software or configurations.

■ You must track drift. Because you have modeled your application, your underlying technology configuration, and the supporting software, you will know what the expected state will be in every instance of the business technology solution in every phase of development, test, and production. A drift indicates that someone has deviated the released application from its current state. Some ARA tools are able to detect a drift away from this model so that the drift can be corrected or the model can be modified to accommodate a required change.

The requirements for ARA solutions: ARA tools can only track drift of what is modeled. For example, if configurations are not modeled, you can’t track a drift in them. Tracking drift is a popular ARA tool feature that only gets more powerful when more of the stack is modeled.




Criteria That support Moving Release Packages

Moving release packages between dev, test, and prod environments is another key function of ARA tools.5 However, if the environment doesn’t exist, ARA tools will also have to create the environment before deploying the application. Using ARA tools gives you the flexibility to deploy to any on-premises or cloud instantiation by ensuring that all environments mimic what will be deployed into production. To get full functionality from an ARA tool for moving packages:

■ You must be able to create and decommission environments at will. If the environment doesn’t exist, a new one can be stood up based on your release package. This is helpful if you need to create environments in development or test. The benefit of this is that you are saving dollars on those systems when not in use. ARA tools can either do this creation and decommission as part of their base functionality or call other environment management tools to do so.

The requirements for ARA solutions: ARA tools have to be able to deploy to the OS or container that your business technology solution requires. Linux and Windows are the most popular OS flavors today supported by ARA tools. If public or hybrid cloud environments need to be created, ARA tools must support these cloud vendors. Amazon Web Services (AWS), Microsoft Azure, and VMware vSphere are the most popular supported cloud vendors today by ARA tools. ARA tools also have the possibility of decommissioning an environment based on a trigger, so that when the task is complete, the environment is returned to the available pool of resources. Integration with the various tools needed to perform these functions (e.g., Microsoft System Center, BMC BladeLogic Server Automation, VMware’s vCloud Suite) will be a key criterion for any ARA solution.

■ You must be notified if errors occur. If moving release packages between environments or creating or decommissioning environment errors out for reasons such as failing to provision an environment or any part of the deployment, you need to be notified so you can take corrective actions.

The requirements for ARA solutions: ARA tools support error notifications and can happen at a minimum either through the ARA graphical user interface (GUI) or through email or both. Some tools support other methods of notifications, but these are the most supported options by far.

■ You must be able to quickly define deployment rules. Different components of the release package may have a certain installation order. For example, you should install the OS, make any configurations required to the OS, install any middleware, make any configurations to the middleware, and, finally, install the application, in that order. Deployment rules can be quite complex and may include manual steps, especially when you first start implementing your ARA tool.

The requirements for ARA solutions: Most ARA tools have a GUI for deployment plans where you can drag and drop certain actions and rules. You can also use the prebuilt third-party plug-ins to augment the deployment to automatically install commonly used components. This feature is common across process automation tools such as run book automation or workload automation.




■ You must be able to easily create a model from an existing environment. When you are just starting the implementation of your ARA tool, the quickest way to get a model for your application release package is to take a snapshot of your existing production environment. This is also useful if development wants to test different environment configurations for performance. When you find the right one, you can take a snapshot to use as the release package.

The requirements for ARA solutions: This is not a common feature of ARA tools yet, but this feature gets you kick-started in your ARA tool implementation and allows flexibility in the future to first implement the release package and then model it later. How detailed the model is when taking a snapshot varies by vendor.

■ You must be able to have the ARA tools be callable by the continuous integration (CI) tools. CI tools provide workflow automation capabilities primarily focused on the build and testing process and can kick off a deployment of a release if the right conditions are met.6 The use of CI tools can help automate the life cycle and achieve uninterrupted flow through the life cycle.

The requirements for ARA solutions: By supporting an integration with the CI tools, ARA tools are able to be called to move releases between environments and deploy environments if needed. The most common CI tool support by ARA tools are Jenkins, Microsoft TFS, and JetBrains Teamcity.

The aRa LaNDsCaPe OFFeRs VaRieD sUPPORT OF ReqUiReMeNTs

The following profiles of prominent vendors can help steer you toward those vendors that are most likely to offer an ARA solution that fits your requirements. This section describes (in alphabetical order) the capabilities these vendors include (see Figure 3, see Figure 4, and see Figure 5).7 Prominent vendors include:

■ Attunity Maestro/Attunity RepliWeb. Attunity Maestro is a deployment automation and data workflow management platform. Maestro integrates with the Attunity RepliWeb for management and automation. Attunity RepliWeb is a replication and transfer automation solution for application releases, Internet Information Services (IIS) updates, content deployments, and WAN file synchronization.

■ Automic One Automation. The Automic One Automation platform is an end-to-end solution for planning, coordinating, and automating software release processes, including automated deployment of applications across large-scale server environments.

■ BMC Release Lifecycle Management Suite. The BMC Release Lifecycle Management Suite manages software release planning, coordination, application packaging, and deployment automation. The BMC Release Lifecycle Management Suite consists of BMC Release Process




Management, BMC Release Package and Deploy, and a limited license of BMC BladeLogic Server Automation for application automation. The community website for third-party plug-ins is https://communities.bmc.com/community/bmcdn/bmc-devops.

■ CA Release Automation. CA Release Automation is a continuous delivery solution to orchestrate and automate complex application release deployments from development through production. The community website for third-party plug-ins is support.ca.com.

■ Electric Cloud ElectricFlow Deploy. ElectricFlow Deploy automates and standardizes application deployments throughout the software delivery process. The community website for third-party plug-ins is https://github.com/electriccommunity/electriccommander.

■ HP Continuous Delivery Automation. HP Continuous Delivery Automation models infrastructure and application requirements while managing versions, configurations, and other application components. The community website for third-party plug-ins is for HP passport login only at https://hpln.hp.com/.

■ IBM UrbanCode Deploy. UrbanCode Deploy orchestrates and automates the deployment of applications, databases, and configurations into development, test, and production environments. UrbanCode Deploy with Patterns extends these capabilities with environment management capabilities that enable users to design, deploy, and update full-stack environments on multiple clouds. The community website for third-party plug-ins is https://developer.ibm.com/urbancode/plug-in s/ibm-urbancode-deploy.

■ Inedo BuildMaster. BuildMaster facilitates everything from continuous integration to database change scripts to production deployments. The community website for third-party plug-ins is http://inedo.com/buildmaster/integration.

■ MidVision RapidDeploy. RapidDeploy is a tool used to automate the deployment, configuration, and release of middleware, applications, and databases. The community website for third-party plug-ins is http://www.midvision.com/rapiddeploy-plugins-new.

■ Octopus Deploy. Octopus Deploy is a deployment automation system for .NET developers. Octopus works with your build server to automate releases of ASP.NET applications and Windows Services into test, staging, and production environments, whether they are in the cloud or on-premises. The community website for third-party plug-ins is http://library.octopusdeploy.com/#!/listing.

■ Serena Deployment Automation. Serena Deployment Automation is an application-centric deployment automation solution that supports continuous delivery and the deployment pipeline by simplifying and automating deployments across all environments. The community website for third-party plug-ins is http://help.serena.com/doc_center/doc_center.html#sda.

https://communities.bmc.com/community/bmcdn/bmc-devops

https://github.com/electriccommunity/electriccommander

https://hpln.hp.com/

https://developer.ibm.com/urbancode/plugins/ibm-urbancode-deploy

https://developer.ibm.com/urbancode/plugins/ibm-urbancode-deploy

http://inedo.com/buildmaster/integration




■ XebiaLabs XL Deploy. XL Deploy is an automation solution to support DevOps and continuous delivery teams. The community website for third-party plug-ins is http://xebialabs.com/products/plug-ins.

■ Zend Server. Zend Server provides a PHP stack including application release automation for PHP. The community website for third-party plug-ins is https://github.com/zend-patterns.

Figure 3 Prominent ARA Vendors


Vendor Product Name(s) Version

Attunity Attunity Maestro

Attunity RepliWeb

2.0

6.1

Automic One Automation 11.0

BMC BMC Release Lifecycle Management Suite 4.4

CA Technologies CA Release Automation 5.0

Electric Cloud ElectricFlow Deploy 5.1

HP Continuous Delivery Automation 1.3

IBM IBM UrbanCode Deploy 6.1

Inedo BuildMaster 4.4

MidVision RapidDeploy 3.5

Octopus Octopus Deploy 2.5.10

Serena Software Serena Deployment Automation 5.1.3

XebiaLabs XL Deploy 4.5

Zend Zend Server 7.0

https://github.com/zend-patterns




Figure 4 Creating Release Package Features


Attunity Maestro and RepliWeb

Automic One Automation

BMC Release Lifecycle Management Suite

CA Release Automation

Electric Cloud ElectricFlow Deploy

HP Continuous Delivery Automation

IBM UrbanCode Deploy

Inedo BuildMaster

MidVision RapidDeploy

Octopus Deploy

Serena Deployment Automation

XL Deploy

Zend Server

Single, logical release created

from m

ultiple builds

Releases versioned

Software bill of materials versioned

Environment tem

plates versioned

Infrastructure environment

template versioned

Configurations versioned

Rollback supported

Drift tracked

• • • • • • • •• • • • •• • • • • • • •• • • • •• • • • • • •• • • • • • •• •• • • • • • • •• • • •• • • • • • • •• • • • • • • •• • • • • •

• ••

•

• Capability as part of the tool • •Partial capability Capability provided by another tool

•




Figure 5 Moving Release Package Features








Inedo BuildMaster


Octopus Deploy


XL Deploy

Zend Server

Atlassian Bamboo

Continua CI

Hudson

Jenkins

JetBrains TeamCity

Microsoft TFS

•

•

••••••••••••

Support for continuous integration tools5-1

••

••

•

•••

••••

••

•••

••

••


••••

••••

••

•





Figure 5 Moving Release Package Features (Cont.)








Inedo BuildMaster


Octopus Deploy


XL Deploy

Zend Server

Supported OS targets5-2

AIXIBM

i

IBM z

Linux

Mac OS

Solaris

Windows

•••••

••

••••••

•••••

••

••

•

••

•••

•

••

•

••

•

•

•

•

••

•

•


••

••

•

••

•

•

•

•

••

•

•

••

•

••

•

•

•







Supported cloud environment targets5-3







Inedo BuildMaster


Octopus Deploy


XL Deploy

Zend Server

Amazon W

eb Services

CenturyLink Cloud (Savvis)

IBM SoftLayer

Google Cloud Platform

Microsoft Azure

OpenStack

Rackspace Cloud

RedHat Open Shift

VMware vSphere

•••••••••••••

•

••

•

••

•

•

•

•

•

•

••

•

••

••

•

••

•

••

••••

•

•

•

••

••

•


IBM Bluem

ix

•

•

•

•

•

•• Capability as part of the tool • •Partial capability Capability provided by another tool

•• •

•












Inedo BuildMaster


Octopus Deploy


XL Deploy

Zend Server

Managing movement of release packages features5-4

Mix of autom

atic and

manual steps

Email notification

GUI notifications

GUI for deployment plans

Create environment from

a copy

Automatically decom

mission

an environment

•••••••••••

••

•••••

•••••

••

•••••••

•

••

••

•

••

•


•••

••

•

•

••

•

•

•••

••

•

•

••

•


•

•

R e c o m m e n d at i o n s

ChOOse a VeNDOR ThaT MaKes MODeRN seRViCe DeLiVeRy ReaL

Based on our analysis of the market, I&O professionals can use the following filters to identify the right ARA vendors for consideration:

■ Does the tool support the right target systems and cloud providers? Consider not only what is supported today but what you need to be supported in the future. Also, consider flexibility and the importance of deploying in different cloud environments.




■ How much governance do you want over your release package? If you are starting out, you may only be modeling the application itself, but eventually, you may want to consider modeling the other parts of the release package to get greater governance and understanding of what is changing with each new version.

■ Does the tool support the ecosystem of tools you use for modern service delivery? We have highlighted CI tools, but other tool integrations to consider are service management and automation, source versioning configuration management, project management, and issue tracking. At a minimum, look for support in your CI tool so that you can increase flow between life-cycle phases.

■ Does the tool add needed automation to your release process? At the end of the day, your ARA tool should fundamentally change your ability to automatically and reliably release into different environments. Choose a tool with the best overall out-of-the-box functionality to meet your needs.

sUPPLeMeNTaL MaTeRiaL

Companies interviewed For This Report

Attunity

Automic Software

BMC Software

CA Technologies

Electric Cloud

HP

IBM

Inedo

Octopus

Serena Software

XebiaLabs

Zend Technologies

eNDNOTes1 For more information about how the digital age has changed your market, see the March 19, 2014, “Unleash

Your Digital Business” report.

2 For more information about the new release cadence of modern service delivery, see the December 3, 2014, “What Makes Modern Service Delivery Modern?” report.

3 For more information about the modular design of packages, see the October 2, 2014, “The Seven Habits Of Highly Effective DevOps” report.









4 For more information on how containers might affect the future of deployment, see the October 21, 2014, “Brief: Why Docker Is All The Rage” report.

5 An “environment” in the context of services and applications usually refers to the collection of infrastructure, middleware, databases, and various supporting services that are needed to ensure the proper behavior of the service or application being released. Like all other aspects, environments must be properly modeled for best results.

6 For more information about tools and technology needed for the modern service delivery life cycle, please see the December 3, 2014, “Gear Up For Modern Service Delivery” report.

7 Community websites for third-party plug-ins are listed if they are available.



Forrester Research (Nasdaq: FORR) is a global research and advisory firm serving professionals in 13 key roles across three distinct client segments. Our clients face progressively complex business and technology decisions every day. To help them understand, strategize, and act upon opportunities brought by change, Forrester provides proprietary research, consumer and business data, custom consulting, events and online communities, and peer-to-peer executive programs. We guide leaders in business technology, marketing and strategy, and the technology industry through independent fact-based insight, ensuring their business success today and tomorrow. 119004

«

Forrester Focuses On Infrastructure & Operations Professionals You are responsible for identifying — and justifying — which technologies

and process changes will help you transform and industrialize your

company’s infrastructure and create a more productive, resilient, and

effective IT organization. Forrester’s subject-matter expertise and

deep understanding of your role will help you create forward-thinking

strategies; weigh opportunity against risk; justify decisions; and optimize

your individual, team, and corporate performance.

Ian OlIver, client persona representing Infrastructure & Operations Professionals

About Forrestera global research and advisory firm, Forrester inspires leaders,

informs better decisions, and helps the world’s top companies turn

the complexity of change into business advantage. our research-

based insight and objective advice enable It professionals to

lead more successfully within It and extend their impact beyond

the traditional It organization. tailored to your individual role, our

resources allow you to focus on important business issues —

margin, speed, growth — first, technology second.

foR moRe infoRmation

To find out how Forrester Research can help you be successful every day, please contact the office nearest you, or visit us at www.forrester.com. For a complete list of worldwide locations, visit www.forrester.com/about.

client suppoRt

For information on hard-copy or electronic reprints, please contact Client Support at +1 866.367.7378, +1 617.613.5730, or [email protected]. We offer quantity discounts and special pricing for academic and nonprofit institutions.

www.forrester.com

mailto:[email protected]

Documents

Market Overview: Application Release Automation Toolsdocs.media.bitpipe.com/io_12x/io_125060/item... · Hp, IBm, Inedo, octopus, serena software, Xebialabs, and Zend technologies