Application Release Automation integrated with IT Engines such as Chef, Puppet and Ansible

Companies shopping for Application Release Automation solutions often confuse the functionality of IT Engines such as Ansible, Chef and Puppet as potential tools to address the ARA challenge. IT Automation engines are designed to automate the management of servers, containers, network devices, and cloud based datacenters. They control configuration details and deploy RPMs (Redhat Package Management files). Developers who use IT Engines for application deployment most commonly do so by first creating an RPM for their application and then passing that RPM to the IT Engine. RPMs were designed for performing Linux installations; however over the years RPMs are now more universally accepted. The problem however is an RPM is OS dependent. An RPM written for Linux must be updated for other operating systems such as AIX. In addition, RPMs must be scripted for each application, hiding critical information about the Application Stack packaging and component relationships with configuration details and deployment logic. RPMs were designed as a delivery mechanism, not an end-all solution to application release management.

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 without relying on the use of RPMs. ARA solutions provide an easy interface for package creation with the ability to track component versions to application versions along with the deploy logic at the component level. And unlike using an RPM, the packaging and associated logic can be installed to any Operating System across the continuous delivery pipeline. 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, tracking components to endpoints (physical, virtual, cloud, containers), supporting roll forward and rollback, database updates and historical reporting.

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, Continuous Integration and Continuous Delivery. This allows an overall DevOps approach that uses RPMs for vendor updates, an IT engine for managing the infrastructure configuration, and ARA to coordinate the Application Stack, all managed as a combined package across the Continuous Delivery Pipeline driven by Continuous Integration.

To simplify this coordination, OpenMake Software’s Release Engineer and Ansible are integrated to create a combined package. The process can be initiated by Continuous Integration calling Release Engineer to create the combined package, working with Ansible for a completely integrated solution from development through production release. Ansible is leveraged to manage RPMs, environment updates, cloud provisioning and other IT Automation tasks. Release Engineer pulls together the Application stack, database updates and the infrastructure layer as a complete combined 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

Application Release Automation with Ansible
Combining Ansible and Release Engineer Packages

Release Automation and Puppet or Chef

Release Engineer for ARA also supports both Chef and Puppet 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 layer steps. Once a Chef or Puppet Component is defined to Release Engineer, Release Engineer 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. Release Engineer 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.

Application Release Automation and Chef or Puppet

Leave a Reply

Your email address will not be published. Required fields are marked *