What is a Staging Environment? (And Why Do We Need One?)

As part of a new series, we asked our engineering team what they wish clients knew about their jobs. William Mena is a Ruby on Rails engineer with Planet Argon for two years. He's worked on everything from new application builds to upgrades from Ruby 1.9!

William says: “I wish clients knew how vital a staging environment is to a developer.”

So let's dive into:

• What a staging environment is.
• How developers use staging environments to make quick changes.
• What goes into the cost of a staging environment.

What is a Staging Environment?

A staging environment is a like-real copy of the live application for your business. It looks the same, acts the same, and has like-real data to test against. Not all industries can provide their actual customer data. For example, the healthcare industry restricts what kinds of data developers can use to protect patient information. So, for testing, we create fake data that looks real. This way, we have clean, isolated data to use for validation, separate from the live site.

A staging environment replicates the live user experience as much as possible. The data looks real; the site responds as if it is live, but everything is separate from the live site. It's a good place to create errors that don’t affect the users.

From a server resource perspective, this means creating a second set of the app and database.

Why is a Staging Environment Important?

Let’s look at a simplified version of the development lifecycle:

1. A change or new feature is requested.
2. Development begins in the local environment (on the developer's machine).
3. When it looks right, the developer sends the work to Staging, which will look like the real site.
4. The change is reviewed from a look-and-feel perspective and a code-quality perspective.
5. It looks good! It can go out to the live site.

The staging environment plays a vital role in this process. It's how the developer and the rest of the team review changes. It's a place to iterate and adjust how the change appears in a like-real environment.

But, as the stakeholder, the staging environment is for you, too! It is a great place to test site behavior and try acting as a user who does not know the site well. The staging environment is an extra level of quality assurance. For this reason, it's critical for everyone.

Here is a more specific example:

As an admin user, I want to see a report of all our users. For this, I need to see data about all license types. This will be a quick place to review new license sign-ups (last 30 days) and upcoming expirations (next 30 days). The management team will analyze this report weekly.

So the request is:

1. Create a new report page for admin users
2. Display all license types in rows
3. Display metrics in columns
4. Ensure that calculations run against current licenses based on criteria.

A developer has 5-10 licenses with fake user data in the local environment. They can use this to test small changes without saving a massive amount of data on their machine. After creating the structure, they can use this local data to see how it behaves. Let's say it goes well! The report is populated with data, and everything looks correct. So, they send the change to the staging environment.

However, the staging environment has a lot more data. The developer notices that, with more data, the new report takes a long time to load and slows down the rest of the site. This could mean users will see slow loading times, even though they are not admins! But because we are on staging, no one can see this error.

The developer will take the change back and make some adjustments to the performance. Then, they will try again.

Real users might have seen the slowdown if the developer had gone straight to the live environment. A staging environment is a great place to catch these ripple-down effects before they go live. It’s an extreme example, but I’ve seen it happen!

How to keep the cost of a staging environment low

It can be expensive to run two full versions of an application simultaneously. A lot of data manipulation or a lot of user interactions often means a high server cost. So, if possible, you don't want to double that! Here are some things to try:

• Turn off data replication. For the live environment, it is important to keep frequent database backups. But for staging, it is not.
• Auto-scaling can be expensive. Keeping up with user throughput and database queries is essential for a live site. But for staging, it’s less likely to be impactful to testing users.
• Some APIs charge per call to their service. Look at what you need for testing, reduce other services, or use a sandbox environment.
• Use staging for large or impactful changes, then turn it off. A small development team with minor modifications to code means you may not need to test as often. Turn the resources off, then spin them back up when needed.

Conclusion

A staging environment goes a long way in helping the entire team feel confident in the changes they make. It allows an iterative and streamlined approach. Reviews are easier. Problems are more clear. And the quality of changes made increases. It's a win-win.

If cost is a concern, keep an eye on your server bill. It is healthy to discuss server costs with the team about once a year. The developers can help keep service costs low and highlight what is critical or not. Keep them in the loop!

If you need a staging environment or advice on reducing your server costs, contact us!