Guest Post: Deployment Automation with CDA

A guest post by Sebastian Schramm

“When software is rolled out on a Friday or on the weekend, we’ll come to work on Monday after lunch — as we’re sure nothing will work until then!”

Someone said this to me in 2015 and since then, this phrase has been a steady companion in my daily automation work, especially in the area of software development and deployment.

Many companies want to automate their IT, but they fail to define exactly what automation means to them.

Automation of IT operations is highly complex, ranging from automated hardware deployment and software distribution, to classic software development — made agile by software such as Broadcom’s CDA (Continuous Delivery Automation, formerly ARA).

In this post, I will explain what a software rollout is and why you need automation for it.

Definition: What is a Software Rollout?

Let’s start with a boring definition.

A software rollout is a business process that uses coordination and a structured process to distribute new software across many clients.

But there’s more to a software rollout: tuning software dependencies, user training, and testing. These aspects are often forgotten in deployment automation.

Experience shows that rollouts often lack structure and coordination. When I asked him where the schedule was deposited, a user replied: “It is in our heads. Only we know what to do, you can not automate that “.

I beg to differ. Thanks to CDA, this process can be automated. You only have to answer four small questions.

The Basics: Automation with 4 Small Questions

The 4 questions are simply Who?, What?, How? und Where?.

Of course, you don’t have to maintain the answers to these questions in Excel spreadsheets — you’ve got CDA for that. There are so-called entities that contain exactly these elements of a rollout. With CDA you can bundle all information centrally in one technology.

Through CDA, your employees gain access to a graphical interface for modeling their implicit knowledge. Don’t worry though, this will not make employees superfluous: their job is now to standardize and model corporate processes.

With CDA, you can create a graphical model for all processes and make them transparent for everyone. This improves both efficiency and auditability in your company.

Now, let’s get back to the questions:

1. Who carries out the rollout?
   This question is easily answered. The operation is executed by any user — someone from IT operations or your central release coordinator. The actual software deployment is performed in CDA by technical user accounts that are stored in the login objects. This allows you to decentralize responsibilities by granting permissions.
2. What is going to be rolled out?
   That’s your software, of course. It does not matter if you use a code repository or have a central repository. The software consists of several software components (e.g. configuration files, software artifacts or operating manuals) whose release-relevant information is stored in the package. However, the package does not serve as a storage location for software artifacts (we may look more closely at code and artifact management with CDA in another article), but merely as an information store. Filing will continue at a location of your choice.
3. How does the rollout work?
   This is the heart of the CDA system and this is where workflows come into play. Workflows are the technical illustration of your structured process of deploying software. The structure and content of the “how” is discussed in the last two sections of this article.
4. Where does the rollout take place?
   The core element of this dimension is the deployment profile, which is actually an environment definition. It consists of the environment, the associated servers (deployment targets), and the login object with the login information for the technical user. By connecting the above information, you also get a configuration management, as it allows you to check who rolled out which software when and where. Typically, companies use external configuration management tools, but this is not mandatory. If you do, the information for a software rollout must be painstakingly compiled and passed on to your automation tool prior to execution — resulting in additional costs.

The Alpha and Omega of Automation: The Workflow

You might be thinking now: “But aren’t there some more object types missing?”. Don’t worry, in the last paragraph we’ll talk about all the missing objects.

Let’s get to the workflow first.

An application is created to contain all software-relevant information – software titles, specific configurations, and the description of the software components. Like all other entities, it is an empty data container that only comes to life once you enrich it with your knowledge.

Like your software (which consists of several components such as a server application, a database, and a client), an application can be combined with multiple components. The basic rule is: Each component always belongs to only one application. Each application must and can be described individually. Since in many companies the applications all have small differences, the control at this point is very realistic.

Now, of course, there’s the legitimate question: “What does all of this have to do with the workflow?” The answer is: “Everything!”

All object types described above are part of the workflow structure. The workflow is divided into three levels:

• Application Workflow (consisting of 1 to n Component Workflows)
• Component Workflow (consisting of 1 to n Action Workflows)
• Action Workflow

Like in Hollywood: “…and Action”

The last puzzle piece, when creating a deployment automation are actions (called runbooks in previous versions). Actions are small, self-contained functions designed for exactly one task. For example, looking at typical operations on a file system, actions such as “Copy File”, “Copy Directory”, “Delete Directory” or “Run Bash Script” can be defined as single actions.

With the actions, you can map your automation of the deployment down to the smallest detail, since you can use standard actions from the Marketplace or create them yourself. You have complete freedom — you are the ruler of your own automation!

Enough Theory: Let’s Look at a Use-Case

It’s time to illustrate this kind of workflow with an example, don’t you think?

We look at the flow of a file system update during the software rollout.

Let’s say you want to roll out your process “SportsWearShop,” an online sportswear store. This means that you create an application data container. Then you define a component with the type “Server” (an online shop typically is a web application).

Below the application, create a workflow and, in editing mode, add an instance of the component.

Open this instance and add your actions step by step.

In our example, the actions look like this: First delete old data archives, then archive current data, create the desired new data structure, transfer new files to the file system and finally delete excess or temporary directories.

Of course, you could do this without CDA, relying on decades of scripts and the experience of your employees. But CDA shows you the automation, supports employees, and at the same time offers lots of flexibility. Believe me, you will notice this during troubleshooting, when the integrated color control shows you at a glance where your automation crashes. No hours of reading script necessary. No guesswork. And no key person risk. You can always change your automation in the background, introduce new technologies, or restructure the staff — the tool lets you react to any change.

Outlook

This blog post was some kind of appetizer for the possibilities, automation with CDA provides. I have some more ideas to turn this article into a small series: Introducing Special Action Packs, Continuous Integration and Continuous Delivery Pipelines, Mapping Processes in Your Business and a lot more.

Are you interested in this topic? Then write me a comment or an e-mail.

And always remember that there are no limits to automation with CDA — or as the Automic slogan says: let’s automate your business!

Sebastian Schramm

Trainer for Automic Products

Sebastian Schramm is a developer, consultant, and trainer for Automic products. He supports you at strengthening your automation – not only with Automic products, but also many other processes and technologies. His passion and focus is DevOps automation.

ChefCoach IT GmbH

We are a team of IT experts and support you with our specialized knowledge in your IT projects. Since we distribute neither hardware nor software, we can advise you manufacturer-independent. We use our experience to implement the best possible concept for your project. You benefit from the many years of experience of our competent team of experts.