Simplify rollout management with the new environments feature
Rollout management can be hard to get right. Managing the rollout of new features across different environments is even harder. When you have multiple environments, each with their own rollout strategies, things get messy quickly. Luckily, Unleash has a new feature to help make this easier for you! This post covers the new environments feature in Unleash. We will look at what it is, at what it means for you, and at how to use it.
If you are looking for a more in-depth and technical explanation, head to the Environments section of the documentation. You will also find a video introduction to the feature there.
What are environments?
An environment is a system that code runs on, such as a development machine or a production server. In most cases, you will have at least a (local) development environment and a production environment. Additionally, it is also common to have more environments, such as testing, staging, and QA.
Unleash’s new environments feature aims to make it easier to roll out features across your environments.
The feature is available behind a flag in Unleash 4.2 and generally available in 4.3. If you are using a hosted version of Unleash and want to get access to this feature early, let us know and we will activate it for you.
Motivation
Previously, if you wanted to use a different rollout strategy per environment, the recommended way was to use strategy constraints. The new environments feature makes this much easier and comes with some additional benefits to boot!
First off: strategy constraints are only available to Pro and Enterprise customers. Environments, on the other hand, are available to all Unleash customers: open source, pro, and enterprise.
You can configure each environment independently, so it’s easier to understand what strategies apply in which environment and how they interact.
Using scoped API tokens (one for each environment) makes it easier to manage features across environments. They make it less likely that you’ll accidentally activate a feature for the wrong user segment.
Because environments are fully separated, you can now get usage metrics for each environment separately, giving you even better insight into how your features are being rolled out and what your users are seeing.
And this is just the first version of this feature! We’re also working on an improved role-based access control. This means that you can control which Unleash users get access to configure which environments! Need to lock down control of production features to only a subset of users? That’s on its way.
‘How does this impact me as an existing user?’
If you already have an instance of Unleash set up (hosted or managed), you will get an environment called ‘default’. This environment will continue to behave exactly how you’re used to. Your existing feature activation strategies will get ported over and your existing API keys will continue to work.
In other words: nothing changes until you decide to make the change yourself.
Open source and Pro customers get access to two pre-configured environments: ‘development’ and ‘production’. If you have an existing instance, you will also get the ‘default’ environment mentioned above. Enterprise customers get the same environments by default, but can create, update, and remove environments as they see fit. All plans can enable or disable environments for individual projects.
How to use them
Each project has its own set of active environments. For each individual feature in a project, you choose which of the project’s environments it should be active in. That means that you only define your project (and its features) once for all your environments; Unleash takes care of the rest.
Let’s look at how that all works and what steps you need to take.
Activate the desired environments
Navigate to your project overview in the Unleash admin UI. In the nav bar, you should see a tab called ‘environments’ (the URL will be <unleash-instance>/projects/<project-name>/environments).
Enable the environments that you want enabled. You must always have at least one active environment.
Use these environment flags to enable or disable environments.
Make an API token for the right environment
Each environment needs its own, unique API token. To make a new token, navigate to the API token dashboard and press the button that says ‘Create API token’. Configure it as you normally would, but remember to put which environment the token should be valid for. This token will only work for the environment you chose when you made it.
Create a new API token for your chosen environment.
Add the strategies you want
Next up is adding the strategies you want for a feature. The feature list will show you which environments the feature is active in: A disabled flag means the feature will not be active in that environment. An enabled flag tells you that the feature will trigger based on which strategies you set up.
Enable or disable environments for each feature.
When you have enabled the environments, you can add strategies to them. The UI will list them on the feature overview page.
Get an instant overview over all environments and their strategies.
And that’s it! At any time, you can enable or disable environments for a feature or for the whole project.
To sum up
Unleash’s environments give you the power to configure individual rollout strategies for each of your deployment environments in a simple and straightforward manner. The addition of separate API tokens per environment also gives you more granular control over where environment configurations are accessed from.
As this is a new feature, we are eager to hear what you think about this and to see what you will do with it!
Want to get started?
| GET STARTED | TRY OUR DEMO |
