Tools for automation
With so many tools serving the continuous delivery market, what job each tool does may be unclear. This article explores the roles of IT Automation, Application Release Automation and Test Automation for building out a stronger and broader continuous delivery pipeline.
Continuous Delivery is the process of pushing new code up the application life cycle as frequently as possible. The goal is to define a CD process that is so automated that no one on the team is required to interact with the process, except for passing an approval gate, unless that too can be automated. In order to achieve that level of automation, all aspects of a software deployment and test initiation must be defined and added starting at IT Automation and ending with Test Automation.
The importance of incorporating the management of the IT stack as part of the continuous delivery workflow is often overlooked. One must remember that the goal of continuous delivery is to push code changes up the life cycle, which ultimately means a continuous deployment process that performs the release. A critical piece of that release is managing the platform to which that release will reside. IT Automation engines such as Ansible, Chef and Puppet all offer open source solutions with professional upgrades designed to automate cloud provisioning, manage network devices, manage server configurations, and deliver middleware using vendor RPMs. As they say ‘no man is an island’ so goes software. Every software application has critical dependencies on the IT stack, so building a CD process that does not incorporate the management of the IT configuration is like building a house with no foundation. It is doable but living with a dirt floor might not be the best solution in the long run.
Second on the heap is the application stack. Managing the application stack is core to continuous deployment, and therefore critical to continuous delivery. Application stack management consists of defining software components, the logic of installing those software components, and assigning them to an application, which also requires specific logic (stopping and starting Tomcat for example). Often times developers create scripts, including RPMs, to ‘automate’ the process of deploying the application stack. A new breed of tool called Application Release Automation is now available to replace the need for one-off ‘deployment’ scripts. ARA adds important features to the application delivery process. A core feature is environment modeling, which is the ability for the deployment to adapt to the dev, test and prod environments. In other words, define the IT and Application configuration once and use it dynamically across the lifecycle. Other features include component to ‘end point’ tracking, rollback and roll forward capabilities, environment modeling, the ability to integrate configuration of the IT stack, calendaring, approvals, and change request tracking. When ARA solutions are used in conjunction with IT Automation, a complete package of the application configuration can be managed together offering the highest level of continuous deployment functionality.
High cost of commercial offerings
Like IT Automation solutions there are both commercially offered ARA solutions such as IBM UDeploy and CA Release Automation and open source solutions such as DeployHub. The initial problem with implementing ARA solutions into your Continuous Delivery workflow is the high cost associated with the commercial offerings. Defining your workflow with lower cost or open source solutions is a good place to start. What is important is to move away from scripted processes and create deployment logic that can easily model across the different environments of the life cycle driven by the continuous delivery pipeline. Your continuous delivery pipeline is not automated when manual steps are required to tweak and ‘baby sit’ the underlying deployment scripts. ARA solves this problem.
Once you have a solid method of achieving continuous deployment, and your application and IT stack is managed, it is time to look at building out your continuous test. There are many levels of continuous testing from smoke test to full functional test. The continuous testing market has been increasing with both open source and commercial solutions that cover all aspects of testing. Your CD workflow should include at minimum a ‘smoke’ test once your deployment has completed successfully. Open source solutions such as Selenium can be called to validate that your new installation indeed runs. Other commercial solutions, such as CA TDM, can be called to perform more extensive testing that mimic large database connections and transaction verifications.
Further automation is required
While your Continuous Delivery pipeline and your Continuous Integration engine do a great job of orchestrating processes, further automation is required to mature continuous delivery to support testing and production teams. Incorporating IT Automation, Release Automation and Test Automation into continuous delivery reduces complexities, improves the process, provides more visibility and begins the transformation of testing and data centers into ‘lean’ teams that can become a part of the agile conversation.
Latest posts by Tracy Ragan (see all)
- Continuous Deployment – The Final Step of Continuous Delivery - April 18, 2017
- Defining the Continuous Delivery Tool Chain - March 16, 2017
- Continuous Delivery – Challenges for the Data Centre - February 15, 2017