Continuous Delivery Vs. Application Release Automation

Continuous Delivery and Application Release Automation

Understand the difference between application release automation and continuous delivery

Application Release Automation is a set of tools while Continuous Delivery (CD) is a process. Continuous Delivery is an extension of  Continuous Integration. When a software update is saved to the version repository, the Continuous Integration workflow is triggered to execute steps that may include the calling of a script to compile code into binaries (Continuous Build), followed by a script to deliver the binaries to a list of servers (Continuous Deploy). In some cases where the production environment is made up of only a small set of servers, the Continuous Integration process may support production deployments, but in most organizations CI is used mainly by development and testing teams. When someone states they are doing Continuous Delivery, they are saying that they use their CI process to execute a deployment script as part of there over all CD strategy.

Application Release Automation (ARA) is designed to fully orchestrate the delivery of software including infrastructure and database updates, server configuration management, calendaring, roll-forward, rollback, security access and component packaging. A Continuous Delivery process may call an ARA solution to perform the orchestration of the deployment, replacing the one-off deployment scripts written by developers.

 

Server Configuration Management

It is true.  A script called by a CI process can set server parameters.  But the script is not the place to store or manage this type of information.  ARA solutions centralize the management of server settings and configurations and can do so for thousands of machines.  This centralization provides a quick, self-service portal for anyone, from development through production, to view, analyze and update configurations if needed, without executing a script.

When this low level configuration data is managed inside a script, only the author of the script will know where in the script the configuration settings are located, and exactly how and if the script is  actually setting them.  Scripts can easily obfuscate a configuration setting. What you thought was being done by the script was actually commented out in the script, or the script failed to loop through all endpoints as the server list was not updated.  Transparency is the biggest issue with the scripts making releases difficult to understand.

The challenge is not how the scripts were called (via a CI process), the challenge is that the scripts are called.   Scripting is a poor solution for managing Server configuration.

Learn more – download the whitepaper 

 

Leave a Reply

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