Best Practices for Staging Environments

Let's talk about staging environments.

Staging is the last step before production. It simulates the production environment as closely as possible. Staging is crucial for bug detection, as it's the last line of defense against bugs. Staging can also be leveraged for other objectives: it can be a great way to demo new features, or even show to a customer what changes on your app could look like.

But as applications are getting complex and tech teams scale, staging environments can become somewhat difficult to manage.

In this article, we want to give you a few insights to help you manage your staging environments and to encourage you, when relevant, to set up on-demand environments. Sounds exciting?

Why is my staging environment difficult to maintain and use?

In the best scenario, the staging environment works perfectly, responsibilities are clearly defined and it allows engineers to test in conditions that are very close to production.

But in some cases, working with a single staging environment can be slightly more difficult. In particular, as scaling occurs, it becomes much harder to work on a single environment.

When your architecture becomes distributed, with dependencies and connections between services (micro ones or applications), spinning up a production-like environment on your laptop to test a new feature is not an option. Engineers have to stub and mock the other services in order to test quickly, but that's often too hard to put in place and very time consuming when the stack has some legacy.

The staging environment is often used to test the integration of new features in a production-like environment. If this feature breaks something, a new patch has to be shipped through the long CI process. During this time, no one can call this bugged service, no one can test the features he wants to ship to production, creating a development and deployment bottleneck for everyone.

Data is also a huge issue in this situation. Maintaining a good dataset in Staging, with the right information and set of edge-cases, is time-consuming and becomes harder and harder when the deployment rate gets higher.

All this results in inefficiencies and a lot of frustration. Release a single feature might take a long time, and the process might not sufficiently prevent bugs from happening in production.

So what should we do then?

Tips for managing staging environments

Avoiding difficulties with staging environments requires to act at different levels: technical of course, but also organisational or cultural.

Taking good care of staging environment

A first step is to facilitate the maintenance of your Staging. The good news is that it doesn't require complex or technical new processes! Most of it can be solved through improved communication and responsibilities.

• Make sure that you test efficiently your code before going into Staging. This will reduce the risk that the tests fail in Staging.
• Clearly define infrastructure ownership.
• Limit the access to each staging environment. For instance, implements slots per team, to make sure that only one team at a time uses the environment. This prevents people from accidentally screwing with each others' tests.
• Involve developers in the process of maintaining the environment: giving responsibilities to developers incentivizes them to take care of their playground.

Consider having multiple staging environments

With only one environment, each team has to block Staging for its own testing. This quickly becomes difficult to manage.

A solution is to create multiple staging environments, so that each team can use its own environment.

This seems like a great solution, but can lead to various issues:

• Time and energy to set up new environments might be very significant. Some manual coding has to be written for each new Staging, even with some levels of automation.
• Data sharing might still be a problem as it might be difficult to completely isolate environments from one another. This means that they might share the same data which can result in side-effects when it is modified.
• Cost! Just adding up environments will necessary lead to much higher cloud costs.

Create on-demand environments

Another solution is to create on-demand, disposable test environments that will be used to test every code change.

This way, it will become easier to test isolated features with confidence. This is definitely great for developers, and can also be powerful for product owners or even salespeople, who will be able to create personnalized demos for their leads!

This configuration should allow you to set up a new environment in only a few minutes. In terms of costs, rather than having 24/7 environments consuming cloud credits, the environments have a specific lifetime that limits the costs.

There are multiple ways to set up this kind of disposable test environments, but we advise you to go with the tool we built, Strio.

Strio creates on-demand test environments, based on technologies you already use, such as Kubernetes and Terraform. It asks for your dependencies and deploys them with the new version of your service to enable full integration testing. To rely on production-like data, our solution contains an anonymization function, so that you can comply easily with GDPR and other privacy regulations.

Ready to try Strio?