Dachary Carey
A git pull request builder creates a working version of a website or web app for every pull request. Whether you call these tools deploy previews, on-demand staging environments, or Review Apps, this functionality can dramatically improve the software development process. Deploy previews provide myriad benefits for different roles. Today, we’re looking at the benefits that git pull request builders provide for back-end developers.
Back-end developers who use deploy previews enjoy some of the same benefits as front-end developers, but with less focus on the implementation of visual design and more focus on data and functionality. For back-end developers, the benefits of git pull request builders are things like:
Picture this: it’s Tuesday morning. You sit down at your computer to start work. You’ve been thinking about the code you were working on at the end of the day yesterday, and you’re ready to test a solution you thought up during dinner. But wait! One of your team members submitted a pull request last night and has tagged you to review. Will you destroy your own local and its current state to pull down the PR and test it properly? Or will you start working on your own task, and do the code review later?
With a deploy preview automatically created for every pull request, back-end developers don’t have to destroy their local environments to perform code reviews. This eliminates a common code review bottleneck, making it easier to say “yes” to reviewing that pull request, and moving the process along for the entire development team. With Tugboat as a git pull request builder, website previews show up as deployments right on your pull requests, and you can also configure Tugboat to post comments with links to the Tugboat dashboard, and visual diffs, Tugboat’s visual regression testing tool.
When a back-end developer needs to review a working version of a website or web app, they must pull or fetch the code from the remote or upstream repository and then build it locally. Sometimes, reviewing code means pulling down a large database or other large assets, which can take anywhere from minutes to hours.
With a git pull request builder like Tugboat, which can automatically build a working version of the website for every pull request, that build time starts when a developer makes a pull request. That build happens somewhere else - on Tugboat hardware - and then just sits around, waiting for review. By the time another developer is available to review the pull request, there’s a working version of the website linked right from the pull request.
As a bonus, Tugboat also has the concept of Base Previews, which enable organizations to front-load time-intensive build processes and build subsequent Previews much faster.
When your development and testing main branches consist of many pull requests that have been merged without testing, those branches become unstable, buggy places to review and test code changes. Back-end developers can’t readily know whether a test failure is because of their code, or something that someone else did, and may even ignore test failures entirely as a result. “Development is just buggy - it worked locally.”
Validating local work with other code in a production-like environment before merging to development or testing branches maintains the known “good” state of those main branches. This builds confidence in test failures; if a test is failing, it isn’t just because the branch is buggy, it probably actually indicates an actual issue that needs attention. When that happens, a back-end developer knows to go back and revisit the pull request to fix issues before merging into the main branch.
Even better, debugging in an environment where the only change is the new code in your pull request – not the seven other pull requests that got merged this week – is much easier. By reducing the scope of a code review to the discrete chunk of work represented by a specific pull request, versus reviewing everything that just got merged into development, reviewers can more readily attribute bugs or regressions to the work that caused them. This makes code review faster, and it also speeds the process for back-end developers to fix issues and move on to the next ticket.
There’s a subtle difference between validating work with other code before merging it, and interoperability testing your code across teams or projects. In the former case, everyday code validations are typically taking place within a team. In the latter case, interoperability testing across teams or projects may be the first time a team’s code interacts with another team’s code.
If that happens for the first time in the development or testing branches, the myriad of work represented in those main branches can make it a lot harder to debug the issue. As a back-end developer, this could mean you’ll lose days or weeks trying to identify and fix interoperability-related issues the first time your code is validated alongside another team’s work.
Using ephemeral staging environments for interoperability testing across teams or projects eliminates those issues. With things like work-in-progress pull requests to merge branches that regularly get updated with otherwise siloed code, organizations can perform interoperability testing from early in the development process, ensuring code works together at key milestones throughout the development process.
As a back-end developer, this means that you’re always able to check whether your code works against code being developed in silos by other teams. This lets you adjust your approach or raise red flags early in the development process, reducing rework later and giving you more flexibility to iterate toward optimal implementation.
You won’t get two months into a project, only to find the work that a different team is doing means you need to completely rethink your approach. You also won’t have to touch code that you wrote months ago, to figure out why it’s not working now that it’s finally being validated against production data.
Want to incorporate a new framework, add a microservice, or change the way you’re using existing infrastructure? You can do the work locally, but asking other folks to review that work, or testing the work against production infrastructure, can be a challenge. Getting other folks to review your infrastructure changes can result in dependency hell (Ruby/Rails, I’m looking at you here) as they attempt to pull the code and test configuration changes locally.
Working with different versions of your stack may not be viable if you’re working with constraints in server infrastructure. For example, when you’re working on infrastructure changes, and your colleagues are working on feature development work, managing shifting stacks while deploying to static server infrastructure can quickly become a nightmare. Switching back and forth between versions of your app or website can become a massive time sink, and can ultimately fail to accurately represent infrastructure changes.
An ephemeral staging server provides a place to experiment with infrastructure or configuration changes where your work won’t conflict with feature work or other code that colleagues are writing.
Are you working on a migration to a newer version of a framework? Do you want to put together a prototype of one of your microservices in Python without impacting the NodeJS version of this microservice that your web app currently depends on? Using a git pull request builder makes it possible to share working versions of this work in an ephemeral environment, where it won’t block feature development or other work that your colleagues are doing.
These ephemeral environments also have the added benefit of making it possible for colleagues to review your work without having to destroy their own local development environments, or getting stuck in dependency hell trying to update their local to work with your new version of the stack. They can see a working version of the site in the deploy Preview, and with a git pull request builder like Tugboat, they can get a terminal directly into services to try different approaches, debug, or suggest changes.
This breakdown focuses on the benefits of git pull request builders for back-end developers, but these tools offer benefits across the entire software development organization. Next time, we’ll take a look at the benefits that these deploy preview tools can offer QA and testing engineers. Many of the benefits we’ve explored in this article apply equally to QA teams, but there are some additional benefits related to testing and time to review pull requests that can simplify QA tasks, as well as reduce the time it takes to review and rework tickets.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
