Stage 4 · Lesson 6 of 8
Not breaking production
Everyone ships a bug eventually. What matters is limiting the damage. Learn how your team releases code.
Do changes go through a environment first, a copy of the product used for testing? Do new features hide behind feature flags, switches that turn a feature on or off without a new release? Do releases go to a small share of users first?
And exactly how do you roll back, or revert, a change? After your change , watch it on , logs or error reports. Avoid risky releases just before you leave for the day or the weekend, unless your team does that on purpose.
Ask what exists for the area you changed. The next topic covers incidents.
Common trapmerging and walking away, assuming someone else will notice if it breaks.
A question to check yourself, an AI practice session and 1 cheat sheet entry come when you add the roadmap to your account. Add it
Resources for this stage
Start with· follow one of these
- GuideFreeGoogle Engineering Practices
Google · Intermediate
Google's guides for change authors and reviewers: small changes, good descriptions and handling comments
- BookPaidThe Missing README: A Guide for the New Software Engineer
Chris Riccomini and Dmitriy Ryaboy (No Starch Press) · Beginner · $29.99 print, $23.99 ebook
The testing, code review, delivery and on-call chapters written for a new engineer