Guide · AI coding & owned software
What to Check Before Deploying a Small App Change
Match your checks to the behavior you changed, then verify the configuration, data dependencies, and recovery path before release.
A small change can cross several parts of an application. Adding a form field might affect validation, storage, email, and the screen where a teammate reads the submission. Before deploying, trace the path the change actually uses. The size of the visible edit isn't a reliable measure of what needs checking.
Start with the promised behavior
Write down what should be different after the release. For a hypothetical request form, the change might let a user add an optional reference number and show that number to the coordinator. That gives you a clear end-to-end check.
Try the ordinary case and a few relevant edges. Submit with and without the value. Use a value at the allowed length. Open an older record that doesn't contain the field. Check the role that should see it and, where relevant, a role that should not. Choose cases that exercise the change rather than repeating a long checklist unrelated to it.
Check the dependencies between releases
Determine whether the web code depends on a new backend function, database field, or provider setting. Plan the order so one deployed part doesn't call something that isn't available yet. If old and new versions may run at the same time, consider whether they can both handle the data during the transition.
Check configuration by name and purpose, without copying secret values into release notes. A feature that works locally may rely on an environment setting absent from production. Confirm the intended account, destination, and permissions for the services the change uses.
Review the patch as a whole
Read the changed files and ask whether the scope matches the request. Watch for accidentally removed checks, unrelated formatting churn that hides a meaningful edit, and generated files that shouldn't be published. Review the final state rather than relying on the sequence of changes you remember making.
Run the appropriate tests and the deployment build. Treat each result as evidence for what it actually checks. A build confirms that the application can be compiled in that configuration. It doesn't prove that a payment succeeds, a message reaches the right audience, or a user can complete a particular task.
Know how to recover
Identify the last working release and the steps needed to return to it. Consider data changes separately. Restoring an older application version may not undo records written by the newer version, and destructive schema changes can make recovery harder.
For an uncertain change, reduce the initial scope where the application supports it. A controlled test group or a reversible configuration change can help you observe behavior before wider use. Choose the approach deliberately; don't assume a deployment platform automatically provides the recovery behavior your application needs.
Verify the live path once
After deployment, check the public route or workflow that changed. Confirm you're viewing the intended environment and release. Repeat the meaningful scenario with suitable test data, and inspect the result in the place where the next person will use it.
Record what was deployed and what you checked. If you discover a problem, keep the evidence and act on the recovery plan. A short, accurate release note is more useful than a long list of checks that nobody can connect to the behavior being shipped.