Free up your DevOps team to focus on higher-value activities
Free up your DevOps teams to focus on higher-value activities while getting more engagement and testing from tech adjacent stakeholders.
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.
What is a staging environment?
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.
How do you deploy to a staging environment?
There are four steps in the conventional deployment process to a single staging environment:
- A developer builds, packages and writes unit tests to catch any issues on their local environment.
- If the developer is content with the work, they move ahead to push their changes to a branch on the git repo, where they open a pull request. Continuous Integration runs automated tests and if issues are found, the developer goes back to Step 1.
- Following the completion of Continuous Integration, the developer's peers carry out a code review. This is required to ensure that your team agrees that the proposed changes should be merged into the codebase. Reviewers should not only examine the code, but also run it to ensure that it functions as intended. The developer returns to Step 1 to address any reviewer feedback.
- The developer's branch is ready to be merged into the main branch once the changes are deemed stable by automated tests and peer reviewers at which point Continuous Delivery kicks in and deploys the build of the pull request to the staging server.
Why have multiple staging environments rather than just one?
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.
Code review will not block product feedback collection
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.
Prevent an integration nightmare
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.
Reduce the time it takes to run code written by other developers
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.
Avoid repetitive code reviews
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.
More testing opportunities
On-demand staging environments can be configured to be available through a shared URL, opening up a world of testing and quality assurance possibilities.
- Accessibility testing: Run accessibility tests to make sure that your content can be easily accessed by people with disabilities.
- Cross browser testing: Run cross browser tests to check whether your website works as intended on different web browsers.
- User testing: Run usability tests to discover usability issues and improve your online customer experience.
Increased stakeholder participation
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.
Increased developer productivity
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.
Save time and money
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.
A single staging environment vs multiple on-demand staging environments
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.
Implement deployment automation
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 deployment automation scripts usually perform the following tasks
- Creating complete isolated staging environments with every Pull Request by installing and configuring any necessary software and by starting up virtual hosts from a pre-prepared image in a cloud provider such as AWS.
- Deploying all the services.
- Performing any deployment-related tasks such as seeding the database.
- Performing any required configuration.
- Running deployment tests to ensure that all external services are reachable, and that the system functions as expected.
- Generating unique URLs that you can share with anyone on your team to review and QA.
Learn More
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.
How to implement deployment automation with Voyage
Here are the steps to do so:
- Sign up for a free account
- Go to the Voyage Dashboard Projects Tab
- Select or import your project
- Add your configuration file
- Select Project->Setting->Environment Variables to add any necessary env variables
- All Done
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.
What's next
Head HERE to create a free trial (no credit card required) to see how Voyage can improve your team’s development productivity.