How to Manage Staging Environments to Speed Up Your Deployments By 5x
The staging environment plays a crucial role in product development. It's the last checkpoint before the product updates are live for customers. Every successful product has a robust and effective staging environment on the back. However, the traditional staging environments cannot keep pace with the modern CI/CD workflow. This article will go through how traditional shared and static staging environments hinder faster deployments and efficiency. We will conclude with how Qovery can help your development teams release faster and cut downtimes & bugs in production with on-demand environments.
Morgan PerrySeptember 14, 2022 · 6 min read
A staging environment is the last step in the deployment process before your changes are visible in the production environment. It is used to perform a final round of testing before stakeholders review it and approve it for production. Usually staging environment is one step ahead of the production because it contains features and bug fixes not yet deployed on production. The staging environment should be as similar as possible to the production environment, so it is usually a replica of the production. To ensure the data present in the production is the same as the staging environment, data is often synchronized from production to staging environment.
The User Acceptance Testing Environment (UAT) is also used for final testing and client approval. However, the UAT is tested directly by customer(s), unlike the staging environment, which is tested by the QA team.
With the agile methodology being the industry leader in software development methodology, the pace of development and deployment has increased by many folds. As a result, the traditional staging environments cannot keep pace with this agility. Here are some reasons why the existing staging environments are unsuitable for fast-paced agile product development.
Traditional staging environments present the first stage where a feature meets the infrastructure for the very first time. And it is not just one feature; all the features are deployed to the staging environment in one go. The inability to test each feature in isolation creates many problems. One feature might not work at all and might block testing other features. When you fix that feature and redeploy it to the staging environment, it might result in a regression bug or conflict with any other feature. This wastes valuable time.
Traditional staging environments have a permanent infrastructure. Once set up, you can modify the configuration and infrastructure, but that change will be permanent. Consider a scenario where you need a staging environment just for a demo for one day. The cost and time to set up the environment are too much that you would wish to have a staging environment that could be created on the fly with a temporary infrastructure.
Modern CI/CD requires rapid collaboration between members of the team. Whether it is the QA engineer waiting for a staging bug fix or it is the product owner waiting for code conflict to be resolved on staging, traditional staging environments carry a significant problem in terms of mutual collaboration. You cannot create your own version of the staging environment so that others can review and collaborate on your staging environment.
The problems mentioned above raised the need for dynamic staging environments so that different team members can create their own version of the staging environment for testing each individual feature in isolation before these features are deployed onto the staging environment. Let’s see how these on-demand environments speed up your deployments.
As the name implies, the on-demand environments are created on a need basis. Here are some of the core benefits of on-demand environments, which can speed up your deployments by 5x.
Imagine the case where you have a new feature developed in your development environment. You suspect it might create havoc if deployed directly on the shared staging environment. But that can be verified only after it is deployed in the staging environment. This is where on-demand environments come into play. You can create a brand new full-fledge on-demand staging environment, which will have nothing else deployed but your new feature. That gives immense power to developers because they can create on-demand environments on their own, and they can do that whenever they want.
On-demand environments promote the culture of rapid feedback incorporation into the product. Now that you can review each feature in isolation without worrying about breaking other features, you can create many on-demand environments simultaneously for testing and reviewing different features and bug fixes. Whether it is a performance tester who is testing on their on-demand environments or it is the UX designer giving feedback on a new UX design feature, on-demand environments result in super-fast cycles of feedback incorporation, which results in a much-refined product.
We mentioned earlier that on-demand environments could be created on the fly. Do you know they can be removed as easily? Yes, you can close down your on-demand environments as quickly as you can start them. It happens so often that we shut down every component of the cloud infrastructure to save cost, but we still get charged for something we forgot to close down. Not with the on-demand environments, in any case. As the process of on-demand environment creation is not manual, removing the environment needs just one click; you do not need to keep track of the services and components involved; all of them will be removed.
The Preview environments are temporary environments where you can preview your code changes in isolation. These are full fledge working environments that are used to test specific features and bug fixes in isolation.
Here is the workflow related to the Preview Environments:
- As soon you create a code PR, a new preview environment is automatically created
- The new environment can be a replica of staging, UAT, or even production
- The new environment is shared with other stakeholders through a unique URL.
- Based on the feedback of different stakeholders, you update the PR. The changes are updated in your preview environment.
- If your team creates 20 PR’s a day, you will see 20 unique environments, each carrying just one PR deployed on it
- As soon as your merge the PR into master, the preview environment is closed. All the infrastructure, configuration, etc. is completely wiped like it never existed
The Preview Environments enable you to deliver a product that has been refined with the valuable feedback of all the stakeholders. It removes all the bottlenecks associated with the traditional staging environments, which are static, and shared and do not allow you to test your features in isolation. A product that can take advantage of the powerful benefits of preview environments will always have a competitive edge over other products in the market.
In this article, we discussed how traditional staging environments are slowing down product development. As a result, modern solutions like Qovery have emerged to fill the gap. Qovery’s EaaS (Environment as service) provides a unique solution where you can take advantage of On-demand and Preview environments, making the best out of your product and reduce the time to market. Qovery’s on-demand environments increase your team velocity, speed your product delivery, cut downtimes and bugs in production, but also reduce your infrastructure costs. Last but not least, you get the dynamically created full-fledged environments on your own AWS account, which lets you keep control of your expenses.
To experience first-hand the power of Qovery's On-demand environments, start a 14-day free trial.
Sign–up here - no credit card required!