Managing Advanced Release Orchestration With XL Release
Continuous Delivery and microservices both come with challenges: how do you roll out releases more frequently, while managing complex dependencies among different components and ensuring that your applications’ quality stays high?
Join the DZone community and get the full member experience.Join For Free
the continuous delivery approach to developing software is gaining popularity, and with good reason; frequent, focused releases can speed up your time-to-market and improve productivity, efficiency, and customer satisfaction. in addition, many enterprises are looking to microservice architectures as a way to structure and manage small units of code that need to be released more and more often.
but continuous delivery and microservices both come with challenges: how do you roll out releases more frequently, while managing complex dependencies among different components and ensuring that your applications’ quality stays high?
xl release addresses these challenges by allowing you to manage interconnected release pipelines across your organization, both individually and as a whole. xl release can alert you to potential problems before they happen and make it easier to see when a delay in one release will impact others. here are some of the ways xl release helps you manage complex release scenarios.
use a master release to manage subreleases
a common way to structure releases for maximum control and visibility is to set up a “master” release pipeline that starts other releases and serves as a central point to monitor and manage those releases while they’re running.
for example, these two phases are part of a master release that will start nine release processes for related microservices and components:
in xl release, the master release depends on these “subreleases”, meaning that it will wait for them to complete before it continues. this structure ensures that the overall release process will only be complete when all components and services have been released successfully.
you can see how the subreleases fit into the overall release timeline on the master release’s dashboard:
kickstart a set of releases
but you aren’t limited to the master release/subrelease model. xl release is flexible, so you can set up your pipelines to reflect real-world release processes and update them as they change and improve.
for example, you might want to create a single release that serves to “kickstart” other releases, but doesn’t monitor their status or depend on their completion. this lets you centralize the way you start a set of releases; you only have to trigger the kickstart release either automatically or manually, and it will take care of the rest.
chain releases sequentially
or maybe you’d rather build a “chain” of releases that run in sequence, so that just before each release completes, it starts the next one in the chain. this structure allows you to enforce the order in which the releases execute and ensure that each release in the series doesn’t start until its prerequisite releases complete successfully.
model development sprints and other business processes
you can even use xl release to model and orchestrate recurring processes such as development sprints and releases with marketing tasks. xl release collects data about the process—such as the time spent on each task and how the task workload is allocated—which can help you identify bottlenecks and spot potential areas for automation.
Published at DZone with permission of Necco Ceresani, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.