This set builds vocabulary for pull-request-based deploy preview workflows.
0 / 5 completed
1 / 5
At standup, a dev mentions that opening a pull request automatically generates a live, shareable URL running that branch's exact changes. What is this feature called?
A deploy preview automatically builds and deploys a pull request's branch to its own live, shareable URL, letting reviewers and stakeholders interact with the actual running change before it merges, rather than relying solely on reading a diff. This visual, interactive review is especially valuable for frontend or design-related changes. It's a standard feature across many modern static-hosting and Jamstack deployment platforms.
2 / 5
During a design review, a non-technical stakeholder wants to click through a pending UI change without knowing how to check out a branch locally. Which capability addresses this?
Sharing a deploy preview URL lets a non-technical stakeholder click through the actual running change in a browser without needing any local development setup or git knowledge. This dramatically lowers the barrier to getting feedback from people outside the engineering team. It shifts review from reading code to directly experiencing the resulting interface.
3 / 5
In a code review, a dev notices each new commit pushed to an open pull request automatically triggers a fresh deploy preview build. What does this reflect?
Continuous preview deployment automatically rebuilds and redeploys the preview URL each time a new commit is pushed to the pull request's branch, so the live preview always reflects the latest changes without requiring a manual trigger. This keeps the preview reliably in sync throughout the review process. It mirrors the same automation philosophy as continuous integration applied to visual review.
4 / 5
An incident report shows a deploy preview accidentally exposed a feature still under embargo because the preview URL was publicly guessable and shared externally. What practice would prevent this?
For a change that must stay confidential before release, restricting deploy preview access, whether through authentication or a genuinely unguessable URL, prevents the preview from leaking sensitive unreleased work if the link is shared outside the intended audience. Leaving every preview fully open by default assumes no pull request will ever involve embargoed content. This risk-aware configuration is worth applying selectively rather than disabling the valuable preview feature entirely.
5 / 5
During a PR review, a teammate asks how a deploy preview differs from simply reading the code diff in the pull request. What is the key advantage?
Reading a code diff shows what changed in the source but doesn't convey how it actually behaves or looks when rendered, while a deploy preview lets a reviewer click through the real running result. This is especially valuable for catching visual regressions or UX issues that are hard to spot from source alone. The two methods complement each other rather than one fully replacing the other.