First there was code, then there were build tools, next came deployment automation and now enterprises are trying to make all of it easier, faster, more reliable and repeatable on a much larger scale. At every stage of that process users face the same issue - how to manage changes. If you have one person making changes then it is not a big deal. The problem arises when hundreds or thousands more come into play. Then how does one manage many changes to the same system at the same time? Source control management (SCM) systems provide the answer for the application code and by now Git has gotten pretty good at managing the mess.
At the build stage, the trend has been to move the complexity to the scripting language (look at Maven and how complicated of a system it has become) in order to reduce the intricacy in the build tool. Luckily, that means that all one has to do is commit the build scripts with their code and let the SCM deal with it.
But how about the deployment stage? For a long time, one approach was deployment scripts. This solution, however, came with some drawbacks: the scripts grew in size and complexity and exposed sensitive data of the environments to anybody with read access. Then people started using their automation tools with various plugins to do the deployments and reduce the complexity (or at least make it more readable) and hide the secrets away. Nowadays more and more deployments need to be automated and an increasing number of changes with management requirements are being introduced. None of these could be scripted and handled by SCM systems. That is why users started demanding that their automation tools should support a model where the configuration can be defined and managed in text files so that they can move them to the SCM system. What came out of that is not necessarily code (and no, YAML, JSON, XML and the likes do not count as code) but it was better. Most of it is not very flexible either so it might need to be wrapped in some scripting to get it to work but it can all be stored as text and managed that way.
We, at Broadcom, did exactly this. Our first approach was to expose REST APIs that took JSON as input so that, with some scripting help, our users could move most of the configuration to the SCM. Nevertheless, this procedure still required additional scripting to handle secure variables and configuration that varied across applications and deployments. It all ended up being almost as complex as the deployments themselves.
Then we decided to provide our users with a way to actually code the configuration for our Continuous Delivery Automation tool and get all the additional benefits that come from it. This is how the Continuous Delivery as Code (CDC) was born. All you need is the CD Code Java based library to start managing your application deployment configurations via your favorite IDE or CI tool.
Using the CDC library you can create Groovy based scripts that can be versioned and stored in a SCM tool of your choice. The Groovy based syntax, we introduced to describe the CDA objects, resembles a configuration, which makes it easy to read, write and adjust. You can also organize/define these scripts as standardized templates (by exposing the variable parts of the configuration) to be used to onboard new applications as a service or by the development teams. CD as Code is an alternative to the standard CDA Graphical User Interface. It shows the whole deployment configuration with all its inner dependencies at a glance, thus making it easier to comprehend.
Our goal was to make CD Code easy to adopt for novice users while preserving the flexibility and freedom to code any custom logic in the scripts for the advanced developers. We wanted to provide an authentic as-code experience and also reduce the complexity of using and processing multiple API calls to come to the desired deployment configuration.
CD Code covers the full CDA domain model and also exposes helper classes to ease on-boarding and use. The AutomationEngineHelper enables the export of predefined component workflows which can be easily modified from the script. The ApplicationExporter is another helper class that allows you to export your existing applications to as Code, so that they can be used as templates to quickly introduce new ones or to speed-up the deployments of the existing applications across different environments.
Some of the features planned in the CDC road-map include auto-completion support for all the strings referenced in the script and more in-depth coverage for the CDA domain model. CDC is compatible with CDA 12.3 and all upcoming versions. Watch the following video to get started!
Getting Started with Continuous Delivery Code
By @Jenya Stoeva, @Varban Vasilev