By Lisa Wells

One of the most popular features of XL Deploy is its model-based approach, which focuses on the components you want to deploy. Most other deployment automation tools use a workflow-based approach, which focuses on defining the steps you need to execute in order to deploy the components.

xl deploy

In XL Deploy, you describe the object you want to deploy, be it web content, files, or a web application. You separately describe the environment. Once you model the components, you only need to specify what you want to deploy and where, at the highest level. XL Deploy calculates the mapping of your components, the ordering (orchestration) and any additional steps for you (for example, restarts), based on industry best practices. If you make a change to a component or environment, that change automatically propagates to everything in the plan. Scaling therefore happens automatically. Add a new target, and XL Deploy then generates the plan accordingly, now with the additional steps included. Unlike workflow-based tools, in XL Deploy you don’t need to search (within your deployment logic) where to account for this new target and duplicate the logic to deploy to it.

Why Workflow-based Deployments Don’t Work

One of XebiaLabs’ customers evaluated a workflow-based deployment automation tool from a large enterprise vendor before they implemented XL Deploy. “However, even heavy discounts didn’t outweigh some significant deficiencies,” said their CTO. He went on to describe the issues:

Workflow approach is inadequate

The workflow approach [vs. XL Deploy’s model-based approach] is powerful, but it doesn’t quite do what we want. It looks good on the surface but doesn’t go far enough. So you either need to extend the components – which is complicated – or write a script anyway… which rather negates the purpose of the tool.

Difficult to change and a maintenance nightmare

You get wrapped up in the workflow if you try to change it, add a new step, etc. – a regular maintenance nightmare! The more you try to use the available workflow structure, the less it seems to be of any value.

Insufficient support for microservices architectures

The tool we looked at does some sort of microservices dependency management but the process is horrific. Every time you add a new node to an existing microservice, there’s a lot to do.

Too complex

Not only was the workflow definition too complex, but also the deployment of the software. It gets very complicated when you look at how many agents can be implemented at one time.

Prohibitive licensing

The vendor of this particular tool wanted to license us to death! Because of the license server, it took a week to deploy and get things working. It’s an awful lot of irritating hassle.

Over-engineered and not modern enough

XL Deploy has a more modern roadmap and is following where modern application development is going. The workflow-based tool we looked at is over-engineered so much, I’m not sure how the company can move forward on it.


Most deployment automation tools are agent-based, and we do not like deploying agents to our 200 nodes! There’s no good way to deploy to that many hosts with agents. It’s a helluva memory suck even if it’s only taking 20-30 MB each.


For a complex global enterprise environment, XL Deploy is the clear choice for managing automated deployments. Don’t take it from us, see how Rabobank, one of the worlds largest financial services institutions, cut their deployment times by 60% by implementing model-based deployments with XL Deploy: Case Study.

Why A Workflow Approach Doesn’t Cut It

About The Author

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>