---
title: "Test and Publish"
description: "Check the complete form on a protected preview, record the result, and publish the reviewed version through GitHub after verifying submission protection."
canonical_url: "https://vercel.com/academy/build-and-launch-with-ai/test-and-publish"
md_url: "https://vercel.com/academy/build-and-launch-with-ai/test-and-publish.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-09-25T16:42:54.116Z"
content_type: "lesson"
course: "build-and-launch-with-ai"
course_title: "Build and Launch with AI"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Test and Publish

# Test and publish

The email tests pass, and we've verified the request limit. Now we'll check the complete form on a deployed preview before making it available on the public site.

From the website folder, confirm the feature branch and saved version:

```sh
git branch --show-current
git status
git log -1 --oneline
```

Stay on `workshop-interest` with a clean working tree. Keep the protection note from 4.6 beside the commit identifier.

## Outcome

Release the reviewed interest form through GitHub and confirm that a production inquiry reaches the owner.

## Hands-on exercise 4.7

### Check the preview

Run `vercel` from the linked project folder. Open the returned deployment URL once it's ready and confirm the project and **Preview** environment. Use an authorized account to review the protected preview.

Preview needs the email settings configured in 4.3. A local `.env.local` file doesn't supply them to Vercel. Leave Production email disabled while we review this version.

Check each case with test details:

| Case                       | Expected behavior                                       |
| -------------------------- | ------------------------------------------------------- |
| Missing required input     | Useful field feedback, with no send                     |
| Valid inquiry              | Acceptance message and one controlled owner email       |
| Submission pending         | Button disabled while the request is in progress        |
| Narrow screen and keyboard | Readable fields, visible focus, reachable submit button |
| Unknown workshop URL       | Missing-page UI and catalog link                        |

Keep the Firewall rule enabled. If it blocks a test, wait for the window to expire before sending again.

The automated tests from 4.5 cover the helper's error results. In 5.3, we'll deliberately break sending on a preview to inspect whether the browser keeps the visitor's draft. Leave that browser failure check marked as pending until then.

### Record the release review

Save the commit identifier and preview URL with what you observed. Include the controlled inquiry's inbox result and the protection check from 4.6. If a check failed, fix it locally, save the correction, and review a new preview before continuing.

You should be able to identify the exact version you tested and explain whether the inquiry arrived. The agent's description of its code can't answer those questions for us.

### Propose the change on GitHub

A *pull request* proposes merging this branch into the production branch. It gives us a place to inspect the combined changes and record the preview review before releasing them.

Push the feature branch and open the pull request:

```sh
git push -u origin workshop-interest
gh pr create --base main --head workshop-interest --title "Add workshop inquiries" --body "Add workshop pages and the validated owner-email form. Preview and delivery reviewed before release."
```

Use your production branch in place of `main` if it differs. In GitHub, review **Files changed** and confirm credentials aren't included. Add the preview observations and protection result to the description. Follow the repository's required checks or reviews.

### Enable and release production email

After the preview and protection checks pass, add the three email settings to **Production** in the existing Vercel project. Use the same controlled sender and owner inbox as before. Check the project, environment, and recipient before saving.

Environment changes apply to a new deployment. With those settings ready, merge the reviewed pull request through GitHub and wait for its production deployment to succeed. Confirm its source matches the merged pull request; a squash merge can have a different commit identifier from the feature branch.

## Try It

Open production in a signed-out browser and follow the gardening card. Submit one controlled inquiry, then check the owner inbox. Record the delivered message and confirm the intended owner is still the recipient.

Review the Firewall's matched traffic for the intended POST path. Use the production deployment to identify the released code. After verification, update the local production branch:

```sh
git switch main
git pull --ff-only
```

Use your actual production branch name. It should now contain the released pages and form.

### The tests pass, but preview sending fails

Check Preview's configuration and Resend's sender/recipient restrictions. Unit tests use a fake sender, so they don't verify account permissions or environment values. Keep the pull request unmerged until the preview works.

### Production still says email isn't connected

Check that the three settings belong to Production in this project and that the deployment was created after they were saved. Confirm the merged source includes the email adapter. Fix the configuration or source before creating and checking a fresh production deployment.

## Commit

The feature and tests are already saved on `workshop-interest`. This lesson publishes them. If preview review requires a correction, save that correction as its own commit and review a new preview before merging.

## Done-When

- [ ] The preview passes the form checks and a controlled inquiry reaches the owner.
- [ ] The pull request records the preview observations and verified submission protection.
- [ ] Production settings are configured before the release deployment.
- [ ] The merged change deploys successfully and a production inquiry arrives in the owner inbox.

## Solution

A complete release connects the reviewed commit to a preview, a merged pull request, and the production deployment. Keep those identifiers with the observed inbox delivery and Firewall result.

Follow the sequence above: review the preview, record the checks in the pull request, configure Production, and merge. Verify the public form before moving on to bookbinding.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)