I am often asked, “if we are using a continuous integration server and adopting a continuous delivery pipeline, why do I need application release automation (ARA)?” Good question. In a nutshell, continuous delivery (CD) is a process, and ARA is part of the CD tool chain. It is best to think of CD as a maturity extension to continuous integration while ARA does the heavy lifting of continuous deployments.
To understand CD or ARA, one must go back to their roots, continuous integration. Continuous integration (CI) is a key component of agile practice. Agile developers understand the importance of adopting a methodology that can manage smaller incremental software changes in order to deliver software, and therefore business value, to end users quicker and cheaper. The activities of deploying to testing and production have historically been in the hands of testing and data center teams, separate from development. But in agile practice, these activities cannot be separated from development. The concept of separate development, testing, and production teams is a waterfall concept, not an agile concept. In agile, everyone is on the same team. This means that testing and production teams must become part of the agile process.
Because practice makes perfect, the CI processes implemented by development should be consumed and re-executed by testing and production teams. Repeatability across the life cycle is the goal of continuous delivery. Maturing from continuous integration to continuous delivery directly impacts the testing and data center teams. Continuous delivery is the process of defining a CI workflow that can adapt and support the lifecycle through a ‘pipeline’ where CI workflows can be shared across teams, making testing and production part of the agile process.
In theory this works well, but the practical application presents some basic challenges. First there are cultural differences to address. Frequent deployments equate to ‘bad’ code not agile code in the minds of data center teams. The goal is stability – not incremental releases. Secondly, the deployment scripts written by developers and pushed up the pipeline do not meet the very real needs of both testing and production. The number of endpoints, the ability to rollback, auditing, server configuration updates, router updates, firewall issues and other requirements drives the data center team to modify the deployment scripts, or re-write the scripts to meet their own process. When developers write a deploy process, they do what is needed for development and sometimes test – but it breaks at production. The data center team is not as large as the development teams making it difficult for the data center to keep up with the agile pace. A sustainability issue becomes real. Production cannot keep up with the new pace at which agile is delivering changes.
Application release automation is designed to support a model-driven software deployment process that allows development, test and production teams to use the same process without the need for one-off deploy scripts, while adding all the features and functions needed to support continuous delivery and data center deployment requirements. ARA is designed to fully perform the heavy lifting of software delivery including deployment packaging, versioning, database updates, server configuration management, calendaring, roll-forward, rollback, security access and auditing. The ARA solution is called by a templated CI Workflow that is defined by the development team. The workflow is moved up the pipeline and adapts to the changes at the various pipeline stages (system test, integration test, pre-production, production, etc.) Because the process is driven by the ARA tool and not a script, the changes are automatically addressed across the pipeline, reducing the workload for all teams and supporting frequent changes that can be easily traced and audited down to the server inventory level.
ARA is a process that strengthens the foundation of the continuous delivery pipeline and is core to the DevOps initiative. It facilitates agile practices by allowing the testing teams and data center teams the tools needed to become more agile and accept the frequency of changes being pushed across the pipeline by development. ARA can be implemented just by the data center, but the danger becomes gaining adoption by the development groups in their CI/CD process. Again, the goal is repeatability across the pipeline, pulling together Dev and Ops. More on that topic in a future article.
Summary:
Continuous Delivery Vs. Application Release Automation
I am often asked, “if we are using a continuous integration server and adopting a continuous delivery pipeline, why do I need application release automation (ARA)?” Good question. In a nutshell, continuous delivery (CD) is a process, and ARA is part of the CD tool chain. It is best to think of CD as a maturity extension to continuous integration while ARA does the heavy lifting of continuous deployments.
