Unleash

Strategy constraint operators: new and improved

How do I schedule a feature release?” is a question we’ve gotten more times than we’d like to admit over the past few years. It used to be that the answer was a long and complicated sequence of steps. You’d have to customize both the Unleash server and every SDK instance you were using. With the slew of new strategy constraint operators we’re releasing in Unleash Pro and Unleash Enterprise 4.9, the answer is simple: you use a strategy constraint.

As an open-source product, Unleash has always been about flexibility: we want you to be able to have it your way; we want you to run it wherever you want; we want you to build and expand upon it in a way that suits you and your use cases. Flexibility is awesome, but it often comes at the cost of convenience. Sometimes, though, you can have both:

We’re unleashing a host of new strategy constraint operators (13, to be exact!) to make it easier to achieve common goals such as scheduling feature rollouts and releasing features to user IDs matching specific patterns (think email addresses!). In line with Unleash’s focus on flexibility: these operators don’t give you anything you couldn’t achieve before, but they make hard things easy. Let’s look at some concrete examples!

Then and now: scheduling a feature release

Let’s say you have a new feature, Feature A, that you want to release to all your customers at exactly 08:00 on Monday morning.

Without the new constraint operators you would have to:

  1. define a custom activation strategy that uses the custom context field you defined
  2. implement the custom activation strategy in all the client SDKs where you needed it, making sure that they all implement the same logic

That’s a lot more hassle than it really has to be. With the new strategy constraint operators, all you have to do is:

  1. add a strategy constraint, saying the currentTime context field should be after 08:00 on Monday morning
The constraint editor. It lists a context field: `currentTime`; an operator: `DATE_AFTER`; and a date: November 25th 2022, 12:00 AM

That’s it! And what’s even better is that if you want to release the feature for a limited time only — say between 08:00 on Monday and 16:00 on Friday  — you can just add another strategy constraint saying that currentTime should be before Friday at 16:00.

Two strategy constraints. The first says `currentTime` is `DATE_AFTER` november 25th 12:00 AM, the second says `currentTime` `DATE_BEFORE` November 26th 12:00 AM

Then and now: rolling out a feature to your company

Another thing we’ve seen a lot of requests for is rolling a feature out to users belonging to a specific domain. This is often based on email addresses. Before this new release, if you wanted to release a feature to all users whose user IDs end in either @mycompany.com or @yourco.com, the easiest way would be:

  1. define a custom context field that you can populate with the domain of a user’s email address (the @something part)
  2. add a strategy constraint saying that your new field should have a value that’s IN @mycompany.com, @yourco.com
  3. manually populate the field on the client

Again: that’s a lot of hassle. With the new strategy constraint operators, you would:

  1. Add a strategy constraint that says userId should end with one of @mycompany.com and @yourco.com
A strategy constraint specifying that `userId` must end with either `@mycompany.com` or `@yourco.com`

How about that, huh?

Strategy constraint operator types

The new strategy constraint operators can be split into four distinct categories based on what they do:

  • Numeric operators: mathematical equalities and inequalities
  • Date and time operators: whether it’s before or after a specific point in time
  • String operators: check whether a string starts with, ends with, or contains other strings
  • Version (SemVer) operators: equality and inequalities for version numbers following the SemVer spec

Visit the freshly updated strategy constraints reference documentation for more information about each group and each operator.

The currentTime context field

If you’ve used Unleash for a while, you might notice that the currentTime context field we refer to above is new too. Going forward, the Unleash Context will have a dynamic property called currentTime. As the name implies, this property’s value defaults to the current time, whenever it is evaluated. As with all dynamic properties, you can override it with your own value if you so choose.

A word of warning …

To implement this new functionality, we’ve had to extend the protocol a little, so it’s very important that you update your client SDKs (especially if you’re using the Ruby, .NET, or PHP client SDKs). If you use the new strategy constraints with an old client SDK, we cannot guarantee what will happen and it’s quite possible that you’ll see different results between different clients. For more information, check out the incompatibilites section of the strategy constraints documentation.

But wait, there’s more!

The examples above only show off some of the new functionality; there’s also a brand new look for strategy constraints and more options for fine-tuning them, such as adjusting case sensitivity in string operators and the ability to negate constraint expressions. So if you want to expose a feature to all your users except for users with an @mycompany.com email address, that’s just another box to check.

There’s so much good stuff packed into this update, so make sure you update your Unleash instance and SDKs to take advantage of these new features!

Want to get started?

GET STARTED TRY OUR DEMO

Share this article