Testing & shipping

Choose an observable outcome and test it through roles and labels. For example, submit invalid input and assert the visible error, rather than checking private state or CSS classes. Use small module tests for rules and a few browser tests for the critical journeys. The snippet assumes your local app has an Email field and a Save button; adapt it to your actual interface.

Run an automated scan on the rendered state, then use Tab, Shift+Tab, Enter, Space, and Escape manually. Check focus visibility, focus order, drawer or dialog closing, and focus returning to the opener. Include errors and expanded controls, not only the initial page. Automated rules catch some defects; they cannot establish that the whole experience is accessible.

Replace fixed sleeps with assertions that wait for the expected state. Give tests independent accounts or records, control third-party responses, and keep traces from failures. Check whether the application, test data, or selector is unstable before adding retries. A test that passes on retry still needs investigation.

Run checks and build, serve the generated production output using the framework's documented command, and exercise critical routes. Verify direct loads, unknown-route status, assets, and mobile navigation. After deployment, repeat a focused smoke check on the real URL; local build success alone does not establish a successful release.

Treat every value shipped to the browser as public. Vite exposes variables with its configured public prefix, including VITE_ by default, in client code. Keep private credentials on the server or in the deployment secret store, use minimal permissions, and never print them in build logs. If a credential leaks, revoke or rotate it; deleting the file does not remove repository history.

Install from the committed lockfile, use a supported pinned runtime, and run lint, typechecking, tests, and build before release. Keep deployment credentials out of untrusted pull-request jobs. Protect the release branch with required checks, and verify that the deployment corresponds to the tested commit. This is guidance for your project pipeline, not a ready-to-copy workflow.

Record the failure, request or correlation ID, release identifier, and operation so you can connect a report to the deployed code. Keep stack traces on the server and show a recoverable message to the user. Exclude secrets and sensitive payloads from logs, and check that alerts reach someone who can act. Use structured fields rather than concatenating untrusted text.

Use an expand-and-contract rollout: add the new structure first, deploy code compatible with old and new versions, backfill and validate data, then retire the old structure after the rollback window. Estimate locking and table rewrite costs before production changes. Application rollback is not automatically a database rollback.

Restore a backup into a separate environment and verify schema, representative records, application access, and the time required. A successful backup command proves creation, not recovery. Account for roles, permissions, object storage, and external services separately; a database dump does not contain your entire application. Record the recovery procedure and repeat it after significant changes.

Identify the last known-good artifact and the exact rollback action before deploying. Record a trigger, an owner, and a verification checklist. Confirm the previous application remains compatible with current data and configuration. After rollback, verify user journeys and error rates; switching a deployment alone does not prove recovery.