The Mr. Meeseeks of the QA world
If, like me, you are a fan of the hit series “Rick & Morty”, you have obviously seen the episode with the infamous Mr. Meeseeks. Elsif you haven’t seen “Rick & Morty” or you simply aren’t familiar with this episode, Mr. Meeseeks is a race of short-lived beings whose sole purpose in life is to solve a single problem, then die. If you have ever worked on a team with a dedicated QA department, which you would like to review one or more features at a time independently of other features which also need QA or UAT (user acceptance testing) before moving on to production, this article is for you.
I should clarify a little more. If you are deploying on Heroku, this article is for you. The Heroku pipeline allows you to generate review site applications based off of pull requests in your Git repository *. Like Mr. Meeseeks, these review applications exist for a short while, allowing a QA agent or other stakeholder to interact with a new feature in your application apart from other features, updates, exorcisms. Then when you are finished with a review app, or the pull request is finished, the review app dies.
Why is this important? Great question. I’m glad I asked it for you. Before I started using the Heroku pipeline and review apps, I would have to provision an new Heroku app with a name like myspecialapp-staging or myspecialapp-dev and spend a couple hours configuring it correctly, setting up my remote connections in my CLI, seeding a database and then testing to make sure everything got set up correctly. This was an ok set up for the time being, but it had major, glaring, ugly, snot-nosed limitations. Mainly, that if I had to do two separate features that made a change to the same view or method or action, I would have to tear down the database and re-seed it with data and run my new migrations. That’s worst case scenario. Best case scenario I would have to frantically email anyone who might be testing that feature to stop immediately so I can push an update and allow another group of testers to interact with my new feature set. Exhausting!
Mr. Meeseeks on the other hand allows me to work on a feature, push it to GitHub, create a pull request and automatically ( within 5 minutes ) have a fully functional review app in place that I can let live until all testing is satisfied. And the best part is, I could do this as many times in a day as I wanted to. No more limitations standing in my way or causing more friction between my team and the QA team.
Now comes the best part. Heroku review apps are also highly configurable. This means that I as the admin can set the review apps to point at a singular database. Something I’ll talk about a little later. More importantly it allows for CI/CD integration! This is huge because now I can have a layer of assurance helping to guarantee that the new application is healthy before I send it off to another team for review.
Back to the singular database I mentioned. Why would I go through all of this work to set up a pipeline and then have all my review apps be limited by a single database? The short answer is, review apps only allow you to create the free tier of PostgreSQL databases in Heroku which is limited to 100,000 rows. If you want to test out some real world data, chances are you are going to want to chunk in a pg backup with a few million rows. By pointing your review apps by default to the same reliable database ( obviously a staging database ) you can avoid this limitation by making real world data available to you.
Hopefully this information finds you well and has inspired you to make some updates to your development process. For more information on Heroku Pipelines, Review Apps, and CI/CD, I have included some helpful links below.
On the Road Code 