Deploy a preview

The duration label works locally. A preview lets us check the deployed site before updating the address visitors already use. We'll deploy the saved change, review its URL, and then publish the same commit through GitHub.

From the linked website folder, check the version we're about to deploy:

git status
git log -1 --oneline

Finish any intended edits and commit them before continuing. A CLI deployment can include local files that aren't committed, so a clean working tree helps us connect this preview with the change we will publish.

Outcome

Review the card improvement on a Vercel preview and publish the same saved version through GitHub.

Hands-on exercise 3.4

Create the preview

Confirm the existing project and scope from 3.3, then run:

vercel

By default, this creates a preview deployment. Follow the command's progress and open the deployment URL it returns after the deployment is ready. Use your returned URL; each deployment has its own address. Vercel's deploy documentation describes the default preview behavior.

If the CLI starts a new-project setup flow, cancel and recheck vercel link. We already have a project, and the preview should belong to it. Don't choose production deployment options for this step.

A deployment uploads the application and builds a version Vercel can serve. Its logs may reveal a problem we didn't see in development. Wait for the deployment status before assuming the URL is ready.

Identify which site we're viewing

Open the deployment in the Vercel dashboard. Confirm its environment is Preview and its project is the workshop site. Keep the production URL from Section 1 in another tab.

The local development process can remain running while we review the preview. Changing a file locally after deploying won't update that existing preview. Run another deployment to review a later version.

A preview may require Vercel authentication because of the project's deployment protection. Sign in with an authorized account for the review. Don't remove protection merely to make the link accessible to someone outside the project; use the project's approved sharing options when collaboration requires access.

Review the change on its URL

Find the duration label on both cards. Confirm the gardening workshop still shows two hours and $45, and printmaking still shows three hours and $65. Open the page at a narrow width and use the keyboard to reach the catalog links.

If the deployed result needs an adjustment, make it locally and repeat the review. Commit the correction, deploy a fresh preview, and record that new URL beside the latest commit identifier. Our review note should match the version we're about to publish.

A useful review note is short: commit identifier, preview URL, observed card behavior, and any unresolved issue. Fill it with your actual observations. Don't mark the review complete based only on the agent's description of what it changed.

Publish through GitHub

Check that we're still on the connected production branch from 2.5. On this personal course project, the saved commits are ready for that branch. If your repository requires a pull request, use its review process before release.

Send the reviewed commits to GitHub:

git push

The Git integration should create a production deployment for the configured production branch. Open that deployment and compare its source commit with our review note. A CLI preview and a Git-triggered production deployment are separate deployments, even when their source code matches.

We use Git for this release so the published source also exists in the repository history. Keep the production deployment page open until it succeeds, then check the stable production URL.

Try It

Refresh production and confirm the duration labels are visible. Recheck the card facts and catalog link. Compare the successful deployment's commit identifier with git log -1 --oneline.

If we made a last-minute local edit after creating the preview, repeat the preview review before releasing that edit. The earlier preview contains only the files we uploaded at that point.

The preview build fails

Open the failed deployment's build logs and find the first application error. Record its file path and message. Ask fx for a focused fix, review the diff, and test locally before deploying again. Runtime logs are for requests to a running deployment; they won't replace the failed build log.

The preview looks correct, but production doesn't

Confirm the Git push succeeded and the production deployment uses the reviewed commit. Check that the production branch matches our local branch. If the deployment is still building or failed, resolve that status before investigating browser caching.

Commit

The card commit was created in 3.2, with an optional ignore-rule commit in 3.3. This lesson publishes those saved changes. If the preview required a correction, give that correction its own descriptive commit and review the new preview before pushing.

Done-When

• The preview belongs to the existing workshop project.
• Its card facts and layout pass the review.
• The production deployment uses the reviewed source commit.
• The production URL shows the duration label and working catalog navigation.

Solution

For a clean, committed working tree on the intended branch, the sequence is:

git status
git log -1 --oneline
vercel

Review the returned preview URL and record its source version. After that review passes, run git push and verify the Git-triggered production deployment. Keep both URLs in the review note so we can identify what was tested and what was released.