Why Release Automation?

Application deployment and maintenance is slow and expensive because of a cultural and process gap dividing the worlds of application development and IT operations. Once an application is functionally complete, it is "thrown over the wall" to IT operations, which takes custody of the app and becomes responsible for its deployment and maintenance.

Systems are constructed around the application based on a series of independent steps—layering on operating system, middleware and other tooling—to create a complete software stack that is ready to run. Because the resulting system is the sum of these uncoordinated steps, there is no consistent way to explicitly understand which components—and more specifically, the exact versions, dependencies and relationships between the components—are included. Systems become an unmanageable black box.

For most IT organizations, the process of deploying an application is manual, taking weeks or months and causing business lines to miss opportunities. Some IT organizations implement custom scripts to automate these processes. This may help to accelerate some of the manual steps, but it fails to address the fact that the process itself remains flawed: systems are inconsistently cobbled together without an adequate or ongoing understanding of the system definition, dependencies and version histories.

As a result, organizations experience escalating delays, costs and risks caused by:

Version inconsistency between lifecycle phases - manual assembly of systems often creates version inconsistencies between QA and production phases. Even subtle differences in system versions often cause QA—certified applications to break in production.

Inefficient maintenance processes - since dependencies aren't deeply understood, updates and patches often break running systems, adding to overhead costs and creating business and compliance risks. With no detailed understanding of which components are running where, "forklift" updates must be delivered en masse, creating a cascading series of conflicts and collisions to running systems.

Inability to roll back changes - when these collisions occur, the absence of version control capabilities makes it difficult or impossible to roll back changes to restore the running system.

Inability to reproduce systems - the ad hoc nature of system construction and the lack of a version history means that it is generally impossible to reproduce exact systems. This can lead to variation in computational results and compliance and audit risks.

Noncompliant systems - a manual approach to creating systems creates the risk of noncompliance with Sarbanes Oxley, PCIA, ITIL, cryptographic, licensing, and other IT and regulatory policies.

Learn how rPath can help with release automation