Mar 22
Why Developers Should Always Do Post-Release Verification
How is the code being shipped? Usually, the code is being created, changed, tested, deployed, and verified in 4 different spaces.
Let’s clarify one thing, our goal is to deliver customer value. That’s the assumption I made. If you don’t agree with the statement, you should ignore the entire article.
Localhost
Green Zone—your own space. Code is created by developers on their machines. They write logic, create functions, compile, execute and test it on their machines. This is why you hear the famous quote.
“It works on my machine”
To avoid this, developers should spend most of their efforts here – including developing, unit testing, manual testing, etc.
Build Agent
Green Zone — a shared space that’s easy to scale up and down. Although it is slower than localhost, feel free to leverage it as much as you can to increase your productivity.
Testing Env
Yellow Zone— a shared place where you compete with other developers. Your team might have multiple testing environments, but that space is still shared with other developers on your team. You probably should
- Take it when you need it
- Release it when as soon as you have completed your task
- Avoid blocking other developers from using it
Production Env
Red Zone — a public place. Any tiny change will impact your customers.
Some developers do the bare minimum — this should be avoided
Develop it, raise a PR, pass the checks, get approval, ship it and forget it.
Developers try to quickly cut code without considering quality or customer benefits. As a Tech Lead or Engineering Manager, you should identify this behaviour and avoid it altogether.
Other developers do a good job but can be better
Develop it, test it, raise a PR, pass checks, get approval, ship it to the testing environment, and do some QA. They may ask for an extra pair of eyes to sign off before shipping to the production environment.
Great developers absolutely nail it
After shipping to the production environment, great developers jump to the production site, testing their features or bug fixes to make sure everything is delivered as expected.
They also check critical user journeys to make sure there is no critical regressions.
Things worth thinking about
- Do you always do post-release verification yourself? 🤔
- Does your team do post-release verification? 🏢
- Have you socialised the concept? 📣
- What’s the impact of not doing it? 🐛
- Have you seen anyone do the bare minimum? 😢
