Lesson 30 / Launch

Deployment QA

Time: 39 min
Type: Reading + Practice
Level: Intermediate
Use: Studio Support

Use a deployment-day checklist to commit, push, verify GitHub Pages, test the live URL, and catch links, paths, mobile, accessibility, metadata, and performance issues.

Course Role

Studio Support

Best during work sessions, critique, debugging, project planning, or final polish.

See course roadmap Minimum viable paths

Mark lesson complete

Teacher Notes / In-Class Use

Demo Live

Model the core workflow from the lesson using a small class example.
Connect the example back to the first goal: Follow a clear commit, push, deploy, and live-site testing sequence

Try In Class

Publish your current project and test the live URL.
Have students make one visible change, save, refresh, and explain what changed.

Submit Or Check

Ask students to show the work in the browser, not only in the editor.
Have students commit their progress with a clear message when the checkpoint is stable.

Watch For

Students copying code without checking file paths, spelling, or capitalization.
Visual changes that work locally but break when the project is published.

Learning Goals

Follow a clear commit, push, deploy, and live-site testing sequence
Verify GitHub Pages branch, folder, deploy status, and live URL
Run local and live QA checks for links, paths, responsive layout, accessibility, metadata, and performance
Prepare the correct final submission information

Local Done Is Not Published Done

A site can work locally and still fail after publishing. Deployment QA means testing the live URL, not only the VS Code preview.

Use this lesson as a launch checklist. Do the checks in order so you know whether the problem is local, in GitHub, or on the published site.

Launch Sequence

Stage	What To Do
Before commit	Remove placeholders, test locally, check responsive layout, and confirm images are optimized.
After commit	Review changed files and make sure the commit message describes the work.
After push	Confirm the latest commit appears on GitHub.
After deploy	Wait for GitHub Pages to finish publishing and open the live URL.
Final review	Test links, images, CSS, JavaScript, accessibility, metadata, and mobile layout on the live site.

GitHub Desktop Workflow

Commit and push are different steps. A commit saves a snapshot locally. Push sends that snapshot to GitHub so GitHub Pages can publish it.

Step	Action
Check changes	Open GitHub Desktop and review the changed files list.
Write summary	Use a short commit message such as "Finish project homepage".
Commit	Click `Commit to main` to save the changes locally.
Push	Click `Push origin` to send the commit to GitHub.
Verify	Open the GitHub repository and confirm the latest commit is visible.

GitHub Pages Settings

If the live site is missing or stale, check the Pages settings before rewriting code.

Setting	What To Check
Branch	The site is publishing from the expected branch, usually `main`.
Folder	The site is publishing from the correct folder, often `/root` for simple projects.
Deploy status	The latest deploy finished successfully.
Live URL	You are testing the Pages URL, not only the repository URL.
Custom domain	If used, the domain points to the correct Pages site.

Path and File Name Checks

Published websites are less forgiving than local previews. Path spelling and capitalization matter.

Problem	Why It Breaks
`Image.jpg` in HTML but `image.jpg` in the folder	Capitalization mismatch can break on the published site.
`css/style.css` in HTML but folder is `CSS`	Folder names must match exactly.
Spaces in file names	URLs become harder to write and easier to break.
Local file paths	Paths like `C:/Users/name/Desktop/image.jpg` only work on one computer.
Uncommitted files	GitHub Pages cannot publish files that were never committed and pushed.

Live-Site Testing Checklist

Run this checklist on the published URL after GitHub Pages deploys.

Homepage loads without a 404 error.
Every main navigation link works.
Footer links and call-to-action links work.
Images load on every page.
CSS styles load on every page.
JavaScript interactions work where expected.
Forms do not fake-submit unless intentionally disabled or explained.
The browser console has no obvious errors caused by your code.
No placeholder text, broken images, or unused template content remains.

Responsive QA Checklist

Test more than one screen size. Drag slowly between sizes because layouts often break between preset device widths.

Width or Context	What To Check
Small phone around `320px`	Navigation, buttons, forms, and text remain usable.
Large phone	Cards, images, and hero content scale cleanly.
Tablet	Two-column areas and galleries do not feel cramped.
Desktop	Line length, spacing, and max-widths stay readable.
Any width	No horizontal scrolling unless intentionally designed.

Accessibility QA Checklist

Navigate the live site with Tab, Shift + Tab, Enter, and Space.
Confirm focus styles are visible.
Check that images have useful alt text or empty alt="" when decorative.
Confirm every form input has a visible label.
Check heading order and make sure each page has one clear h1.
Check text, link, and button contrast.
Make sure important information is not communicated by color alone.

Metadata and Findability Checks

Metadata helps the page make sense in browser tabs, search results, bookmarks, and shared links. Lesson 31 goes deeper, but these checks belong in launch QA too.

Each page has a meaningful title.
Important pages have a useful meta description.
The homepage has a clear h1 that matches the site purpose.
The favicon appears if the project includes one.
Open Graph metadata is present if shared-link previews matter for the project.

Performance and Image Checks

Large images are resized and compressed before publishing.
Images include width and height when possible to reduce layout shift.
The first visible image is not lazy-loaded if it is important above the fold.
Unused large assets are removed from the project folder.
Only necessary fonts, scripts, and embeds are loaded.
Lighthouse or PageSpeed Insights is used as a support tool, not the only test.

Common Launch Problems

Problem	Likely Cause	Fix
Site shows `404`	Pages settings, branch, folder, or URL is wrong.	Check repository Settings > Pages.
Old version is live	Latest commit was not pushed or deploy is still running.	Push origin and wait for the deploy to finish.
CSS missing	Stylesheet path or capitalization is wrong.	Open the CSS URL from the live page and fix the path.
Images missing	Wrong folder path, case mismatch, or file not committed.	Compare `src` values with actual file names.
Subpage links break	Path assumes the wrong folder depth.	Rewrite links relative to the current HTML file.
JavaScript does not run	Script path, console error, or missing element.	Open the console and read the first error.
Mobile layout breaks live	Fixed widths or untested responsive state.	Use DevTools device toolbar on the live URL.

Final Submission Checklist

Before submitting, make sure you are sending the right evidence of the finished project.

Submit the live URL, not only the GitHub repository URL.
Submit the repository URL too if the assignment asks for it.
Include the project name and your name if required.
Mention any known issues honestly and briefly.
Confirm the live URL was tested after the final push.
Do one last click-through from the homepage to the important pages.

Checkpoint

Before moving on, make sure these feel true.

I can test the published URL, not only the local site.
I can check links, images, responsive layout, and accessibility before submission.
I can troubleshoot common GitHub Pages problems.

Practice

Publish your current project and test the live URL.
Confirm your latest commit appears on GitHub after pushing.
Find and fix one issue that appears only after publishing.
Run a live-site link, image, responsive, keyboard, and metadata pass.
Write a short final submission note with the live URL and any known issues.