Go With The PR Instance Workflow
As an engineer, the workflow and deployment process is something that can often be seen as tedious and bothersome. When you join a team with a process in place, it is generally easy to adhere to that system and go with the flow, so to speak. But what if you are on a completely new team where there is no system in place and you have the opportunity to set up a whole new deployment process? My squad was placed in this unique position when we formed almost two years ago, and I found that it was a great opportunity to learn more about how we could streamline our process and refine our workflow practices.
So let’s take a look at a typical workflow and where potential pain points can occur. In many cases, there are two permanent branches on a repository; One branch where work is reviewed and one that reflects what is live and on production. An engineer will pick up a task (a ticket), do that work, create a pull request, get some engineers to review the PR, and merge it to whatever the QA branch is. At this point, the designated QA branch may be a mix of passed, pending, and rejected tickets. But what if you have a ticket on QA that has passed and needs to get to production right away (a bug fix, perhaps)?
This is where pull request instances come in handy. On opening a PR against the QA branch, a new Kubernetes pod is created that only contains the changes made within this PR. This enables our QA team to look at a ticket’s acceptance criteria in isolation. If the ticket is rejected, the engineer can make any necessary changes on the working branch. Each time a new commit is pushed up, the instance will rebuild to reflect those changes. Once a ticket is passed, it can be merged to QA ensuring that our QA branch is always in a state that is approved and, subsequently, deployable to production.
Another benefit of PR instances is that they help our code review process for engineers. If an engineer is doing a code review on a frontend ticket, they typically would look at the code and then also need to look at the actual user interface. Before, this would involve pulling down the branch and running the application locally. With PR instances, all you do is click the link and that version of the application is right in front of you.
Our squad also has PR instances implemented on our Hapi API project, enabling our backend tickets to go through the QA process in the same way that our frontend tickets do. We are currently working to set up PR instances with our plugins so that when a PR is opened against one of our plugin repositories, an instance of our Hapi API is spun up with the working version of the plugin. Look out for a future blog post upon success!
Our team has found that PR instances have really streamlined our process and put us another step closer to continuous deployment. They empower us to feel confident in our production deployments and the state of our QA branch at any given time. Feel free to reach out with any questions!