Dachary Carey
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.
For front-end developers, the git pull request builder, deploy preview, or in Tugboat parlance, just Preview, offers a range of benefits:
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.
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.
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.
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.
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.
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.
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.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
