The art of rollback: Deployment objects

Episode 2: Defining object, component types and which rollback strategy to select

Pierre-Boris Bonafous
Pierre-Boris Bonafous, November 10, 2015 2:30 pm
Blog > Business Automation | DevOps > The art of rollback: Deployment objects

In ‘The Art of Rollback, Episode One’ we explored rollback in depth, by getting to the bottom of the ‘what is it’ question. You can recap, here. With Episode Two, in order to better understand the challenge of software delivery, I would like to introduce the objects involved, their respective properties and how they combine.

Object types

Objects in descending size order:
• Information system
• Release or enterprise release
• Application
• Component
• Job

Information system: Do you really want to deploy or rollback the entire information system? If yes, you need disaster recovery!

Release: A release, as defined by Automic Release automation, is the biggest object you can deploy in one click. A release is a group of applications that need to be deployed together for different reasons, usually because there are dependencies between them or because they share a common calendar or release window. Deploying a release means deploying all its applications packages, sequentially or ideally in parallel.

Application: An application is a group of components. It is a service or a tool that can be used on its own. That doesn't mean there can’t be integration with other tools and dependencies, but it does mean that if the integrations are not running, users can still use the application on its own (there are some exceptions to this definition of course). Deploying an application means deploying all of its components packages, sequentially or ideally in parallel.

Component: A component is the smallest piece of software you can deliver and track using version numbers. Deploying a component package means executing a deployment workflow made of jobs on targets machines.

Job: A job is a basic action, performed on a target machine. A job can have is own rollback definition within CA Automic Release Automation. For example, a job that copies a complete directory structure can have a rollback action that will delete the top folder in case of failure during the copy in order to leave a clean target.

Defining a rollback process for each object

You must define a rollback process for each object type, i.e. components, applications and releases and maybe even jobs when it makes sense. Another not so obvious consideration is that an application rollback is not necessarily the execution of each component rollback. It can be a completely different, perhaps faster process that can restore all application components together in the same action.

A basic example: let's assume my application is made of two components, a database and a website, and both components are hosted on the same VM. Restoring a VM snapshot or checkpoint of the VM will always be more efficient than executing the rollback process for the website followed by the rollback process for the database. It’s the same with a release. Rolling back a release is not necessary rolling back all of its applications, but it's often the case.

Component Types

Now let's take a look at the possible rollback strategies for each object, starting with components.

It's important to understand that there are different types of components, those for which a rollback causes a loss of data, and the others that do not. Keep in mind that you can create as many component types as you want in CA Automic Release Automation; the objective of this post is to identify the more common ones.

Living Components

“No man ever steps in the same river twice.” (Heraclitus)

Data is a living thing, and it's the real brainteaser when it comes to designing your rollback process. I recommend you create a component-type database when possible. Then a component-type rollback strategy will be at the heart of the application or release rollback strategy.

Static Components

Static components are boring, but you can reinstall them!

The other main component types fall in the following sub categories:

Application logic: This can be a web site, a service, or a core system. It can include middleware, or be a container…and so on.

Scripts: These can be any kind of scripted actions to be executed on a regular basis, like batches, ETL chains, jobs.

Configuration: This is any kind of parameterization applied during the deployment. Configuration usually changes between environments. The configuration can impact a set of configuration files and also databases, but in this case this must not be considered as living data in the sense that applying a parameterization is reproducible, whereas living data is random.

Again, it's possible to create as many types of components as you want. The classification discussed here is the minimum required.

Rollback initiating event

Once understood the logic behind the object structure we can establish 2 conclusions

1) The first object type that can fail to deploy is a component. Technically, the component fails to deploy when a critical job fails in the component deployment workflow. In that case the failed Job will raise the rollback event. CA Automic Release Automation allows you to define if a job can perform a rollback or not and what kind of scenario must be executed depending on the object scope.

2) The rollback event must be spread all over the dependent jobs and parent objects in reverse order. With CA Automic Release Automation you can configure the way the event will be broadcasted using the job post conditions. You can chose to send the rollback event to the first-parent object workflow, or to the top-most parent workflow.

These simple basic options give you enough flexibility to implement all the state the art rollback strategies known today.

Next episode: A list of state of the art the rollback strategies for your components, applications and releases. Stay tuned!

Key Requirements for Practical DevOps Using Application Release Automation

Business Automation
Back to the blog
Pierre-Boris Bonafous

Pierre-Boris Bonafous

Pierre is a DevOps and Automation Specialist at Automic. An expert in DevOps, Release management, Application Lifecycle Management and automated deployment, he has worked for the likes of Orange, BNPP, Renault, Schlumberger, Valeo and has more than 15 years’ industry experience.