Test and publish
Want more background?
The idea in everyday life
A finished local page still needs a repeatable public release and a check of the delivered files. README section 5 supplies the GitHub Pages settings, required filenames, upload location, verification steps and rollback procedure. Keep evidence of the actual deployed URL and distinguish unavailable checks from checks that passed.
Deployment means putting your site online. Test the files, publish them through a hosting service, then check the live site.
One step at a time.
Use the sample or information you have permission to use. Keep your work as you go. You can pause between steps.
- 1
Run W1–W10 in the supplied expected-results.md. Test links, native disclosure, keyboard focus, calculator, failure/retry, title, description, SVG, console and missing-file errors. Record checks that require unavailable devices honestly.
- 2
Use the exact README GitHub Pages path: create public maple-study-practice; upload index.html, styles.css, script.js, mark.svg and 404.html at repository root; commit. Publish only supplied fictional or intentionally public content.
- 3
Open Settings → Pages; choose Deploy from a branch, main, /(root), then Save. Wait for success and open the HTTPS URL shown. Relative asset paths support the repository subpath; a pending deployment is not a live site.
- 4
On the live URL rerun W3/W4/W6/W7, navigation/keyboard and an invented path for 404. Record URL, commit, date, actual file sizes and results. Keep last tested source for re-upload rollback; the provider URL is a complete domain plan, with a purchased domain optional.
See how it works.
The supplied README gives every upload and Pages setting. Five site files at the root of maple-study-practice produce a provider URL such as https://YOUR-USERNAME.github.io/maple-study-practice/. Keep the actual successful URL and release record; do not substitute this illustrative address or a local file path. This course provides instructions, not permission to publish private content.
Did you cover these?
- The actual HTTPS URL serves the tested relative-path assets and correct metadata.
- Live success, error/retry, keyboard, navigation and 404 checks are recorded with date and commit.
- Your rollback source and domain plan are complete, and unavailable checks are disclosed.
What to finish
A live site plus a signed launch checklist covering content, function, access, speed, and metadata.
Watch for this
Calling the homepage done while links, form delivery, mobile overflow, or domain variants remain untested.
How can I tell I understand it?
You can reproduce the release from source and verify the live version matches it.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkOptional course overview video · same video as Lesson 1
Full Stack Web Development for Beginners
From freeCodeCamp.org. Watch here or open it on YouTube .
Treat the optional deployment demonstration as background, then follow the included host-specific recipe and retain evidence from your own delivered URL.Tools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.