The developer workflow I use before touching production
A production change should move through context, reproduction, risk review, rollback planning and verification — even when the code change itself is small.
Understand the change surface
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.
Reproduce and test the intended behaviour
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.
Plan the rollback before deployment
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.
Verify after deployment
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.
Keep the useful part, not just the reading.
Save this article, explore the related resources or continue the discussion in the TWE community.