Are you afraid to deploy a master branch to the production? Do you still mess with staging servers? Do you spend a lot of time to find out which Pull Request (PR) has introduced a bug?

One of the principles of agile is that the master **branch should always be potentially shippable. That means it should always be of production quality. In order to achieve it, there are some practices like GitFlow and Code Review. But still we are not confident!

There is very effective practice to reduce risks and make master stable: run Functional Verification of requested changes on each PR. You could add this practice as a part of Code Review but it’s also OK to run it as a dedicated step in order to involve QA Team or Product Owner.

Ideally, you should be able to have a shareable live environment with only changes related to the PR. I came up with a name for such environments — Isolated Testing Environment.

This practice is well known, but development team might have some objections to add it: setup a new staging instance or build and deploy is very time consuming procedure or cause a mess during the process.

I would agree with them in case there are some real issues to implement it. But, nowadays, we have a lot of tools, like Kubernetes and Docker, which reduce the complexity of isolated testing environment creation. And it’s time to clean up a technical debt in both delivery and development process as it is crucially important.

Here comes Heroku Review Apps

If a human operator needs to touch your system during normal operations, you have a bug.

Carla Geisser, Google Site Reliability Engineering

To create Isolated Testing Environment per each PR you could use the local scripts or automatize such routine with tools like Continuous Integration.

For Web Applications, there is a “*Reviews Apps” feature *by Heroku.

Review Apps run the code in any GitHub PR in a complete, disposable Heroku application. Review Apps each have a unique URL you can share. It’s then super easy for anyone to try the new code.

How to start?

On Heroku, there is a guide on how to setup the Review Apps feature.

We have some extra changes in order to obtain a better experience. This is an example for *Ruby on Rails *but could be adopted for other web frameworks.

Update configuration

Our secret sauce in app.json is environment variables which we require to be set for Heroku Review Apps instances. It allows to detect environment and reduce the build time.

Heroku Review Apps configuration

Sample Data

We require testing sample data to be populated on each deploy. For this purposes, Heroku provides us with a custom release phase and this is our solution

Summary

PR Functional Verification with Heroku Reviews Apps provides a safety net while working on critical code and infrastructure.

• Safer master;

• Faster feedback from Product Owner or Clients;

• Good for Asynchronous Development Process;

• Reduced on-boarding time and skill requirements for QA Team or Product Owners;

• Non-technical team members or clients are able to easily review and approve changes to an application;

• No manual routine involved with support of Isolated Testing Environment;

• Removed conflicts for server usage.

Now your team can focus on perfecting the user experience as well as finding and fixing bugs much earlier in the development process, leading to more frequent and higher quality releases.

And finally we got improved customers’ and clients’ satisfaction and appreciation.

Useful Links

• “Eliminating Toil” from Google’s “Site Reliability Engineering” Book

• “Simplicity” from Google’s “Site Reliability Engineering” Book

• Review Apps Guide

• The simplest way to automate delivery of your React Native Application

Paul Keen is an Open Source Contributor and a Chief Technology Officer at JetThoughts. Follow him on LinkedIn or GitHub.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories.