Why Preview Environments Are The New Thing in DevOps
Consider the scenario where a complex product is being developed by dozens of engineers working on different features of a product. Not only the development environment is the same, but the staging environment is also shared. As different features are merged into the shared environment, they break the code. So QA has to wait until this is fixed. A feature or bug fix may be working perfectly on the developer’s own machine, but there is no way for the QA team to test that one feature in isolation. This problem is intensified when the product has a lot of integrations and different data sources. The DevOps team simply cannot provision so many different environments on time; they will miss the bus. If developers keep using the same shared staging environment, it will take ages to deliver a mature product to the market.
This is where the concept of preview environments comes into play. In this article, we will tell you what preview environments are and how they solve the above problems. We will also discuss why so many DevOps teams are adopting it to improve team productivity.
Morgan PerryJuly 26, 2022 · 5 min read
CRO and co-founder of Qovery. Morgan is a Tech entrepreneur with 7+ years of experience in the SaaS industry.See all articles
What is a Preview Environment?
A preview environment gives you the ability to “preview” the code changes present in a pull request BEFORE you merge it to master, hence the name “preview environment”. It is also coined as an “ephemeral” environment because it is not a permanent environment. It's created temporarily i.e., when a feature is ready to be tested. Then the environment is removed as soon as the feature testing is complete. It is a breakthrough for DevOps because it is provisioned automatically after the one-time setup.
A preview environment is as good as other deployment environments e.g., Production, Staging, etc., because it is equipped with everything needed for proper testing in isolation. That includes infrastructure, updated products, integrations, databases, configuration, etc. A preview environment is better than the traditional deployment environments because it is super easy to provision and de-provision a preview environment.
You can think of a preview environment as a feature-specific version of the staging or production environment, which enables developers, QA engineers, or even product managers to test that feature without worrying about other features being tested. The ability to see the changes in “live” mode before merging to master is a game changer.
Preview environments are ideal when you have an urgent fix for a product defect or you have to deploy multiple improvements to an existing feature. On the other hand, a large feature segregated into smaller chunks probably does not need the preview environment as much.
Now that we know what a preview environment is, let’s discuss how they work.
How Do Preview Environments Work?
A developer is writing code to add a feature in its respective branch. Currently, the code is being committed to the local branch. The name of the branch will be similar to” Feature-MyStore-34” in the case of a feature and “Hotfix-MyStore-598” in the case of a hotfix. As the name of the preview environment is based on the name of the branch, so proper naming of the branch will help you distinguish different preview environments from each other.
Now the magic begins, as soon as the developer pushes the code from the local repo to the remote repo. A preview environment is instantly provisioned, containing everything needed for the smooth testing of that feature. The newly created preview environment will be accessible through a unique URL. Every subsequent push to that branch will be deployed to that preview environment. As soon as the PR for that feature is generated, the QA team can access the URL of the preview environment and will start testing that feature in isolation.
After the testing is completed, PR will be merged into the master. As soon as the PR is merged into master and the feature branch is deleted (We do not want any dangling branches), the preview environment will be removed.
After discussing how a preview environment actually works, let’s see why engineering teams are adopting it rapidly and how it benefits your product development.
Benefits of Preview Environments
Increased Ownership and Autonomy
Preview environments allow simplified collaboration on the code review. When QA, product managers, and engineers participate in the review process, the sense of ownership is increased. It also results in Cross-functional team members’ autonomy when their feedback is incorporated into the code review process without waiting for DevOps to set up and spin up proper environments.
Shorter Feedback Cycle and Faster Delivery
Preview environments help you run faster feedback cycles, reducing your time to market the product. For a product already in production, the ability to release hotfixes without overriding the staging build is a lifesaver. You can release the next version of your product much quicker now.
Note that you can incorporate the changes before the merge happens and in the same pull request. That means you do not have to wait for a merge to see the changes. This drastically improves the release cycles.
Improve Review Process and Product Quality
Preview environments provide excellent collaboration between manual testers, automation testers, developers, and other stakeholders. This improves the overall review process. As your releases now contain all properly tested and verified features, this results in better product quality.
Preview environments run in isolation, which allows the product team to try innovative ideas and experiments without worrying about the impact on other development work.
As the preview environments are ephemeral in nature, they are removed as soon as the PR is merged back into the master branch. This eliminates the need for permanent infrastructure, hence resulting in reduced cost.
The automatic provisioning and de-provisioning of a full-fledged deployment environment reduce much time spent manually setting up the environments. Note that all the preview environments are not the same. The difference in configuration, security, infrastructure, database, etc. makes a real difference whether you provision the environment manually or automatically. Apart from time spent, your bill for the DevOps team drops as well, because the DevOps team spends less effort.
As you can see from above, preview environments greatly benefit engineering teams. At the same time, it adds a burden to the DevOps team because setting up and maintaining preview environments is complex and requires time and resources.
Below, we will describe how Qovery’s preview environments provide the best of both worlds. It provides all the great benefits of preview environments but simultaneously makes the life of the DevOps team easier.
Qovery’s Preview Environments
Preview environments provide compelling features, but unlocking that potential is not easy for the DevOps team. The job of implementing and maintaining the preview environments is tedious. What if you could directly integrate your preview environment with your AWS account and configure it in a few clicks without going into any complexities? Well, this is exactly what Qovery’s preview environments do. Let’s try Qovery’s preview environments by following this step-by-step guide or watch the video below.
Deploy On-demand Environments on AWS, Remarkably Fast
Deploy your Production, Staging, and Development Environments on AWS in a few seconds. Managed databases, AWS VPC Peering, Preview Environments... Qovery got you covered!Try it out now!