Git workflow photo by Yancy Min on Unsplash

Git pull request builders; sometimes called things like Deploy Previews, front-end staging environments, or Review Apps; build working versions of websites or web apps for every pull request. This functionality provides benefits to many different roles across a software development organization. Today, we’ll look at why front-end developers should use one of these deploy preview tools.

Git pull request builder benefits for front-end developers

For front-end developers, the git pull request builder, deploy preview, or in Tugboat parlance, just Preview, offers a range of benefits:

  • Testing that your code works in a production-like environment, off of your local dev environment.
  • Collaborating with UI/UX designers to ensure implementation matches design specs, improving and speeding up the development process.
  • Ensuring that front-end work lines up with back-end code, before merging it into development.
  • Checking for regressions with visual diffs.

In a world where many of us are now working remotely, the git pull request builder also has the benefit of making your work visible to the rest of the organization as you’re doing it. It doesn’t matter whether your colleagues are sitting one desk over, in the next town, or across the world - they can view your work as easily as if they were in a conference room with you.

Let’s dig a little more deeply into how git pull request builders deliver these benefits.

Testing that your code works in a production-like environment, off of your local dev environment.

How many times have you made an awesome front-end tweak, or implemented a beautiful new design, only to find it causes seemingly unrelated regressions when you make a pull request? (That’s right, CSS, I’m giving you side-eye right now…)

With a git pull request builder, you’re effectively taking your local environment out of the equation. In a properly-configured on-demand environment, you can see what your changes would look like on production, before they’re deployed to production - which gives you time to fight with CSS or make those front-end tweaks before you’re in the position of working overtime to provide a hotfix, or looking at a rollback.

Collaborating with UI/UX designers to ensure implementation matches design specs, improving and speeding up the development process.

In many organizations, the role of the front-end developer is to bring to life the design vision of UI/UX designers. But there’s a long way between wireframes and a live production website, and it’s not uncommon for organizations to have difficulties communicating along the way.

With a git pull request builder in the toolchain, organizations can improve communication between front-end teams and UI/UX designers. Update that widget to match the new design spec? Share the pull request preview environment with the design team for review. No local environment required, and with a hosted service like Tugboat, no server infrastructure is required. Get a unique Preview URL, and share it with anyone who needs to be able to review a working version of your code.

Screenshot of Tugboat Preview and Dashboard links as a comment on a pull request in GitHub

Ensuring that front-end work lines up with back-end code, before merging it into development.

In many organizations, front-end work is disconnected from back-end development projects. A git pull request builder provides a great opportunity to test front-end work with back-end code on a shared environment, before merging it to development or production. It’s easier to review and test work completed on an ephemeral pull-request-based environment than to merge work into a main branch like development or QA, and then find out it doesn’t work and needs to be rolled-back or patched.

With a git pull request builder like Tugboat, you can pull in the latest back-end code and test it on a pull-request environment. No need to maintain up-to-date databases or back-end changes on your local development environment. Consider a deploy preview as an interoperability check before merging front-end work into development.

Checking for regressions with visual diffs.

Even simple changes can introduce regressions, and this can be particularly dangerous when changes over here affect pages over there. Code reviews don’t always spot these changes. Visual regression testing on an ephemeral environment is a great way to confirm that front-end updates don’t introduce regressions.

Screenshot of Tugboat's visual regression testing tool showing visual diffs between two versions of a website

Tugboat is a git pull request builder tool that offers visual diffs out-of-the-box, making it possible to incorporate visual regression testing into every pull request’s Preview. Tugboat also offers integration with third-party visual regression testing tools, such as Diffy, for organizations that have more complex visual regression requirements.

Mike Herchel, a Lullabot front-end developer who loves Tugboat’s visual regression testing so much that he wrote an article about it, adds:

One of the biggest benefits of visual regression testing comes when refactoring CSS. Poorly architected CSS can leave its tentacles all over the site, and when rearchitecting or refactoring the CSS, regressions may happen in random places. Those regressions are easiest to resolve when they happen, as it’s easier to trace changes back to the issue when you catch them quickly.

Coming soon: deploy preview benefits for back-end developers

These deploy preview benefits focus on front-end developers, but next week we’ll look at how back-end developers benefit from git pull request builder tools. While front-end roles get some unique benefits related to collaboration with design teams, many of the benefits that back-end developers derive from deploy preview tools, such as faster code review without destroying the local development environment, apply equally to front-end devs. Stay tuned as we continue to explore how these tools benefit the entire software organization.