You know how this goes: it’s the eve of a major release, and your development team is clambering to address any last-minute feedback prior to deploying to production. The majority of the feedback is about small changes that are easy to fix — but some of it requires larger, more significant changes. These lengthy feedback loops point to a more fundamental problem: a breakdown in communication. This should have been addressed sooner. Now you're wondering if it's worth delaying the release to help ensure the build's stability.
Does this sound familiar? I saw this firsthand while working at a small SaaS startup. With only a day or two left in the sprint, the product team would provide feedback on the latest build on staging, resulting in a last-minute rush by the development team to implement those changes. To meet deadlines, shortcuts were taken, and hastily written workarounds were rarely refactored, adding to the backlog of technical debt just as the next sprint began.
Chances are that if you are experiencing these bottlenecks while developing your product, then it is highly likely that your team lacks the necessary tools. The product team ended up leaving feedback late because they didn't have a stable URL to check UI/UX until the changes were on our staging server.
We needed a way to get input from stakeholders earlier in the development cycle, before features were released to staging.
When testing software, a staging environment is a nearly accurate replica of a production environment. Before an application is deployed, staging environments are used for testing code, builds, and updates in a production-like environment for quality assurance.
Stakeholders in the past didn’t get to use the finished product until it was live. Rather, at the end of the sprint they received a short scripted demo. By allowing stakeholders to have unfettered access to your staging environment, they get to assist with quality assurance and this also ensures that the release lives up to their expectations.
Consider a staging environment to be the ultimate quality assurance test, where you can ensure that everything works in conditions that are as close to the production environment as possible. You’ll identify bugs, minimize possible downtime, and empower your developers to take risks.
There are four steps in the conventional deployment process to a single staging environment:
Rather than being restricted by all upcoming changes landing on a single server, you could have ephemeral staging environments that exist for the sole purpose of hosting the build of a given pull request. Giving each branch in your git repo its own staging environment is very liberating for both your developers and reviewers because it allows them to test features independently.
There are more advantages to having multiple on-demand staging environments than just testing features.
When you have one staging server, the gathering of product feedback is hampered by code review meaning that you won't get to deploy your code until the code review goes through.
On the other hand, product feedback and code review can happen before or at the same time as code review if your developers have access to ephemeral staging servers that spin up on demand. In the event that something needs to be addressed, a bug or a new feature, going back to the drawing board isn't too expensive because not much time has passed. You therefore avoid a stumbling block by combining product feedback and code review, rather than having one rely on the other.
You have just finished working on this new cool feature — but because a single staging server serves as the landing pad for your entire engineering team’s upcoming changes, a member of your development team can unwittingly push code to your organization's git repo that breaks what you wrote. Even if you have an internal link you can share with a non-technical stakeholder, there is no guarantee that the link will continue to work, because it is actively being integrated with!
While testing a release as a whole can be done in a single staging environment, features should be tested separately. This means that the purpose of an environment should be to test the functionality of a single feature rather than a collection of many features. After you've tested each feature individually, save testing the collection of all your features for your QA server.
When asked to review someone else's code, developers must switch between several contexts. The procedure is unnecessarily disruptive.
With on-demand staging environments, developers can jump right into the deployment preview without having to checkout files, install dependencies, restart their development servers, or make any other changes to their local environment.
The purpose of receiving feedback is to make more implementation changes that address the problems raised during the session. The issue is that this will necessitate a new code review! Even if the proposed changes are (hopefully) minor the second time around, your reviewers will have to go over the same lines of code for the same feature implementation.
On-demand staging environments can be configured to be available through a shared URL, opening up a world of testing and quality assurance possibilities.
Previously, stakeholders did not have access to the finished product until it went live. Instead, at the end of the sprint, they received a brief scripted demo.
Allowing stakeholders access to your staging environment allows them to assist with quality assurance and ensure that the development work completed meets their expectations. This saves time and prevents mistakes from being shipped inadvertently.
Developers can spin up as many staging environments as they need with on-demand staging environments instead of asking DevOps to configure new environments. Developers like this because it allows them to autonomously provision new servers, and DevOps like it because it eliminates the need for manual tasks such as provisioning and terminating servers.
A single staging environment can become a bottleneck if you have multiple development teams because teams have to wait for a staging environment to become available, as well as for the quality assurance procedures of other teams to be completed. This sometimes ends up wasting days of developer productivity and can encourage teams to skip straight to production, denying them all the advantages of a good staging environment.
In contrast, an on-demand staging server stays alive as long as the pull request is open. When the PR gets merged or closed, the server is automatically torn down.
Rather than having a single staging environment lying idle as it stands by for someone to make use of it, on-demand environments are provisioned automatically and dynamically.
This means that developer teams can gain access to staging servers whenever they require it just by opening a pull request. As you might expect, this increases productivity and encourages developers to use staging environments, which reduces the likelihood of costly production bugs. When a developer is finished with the staging environment, it is destroyed, along with any configuration, environment, or installation inconsistencies.
Having said that, you should still have a staging server where you can perform quality assurance testing before deploying to production. Before going live, you can perform a final spot-check to ensure that everything is working as planned. The difference is that this server's goal is to test the entire release rather than individual features. What's the relationship between the new features? If a bug is discovered, which pull request and which lines of code were responsible for the bug? When features are checked while the pull request is still open, these questions are much easier to answer.
Deployment automation is one of several capabilities that contribute to improved software delivery and organizational performance. Deployment automation allows you to deploy software to staging and production environments with the single click of a button. Automation is critical for lowering the risk of production deployments. It's also critical for providing quick feedback on the quality of your software by allowing teams to conduct comprehensive testing as soon as changes are made.
If your business constantly finds it hard to ship features that meet everyone’s acceptance threshold on time, then it could be indicative that you're lacking the right tooling.
The ability to autonomously create on-demand standalone staging environments (including databases) for an unlimited number of branches is very liberating for developers. The simplest way to set up on-demand staging environments is with Voyage. Voyage creates a deployment preview of your application every time you open a pull request.
Voyage can deploy multi-repo, multi-service, complex applications. Voyage is a self-hosted platform which means that you don’t have to migrate to a new cloud ecosystem or interfere with your existing infrastructure.
The built-in commenting and issue submission also makes it easy for reviewers to asynchronously leave feedback and share screenshots on multiple staging environments. It currently integrate with Github, Bitbucket, Slack, and Jira.
Here are the steps to do so:
All you have to do now is push up a PR and Voyage will deploy the app, and give you a url to view your app.
Head HERE to create a free trial (no credit card required) to see how Voyage can improve your team’s development productivity.