IT Automation is not Release Automation
IT Automation and Release Automation can be confusing. Companies shopping for Application Release Automation solutions often confuse the functionality of IT Automation Engines, such as Chef, Puppet, and Ansible, as potential tools to solve application release automation. IT Automation engines are designed to automate the management of servers, containers, network devices, and cloud-based data centers. They control configuration details and deploy RPMs (Redhat Package Management files). Developers who use IT Automation Engines for application deployment most commonly do so by first creating an RPM for their application and then passing that RPM to the IT Automation Engine.
RPMs lack Application Packaging
RPMs were designed for performing installations onto Linux platforms. They do this well. However RPMs hide critical information about the application stack in their code. Component relationships with configuration details and deployment logic is obfuscated and hard to read by someone other than the author. RPMs were designed as a delivery mechanism for IT Automation, not an end-all solution to application release automation.
A Better Way
Organizations looking at Application Release Automation (ARA) solutions are seeking a more flexible and transparent way to manage the packaging and deployment of the Application Stack. In addition, they want to do so without relying on the use of RPMs. ARA solutions provide a graphical and easy interface for package creation. These tools give you the ability to track component versions to application versions along with the deploy logic down to the component level. In essence, ARA automates and controls what would otherwise be scripted and hidden in a RPM and then extends the automation and control to the final delivery step. Hence, ARA performs the tracking of components to endpoints (physical, virtual, cloud, containers), supporting roll forward and rollback, database updates and historical reporting.
IT Automation as Components
The good news is that you can include IT Automation as part of your ARA application package. In fact, DeployHub integrates with Ansible and uses Ansible Galaxy Roles as Components. Both IT Automation and ARA have their place in the delivery process and work better integrated as a complete solution. Using ARA for infrastructure management is doable, just as using IT Automation for application deployments is doable. You can always use a kitchen knife in place of a screwdriver when you are in a pinch. But when faced with assembling a shelving unit, most people invest in a screwdriver, or better yet a screw-gun. The point being – choose the right tools for the job.
Benefits of Application Release Automation over RPM
When it comes to packaged software (Oracle, WebSphere, Tomcat, etc.) most developers would prefer to use the RPM from the vendor and use an IT Engine to perform the deployment. The job of installing the new software is done without much effort. It follows the old KISS rule (Keep It Simple Stupid).
If moving the software from point A to B is all that is needed, our problem would be solved. However, there are other functions such as reporting and tracking the update, database management, incremental rollback, jumping versions, calendaring and inventory reporting that is required by larger, more complex organizations. These functions are critical to automating Continuous Delivery. So while using an IT Automation engine to deploy an RPM might work for development, it lacks the sophistication for a fully automated and traceable Continuous Delivery pipeline. This is where ARA steps in.
Using the Best of Breed for Release Automation
Using the right tools for the job requires integrating ARA with IT Automation and Continuous Deliver. This allows an overall DevOps approach that uses RPMs for vendor updates, IT automation for managing the infrastructure configuration, and ARA to coordinate the Application Stack, all managed as a combined package across the Continuous Delivery Pipeline.
To simplify this coordination, DeployHub and Ansible are integrated to create a combined package. The process can be initiated by a CI Workflow calling DeployHub to create the combined package. Ansible is leveraged to manage RPMs, environment updates, cloud provisioning, and other IT Automation tasks. DeployHub defines the application package, delivers the combined package, tracks the Component Versions, audits the process, tracks endpoints to Component Versions, supports rolling forward/rollback, version jumping, calendaring, security and delivers historical reports. The process can be initiated by a Continuous Integration trigger and pushed Combining Ansible and DeployHub Packages.
Release Automation and Puppet or Chef
DeployHub also supports both Chef and Puppet IT Automation solutions to assist with creating the ‘Combined Package.’ Chef and Puppet can easily be called as part of the Component Item Workflow to perform these infrastructure steps. Once a Chef or Puppet Component is defined to DeployHub, it passes control to Chef or Puppet to perform the work. This means that you could define your Application to include a Chef Component to install or update Tomcat prior to the deployment of an EAR file. DeployHub will Version the Chef Component, call on Chef to perform the delivery of the Component, track the Chef Component to the Server, and send the logs back to the Jenkins CI server that initiated the work.