A feature is not ready simply because its code has been written. In this lesson, Carlos Sanabria explains the checks between a completed change and the moment customers encounter it.
The process combines automated tests, a staging environment and clear ownership. Each provides a chance to identify a problem before it becomes part of the live experience.
What you'll learn.
- Use automated checks and staging for different kinds of verification.
- Make release approval someone’s explicit responsibility.
- Treat deployment and recovery as part of the product’s reliability.
Check the change before release.
Automated tests can flag broken behavior when the code changes. They are one safeguard in the process, helping the team find regressions before deciding that a change is ready.
A passing check should have a clear meaning. Ask which customer journeys it covers and what other review is needed. The presence of a test command is less important than whether it detects the kinds of problems the product is likely to encounter.
Use a staging environment.
Staging gives the team somewhere to review an integrated change before exposing it to real customers. It provides a practical place to check that the product works as intended in a deployment-like setting.
Carlos highlights the risk of skipping this step: the first people to discover a release problem may be the users. Decide what is reviewed in staging and how the reviewer confirms that the intended version is the one being tested.
Assign release ownership.
Someone needs responsibility for checking the change and authorizing its movement into production. Clear ownership prevents a release from becoming a sequence of assumptions about what someone else verified.
The recording uses the Knight Capital deployment failure as an example of the consequences of weak release safeguards. Its purpose in the lesson is to make deployment discipline a business concern, not merely a technical procedure that happens after the important work.
Plan for the live result.
Production is the environment customers use. After a change reaches it, the team needs to know that the expected behavior is available and be able to respond if it is not.
Review the complete path with your team: what tests run, what staging checks occur, who approves the release and how a failed change is handled. Make those answers concrete enough that the process can be repeated by more than one person.
Release safeguards protect the customer experience while the product changes. Treat verification, approval and recovery as part of delivery, rather than leaving them to chance at the end.
