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:
- define a custom activation strategy that uses the custom context field you defined
- 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:
- add a strategy constraint, saying the
currentTime
context field should be after 08:00 on Monday morning
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.
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:
- define a custom context field that you can populate with the domain of a user’s email address (the @something part)
- add a strategy constraint saying that your new field should have a value that’s
IN
@mycompany.com, @yourco.com
- manually populate the field on the client
Again: that’s a lot of hassle. With the new strategy constraint operators, you would:
- Add a strategy constraint that says
userId
should end with one of@mycompany.com
and@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 |