Four Reasons You Need Preview Environments
There has been a rapid increase in the adoption of Preview Environments across organizations. From open-source projects to enterprise organizations, everyone seems to agree on their usefulness in helping ship applications faster. If you're not familiar with Preview Environments, they basically deploy the changes present in a Pull Request (PR) or Merge Request and provide a shareable link to access them!
Preview Environments provide an excellent way to not only validate that everything is working as expected but also allow everyone in the team to be a part of the feedback process. In this article, I’m going to give you four reasons which make them a must-have if you're looking to boost productivity across your team!
Feedback is one of the most crucial aspects of the software delivery process. Great feedback can come from anyone and not just engineers. But conventionally, the feedback process has always been limited to the software engineers on the team because it involved being able to read code. Even for technical team members, the feedback process hasn’t always been convenient. If you want to see how changes actually look and try things out, you would have to pull the code and build it, which is a time taking process.
Preview Environments solve both these problems by deploying the changes in a pull request and giving you a link that you can visit to view these deployed changes. This link is shareable, which means you can send it to anyone across your organization - product, marketing, sales, and even customers if need be! Not only does this allow a much wider set of people to be a part of the review process, but it also makes reviewing easier for everyone. Nobody needs to build the code or wait for a staging environment to try the new features or verify that that nasty bug blocking your users has indeed been fixed!
I think you will agree with me when I say that the early we're able to give feedback, the better. Often feedback from non-technical teams in software companies comes too late in the delivery cycle. It is often just before the release (or sometimes even after 💀) when you're testing things in a staging environment that you would show it to product, marketing, sales, and other teams. But the problem with this is that the feedback you get at this point is much harder to act on than if it were given right when chunks of code were being merged. Preview Environments solve this problem by allowing everyone to review things early on. They provide an excellent way to cut short iteration time by allowing early feedback.
Preview Environments follow the lifecycle of a pull request. They allow you to show the changes in a pull request or merge request before it gets merged. This way, you're able to get feedback for each pushed commit and make the required changes. This is so much easier than getting feedback in staging environments right before the release. Without Preview Environments, feedback early on is only possible from people who can read code, and others are left out of this very important process.
If multiple people have been pushing commits to the same branch, Preview Environments provide you a way to see the complete change together deployed live and be sure that things are as expected when you make a PR. But it’s not only this; even if you’re working on a branch alone, Preview Environments have become essential because of how complex our applications have grown.
Before a team has Preview Environments, it is very hard to know if the code works as expected or not. Sure, you can look at the code and review it syntactically, but when you start the application, maybe it doesn’t start. Maybe the helm chart you have for your application uses a variable different from the one you used in your code. Preview Environments do an excellent job of highlighting errors like these which are very hard to catch otherwise. When you have multiple services, and there is information flowing through a bunch of different things like databases, secrets, and whatnot, then validating that the changes in a PR still work with the rest of the application becomes a very tough job. Preview Environments help you provide this certainty that things work by deploying your changes and letting you see them!
Preview Environments help you expand the kind of tests you run on your Pull Requests or Merge Requests. Before Preview Environments, you would have to rely only on CI/CD to run tests. While having a robust CI/CD is necessary, it still doesn’t solve all your problems. Typically CI/CD is mainly focused on unit and integration tests. What gets left out of the picture are end-to-end (E2E) tests.
End-to-end tests require your entire application to be brought up. This is something that the CI/CD systems are not good at achieving. Preview Environments, on the other hand, shine in this area! They bring up the application with your changes just like it would be deployed in production. This allows you to run all sorts of E2E tests. Preview Environments also allow you to run testing frameworks like Cypress and Selenium, which require the application to be brought up. If you’re working with APIs, the URL that Preview Environments provide can also be used to test them end-to-end using tools like Postman. The cloud-native applications we code today have multiple services and different scenarios that CI/CD doesn’t really have the capability of catching. Preview Environments, therefore, become a must-have for being able to ship bug-free applications!
To sum up, Preview Environments are a great way to easily get validation and feedback from everyone across your organization in a timely manner! As our applications continue to grow more complex, it becomes essential to rely on them for faster iterations if you’re looking to ship code timely.So what are you waiting for? Sign up for Okteto for free and get started with launching Preview Environments for your repositories. You can find a detailed step-by-step guide to walk you through the process in our docs or check out our video tutorial to get started!