A production change should move through context, reproduction, risk review, rollback planning and verification — even when the code change itself is small.
Before editing production code, identify which users, services, tables, jobs and integrations are touched. A one-line change inside authentication or payments can be riskier than a hundred-line isolated feature.
Read recent deployment notes and related incidents. If the system has no change history, create one now; future debugging gets easier when deployment context exists.
Create the smallest repeatable test that demonstrates the problem or desired behaviour. Then make the change in a non-production environment and test both the happy path and obvious failure paths. For data changes, test with realistic volumes and constraints.
A passing unit test is useful but not sufficient when the change depends on web-server configuration, queues, third-party APIs or database permissions.
Know how to reverse the change before pressing deploy. That may mean keeping the old release available, making database migrations backward compatible, feature-flagging behaviour or preparing a restoration script.
If rollback would destroy data, that fact should change how the rollout is performed.
Check application health, logs, error rates and the actual user workflow. Do not treat a successful file upload or CI pipeline as proof that the release is healthy. Production verification should test the outcome the change was meant to create.