Dachary Carey
A new type of software development tool has been emerging for the past few years; the git pull request builder. You may have seen this same feature called Deploy Previews by Netlify, on-demand front-end staging environments by FeaturePeek, Review Apps by GitLab; the industry hasn’t yet centralized on a way to refer to this concept.
With half a dozen new entries in this space in the last two years, including big platforms providing this functionality as a feature to entice developers and software organizations, there’s no question this space is growing. Whether you call it a deploy environment, a website preview, or an on-demand staging environment, here’s what you should know about git pull request builders, and why they should be a part of your organization’s software development process.
A git pull request builder does what the name would suggest; it builds a working version of your website or web application for every pull request. Specifics vary depending on the tool you choose. Some people have set up GitHub Actions to build working versions of websites on existing staging, QA, or development servers. Other tools, like Tugboat or Netlify’s Deploy Previews, create a hosted environment that springs into existence when you create the pull request. Tugboat’s git pull request builder also deletes the environments when the pull requests are merged, doing the housekeeping to keep projects clean and small.
Most of these tools post links to the environments directly on the pull requests in GitHub, GitLab, or Bitbucket, so developers can easily access them. Some also share links to Jira, Slack, or other platforms. Ideally, people who visit these pull request environments can do it from wherever they interact with the workflow; no need to login to yet another dashboard for this functionality.
The creators of these tools use different messaging to communicate about the benefit of git pull request builders; organizations promote this concept as a collaboration tool, a code review tool, a testing tool, a development tool - and the truth is, it’s all of these things.
The reason you’ll see such fragmented messaging about the benefits of git pull request builders is that the value of these tools varies depending on the person using them. The git pull request builder serves many different roles in an organization in different ways; one way of talking about it is to break down the benefits specific to each type of person using them.
We’ll dive deeper into how each of these roles benefits from a git pull request builder in the coming weeks:
While the benefits of a git pull request builder cross over some of these roles, the value they provide is substantial. Breaking that down by role is a useful exercise to understand how these on-demand environments benefit individuals and the organization at large.
Some of the benefits of using a git pull request builder to create on-demand environments for every pull request include:
Even if your organization already has server infrastructure, git pull request builders have a role to play. They solve some common pain points for organizations that already have infrastructure in place, or are looking to add more infrastructure for new projects or to improve the software development process.
No matter how many deploy destinations your organization has, somebody probably thinks there are too few. Whether the struggle is too few QA servers to test multiple feature branches; too few development servers for discrete development projects; or not enough UAT environments for stakeholders to evaluate and accept new features; many enterprise software development organizations lack sufficient infrastructure.
An environment for every git pull request ends many of these resource contention issues. And something like Tugboat, with the ability to Clone and Reset preview environments, adds flexibility for concurrent or sequential testing, code review, or UAT.
IT and DevOps managers know infrastructure isn’t cheap. And engineering managers across the industry know that the time it takes to provision new infrastructure can add weeks or months to the development process. Git pull request builders provide more infrastructure for a similar or lower cost, and shortcut the time it takes to provision new infrastructure.
One of Tugboat’s clients recently reported that a Tugboat Enterprise Plan, which for that client provided enough storage space to host 10 to 15 pull request environments simultaneously, cost roughly the same as one of their traditional servers. That client has since moved to an on-premise plan to leverage Tugboat’s pull request environments on a much larger scale.
For time to provision new infrastructure, a different enterprise client reported delays of months to get new servers up and running after starting new development projects. With ephemeral environments on-demand, organizations don’t face the same red tape as provisioning new pieces of hardware - especially if the infrastructure already exists in the SDLC. Tugboat’s clients have been able to shortcut the provisioning process to get new environments building in a matter of days, which has been a big win for development teams that want to move fast.
In the coming weeks, we’ll break down the benefits of git pull request builders for different roles across the software development organization. We’ll also look at how you can evaluate different tools to find the best git pull request builder for your organization. And finally, we’ll provide a roundup of all of the git pull request builders that are currently available, whether they’re SaaS apps or provided as part of a larger hosting platform.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
