Test and deploy a small web application

Define success before building

A green build proves the compiler accepted the project. It does not prove login works, a direct link survives refresh or server variables are configured. Write observable release criteria: home loads, valid input succeeds, invalid input fails safely and nested routes open directly.

Keep form validation pure enough to test without a browser. In the browser verify keyboard order, focus, narrow layouts and error messages. Use disposable records for mutation tests. Never click live ads to test an integration.

Separate environments

Public configuration is shipped to the browser; private credentials belong in server execution. Prefix conventions are build-tool behavior, not encryption. Inspect built output for accidental secrets and set production variables through the host. Do not put credentials in screenshots or test fixtures.

Development middleware may not exist in a static build. Serverless functions may not run under a plain local asset server. Test the environment you intend to ship rather than treating them as interchangeable.

Verify the artifact

Open a nested URL and refresh it. Request robots.txt, sitemap.xml and ads.txt: they should return the correct text or XML, not an HTML fallback. Inspect status and Content-Type, not just what a browser displays.

Record the commit and deployment tested. Compare a regression against the last verified release. Rolling back frontend files does not undo a database migration; review those changes separately.

Rehearse with a validator

Accept trimmed string names between 2 and 40 characters. This small contract has useful boundary cases: whitespace, null, a 40-character string and a 41-character string. Add your own examples after the provided checks pass.

A release also needs monitoring and a recovery path. Record what remains unknown, such as account approval or ad fill. A checklist makes missing evidence visible; it does not guarantee a flawless release.

Practice a release checklist

Make a release note with three columns: observation, expected result and evidence. Include a fresh session, a direct nested link, a missing page and the three discovery files. For a code editor, include an infinite loop and a syntax error so failure behavior is part of the release criteria. Test an empty search result and storage denial, not just a populated home page.

Use a preview deployment before changing the production alias. Check the real response content type and the browser console; a status 200 can still contain the wrong document. A rollback should restore a known build and its compatible configuration. If data has changed too, a code rollback alone may be insufficient. This exercise validates a small function; it does not claim to deploy an application for you.

Try it yourself

function validName(value) {
  return true;
}
console.log(validName(" Ada "));

Enable JavaScript for this interactive activity. You can read all lesson explanations above without it.