How to Achieve Stable Continuous Delivery with StackState and XL Release

| July 31, 2018 | 0 Comments

DevOps

Martin van Vliet is the Vice President of Engineering at StackState. He has over 20 years of experience in building and leading software development teams and was previously a VP of Engineering at XebiaLabs.

With the need for speed that comes with modern application development, DevOps teams everywhere are implementing Continuous Delivery. Teams and businesses benefit from the frequent, automated release cycles that safely release new software as soon as it is ready.

Keeping your services running smoothly under this barrage of changes, however, is a challenge.

StackState, our market-leading next-gen monitoring and AIOps solution keeps continuous tabs on your entire IT landscape and helps to keep everything running. StackState now ships with an out-of-the-box integration with XL Release, a leading release management product from our sister company XebiaLabs.

Validating Deployments

Stop me if you’ve heard it before. Your code works fine on your laptop and in the Development environment, but there is an unexpected crash when you integrate it with the latest components your colleagues have been working on.

Where did you go wrong?

While you wrote your unit tests and even some integration tests that exercise your change with the work done in your team, there’s actually nothing you can do about this. With all the changes going on in the product you are working on, there are bound to be unexpected interactions between code changes in different components. Continuous Delivery handles these occurrences by applying the “fail fast” mantra. As soon as an issue is uncovered, the CD pipeline is aborted so that the error can be fixed.

How do you discover that your changes caused the entire application to fail in some non-obvious way? Well, by running the latest version of all components together, putting some load on the system, and watching a few key metrics (like response time, throughput, error rate) like a hawk. If no metrics spike or drop off, your change is starting to look better by the minute.

Now it’s just a matter of balancing your appetite for risk with how long you’re willing to wait to have your new functionality live.

Defining Application Health with Views

Deciding what makes an application healthy depends on the context. If you are monitoring your application endpoints, you might go with something as simple as error rate and response time. You could also use business metrics, like number of transactions per second. If you are responsible for technical components, metrics like storage usage or messages processed could be what you are looking for.

In truth, different teams have different requirements for monitoring application health. StackState allows each component in your application to have its own health state, indicating whether the component is working fine (CLEAR), has some issues (DEVIATING) or has failed (CRITICAL). The health state is calculated based on one or more metrics associated with the component.

StackState offers Views for teams to visualize their world. Each component in the View has its own health state which is calculated based on one or more metrics.

Here is a sample View with its own associated health state:

StackState

Related Reading: 11 Black Holes of DevOps – How Not to Get Lost in Outer Space

Using StackState in Your XL Release CD Pipeline

StackState’s integration with XL Release allows you to include application verification in your CD pipeline, making it possible to take action based on the health of your application.

The integration defines a Check View Health task that you can place anywhere in your XL Release template. This task requires access to StackState and queries the current health state of the specified View, making the health state available as an output variable:

StackState

If the health check is unsuccessful, you’ll want to take corrective action to restore sanity to your environment. This can be done using task preconditions and the XL Release integration with XL Deploy:

StackState

In the above example, XL Deploy will roll back the deployment in case of an error to restore the previous component version, then abort the release.

Blue/Green and Canary Release Strategies

The Check View Health task building block makes it easy to use either the Canary or Blue/Green release strategies.

Using the Canary strategy, you deploy your code change to a small subset of your infrastructure to test it. If the Canary environment stays healthy, you roll out the change to your entire infrastructure, otherwise you consider it a failure, roll back the deployment and abort the release.

This is what a Canary release might look like with StackState and XL Release:

StackState

With the Blue/Green strategy, your code change is deployed to a copy of your environment (call it BLUE) next to a stable, existing environment (GREEN). Traffic is routed to the new (BLUE) environment which is monitored for health. If there is a failure, traffic is switched back to the safe (GREEN) environment:StackState

Wrapping Up

Continuous Delivery can really put your teams to the test. Fast, short release cycles and continuous updates make it hard to keep track of your application landscape. DevOps teams need to understand how their applications are interrelated and how they are performing.

StackState delivers this insight, real-time, always up-to-date and without manual configuration. With the new XL Release integration, StackState combines XL Deploy data with information from other sources to create a digital map of your application landscape. As your applications are updated, StackState tracks XL Deploy deployments and, indeed, any changes over time to reduce the time it takes to diagnose and repair outages.

Do you want the confidence that each release performs, operates and delivers improved business outcomes? We are more than happy to show you how. Schedule a guided tour of StackState and get a better understanding of how we can help.

Editor’s note: This post originally appeared here. It has been slightly edited for formatting and clarity.

Learn More


Martin van Vliet

About the Author ()

Martin van Vliet is the Vice President of Engineering at StackState. He has over 20 years of experience in building and leading software development teams and was previously a VP of Engineering at XebiaLabs.