New Dependency Management in XL Deploy: How It Works

| September 8, 2015 | 0 Comments

Dependency Management in XL Deploy: How Does It Actually Work?

This week we released XL Deploy 5.1, which introduces powerful new dependency management capabilities (announcement here). Before it deploys an app, XL Deploy 5.1 now checks to ensure all dependencies are met. If the required applications or deployment packages are not already deployed, XL Deploy deploys them. And if they’re missing entirely, it notifies you and refuses to start the deployment.

Why?

Managing dependencies is painful and error-prone. Moving to Microservices, SOA and cloud architectures amplifies these challenges beyond what manual processes can effectively manage. With XL Deploy, you don’t need to develop one supreme model that understands every component’s dependency on everything. You only need to understand each app’s local dependencies and configure them in XL Deploy.

How It Works

When you create a package in XL Deploy, you can specify what version of what other applications that packages depends on. For example, let’s say you have a user interface for a banking application called banking-app-ui. Version 3.0 adds some functionality that is supported by a new version of the backend, which is at version 4.0. So you would define a dependency that banking-app-ui v3.0 requires banking-app-backend v4.0 and up.

Note: XL Deploy uses industry standard OSGi semantic versioning to define these dependencies. In this case that would be [4.0,).

Defining a dependency causes a number of things to happen in XL Deploy:

When you try to deploy banking-app-ui 3.0, it checks whether banking-app-backend 4.0 or up has been deployed to the same environment.

  1. If it is, no problem.
  2. Otherwise, XL Deploy looks in its repository to find the latest version of banking-app-backend and includes that in the deployment.
  3. If there is no suitable version of banking-app-backend in the XL Deploy repository, XL Deploy does not allow you to deploy banking-app-ui and tells you exactly which version (range) is missing.

 

After you have successfully deployed banking-app-ui, if you later try to undeploy banking-app-backend, XL Deploy does not allow you to do so, as it would break your banking application. You first need to undeploy banking-app-bankend.

XL Deploy applies dependencies transitively; that is, it applies the same rules to dependencies of dependencies. If you initiate a deployment of banking-app-ui 3.0, the following occurs:

  1. XLD checks dependencies and sees that banking-app-ui 3.0 depends on banking-app-backend [4.0,).
  2. XLD looks for the latest version of banking-app-backend in the [4.0,) range. That might be banking-app-backend 4.5.
  3. Then it sees that banking-app-backend 4.5 in turn depends on banking-app-dbschema [1.0,).
  4. So XLD looks for the latest version of banking-app-dbschema in the [1.0) range. Let’s assume that is just version 1.0.
  5. So in order to deploy banking-app-ui 3.0, XLD will first automatically deploy banking-app-dbschema 1.0 and banking-app-backend 4.5 (in that order)… and then it will deploy banking-app-ui 3.0.

 

To learn more about XL Deploy and dependency management, watch this handy 2 min video, or visit the following pages:

 


Lisa K. Wells

About the Author ()

Lisa K. Wells is the Vice President of Product Marketing at XebiaLabs. Leveraging more than 25 years of experience in software, Lisa is laser-focused on creating value in the software development pipeline, crafting go-to-market plans, honing company messaging, and spearheading general cat-herding activities. After starting her career as an Applications Engineer, she moved to the "Dark Side" – product marketing – where she developed a passion for helping companies effectively build, market, and sell technology that provides life-changing value to customers. Over the last 12 years, Lisa has been at the forefront of building winning product strategies and messaging for some of the world’s leading software tooling companies, working with SmartBear and CloudBees before joining XebiaLabs in 2015.