When developing software, it's common to have multiple deployment environments. These can be used to harden features before rolling them out to customers in production.
Here's one popular pipeline of environments as an example.
When integrating an mtribes Space into your application, you may want to align this with your environments.
While native support for Space Environments are on our roadmap, they're not currently available. In the meantime, we have an alternative that we'll work through next.
Tribe per environment
Our recommended approach with support across SDKs, which decouples feature rollout from software release.
With this approach, you pass a new contextual user property when starting a user's session. This defines the environment the user is under.
When you run this for the first time, our platform will surface the new
environment contextual property under your Space. You can then set up Tribes
based on this property for each environment.
In this example, we'll set one up for the
With Tribes for each environment created, you can now target your Scenarios at specific environments.
This allows you to decide which environments an Experience is enabled in, and what property values it surfaces.
For accuracy, it's important to select the ALL option in Scenario targeting when including a specific environment Tribe.
Space per environment
A more complex approach that's not compatible with all SDKs and prone to inconsistencies.
You may be tempted to set up a Space per environment as an alternate approach.
This can work for our browser SDK but requires code generation for each Space. It can also force a rebuild of your app before being deployed to each environment, so it can target the correct integration code. Something to avoid where possible.
It also requires the manual synchronization of Space modeling, which is error prone and could impact production.
For these reasons, we recommend the Tribe targeting approach until we offer native environment support under a Space.