Continuous Delivery Vs. Continuous Deployment

I am often asked, “if we are using a Continuous Integration Server and adopting a Continuous Delivery pipeline, why do a I need Application Release Automation (ARA), and where does continuous deployment fit?”

Good question.  In a nutshell, Continuous Delivery (CD) is a process, and ARA is part of the CD tool chain. ARA performs the actions that allows you to deploy software fast and safe.   It is best to think of Continuous Delivery as a maturity extension to Continuous Integration while ARA does the heavy lifting of continuous deployments.

To understand both Continuous Delivery and Continuous Deployment, 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 the 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 life cycle 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.

Model Driven Deployments

Application Release Automation is designed to support a model driven continuous deployment process that allows Development, Test and Production Teams to use the same release process without the need for one-off deploy scripts, while adding all of the features and functions needed to support Continuous Delivery and Data Center deployment requirements.  Application Release Automation (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.

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 or application deployments.  Application Release Automation solves this problem.

Learn More

IT Automation Vs. Application Release Automation

https://www.deployhub.com/openmake-softwar…uting-foundation/ ‎