There’s a better way to deploy (part 5)

** Please note: The SDA Community Edition is no longer available.** 

Myth: Each deployment needs me

Helicopters have been described as “10,000 parts flying together in close formation. It is the mechanic’s job to keep that formation as tight as possible.”

Modern software applications comprise of millions of parts when you consider the huge chunks of code we bind into our applications from the database, security, web server, communications, encryption and authentication vendors. Add to that the seemingly infinite numbers of dependencies on external web services and internal CRM and financial systems.

There are 100 million lines of code in the Ford Taurus

But, just like the helicopter’s mechanic, the software and release engineers can’t be there all the time the system is on the air (or in the air).

It would be prohibitively expensive to have engineers chaperoning their application 24×7. Yet, whenever there is a deployment, no matter how routine, release engineers “want to be there just in case.”

This is laudable commitment to ensuring success but belies a worrisome truth. Is the release engineer who hangs around the release “just in case” more capable than the one who doesn’t hang around but gets on with the next release automation task?

Deployment Automation maintains an inventory of every artifact deployed

Automation means never having to say you’re sorry

Release engineers who build automated deployments know that they can incorporate all the necessary logic to deal with the expected (and unexpected) consequences of their deployments. They know they can leave the automation to execute quietly and efficiently without human intervention.

Automation engineers also know if that if something occurs that has not happened before they can a) handle that safely too and b) add further automation to deal with this new exception in a proper, predictable fashion each time it occurs in the future.

Serena’s Deployment Automation technology release engineers are freed up from constant script development and modification. Now release engineers can turn their attention to supporting the development teams and enabling their continuous improvement programs, their continuous integration process and their continuous delivery goals.

Instead of firefighting every failed script and every broken deployment, release engineers can use the Serena Deployment Automation logging capabilities to do full root cause analysis of problems that arise. Then they get to address the problem at its source by improving the coverage and completeness of the automation eliminating the possibility of future errors occurring.


In order to help you get started with your automation, Serena has made their latest version of Serena Deployment Automation available in a Community Edition format that lets you experience the most up-to-date deployment automation technology for free.

Avatar photo
Share this post:

Leave a Reply

Your email address will not be published. Required fields are marked *