Alternate Title: The Lynch Pin of Safe Patch Releases
Some would argue Patch Releases to Production are inherently risky. In fact with the right approach the risk involved in a Patch Release can be small. The key to managing this risk is Continuous Integration and a disciplined release process.
When a bug is discovered in code that was released 2 or 3 weeks ago, developers may have already begun work on the next big release. Ambitious new features that touch sensitive business logic may be partially implemented. Developers sometimes struggle to navigate this moment when there seems to be no firm ground to stand on. If they release the code in the state it is in, they have untested changes and stand a good chance of introducing new bugs into the Production system.
What is required is a “snapshot” of the code exactly as it appeared the last time it was thoroughly tested and reviewed… that is… the last time it was released. If the bug fix can be applied to well-tested code, the risks of introducing new bugs are greatly reduced.
In the diagram, we can see how tagged code can make patch releases fast and low-risk. In the first section, the normal loop of development occurs. The source code is in a state of flux. Developers are making changes and releasing to the shared server, where it is visible to business stakeholders. Product owners, testers, and stakeholders are reviewing the work, providing their thoughts, and identifying issues. When the new features and improvements are completed to the developers satisfaction, a release is prepared. The release is tagged. Tagging a release is a process that takes minutes, but is crucial to the managing risk. It marks the code in time. The release that goes into production is built from this snapshot.
This tested, reviewed, and approved code is released. Once again, new features begin to take shape. The code base is in flux. Two weeks into this new effort, a bug report comes in. The schema changes have had a an expected effect on another feature. An important client is unhappy. Business raises the issue to highest level. This bug must be patched.
The developers can proceed calmly and with confidence. In seconds they can pull down a snapshot of the code exactly as it looked when it was released. The bug was missed but the fix is simple. Testing is completed in a short time. Only the places that might be influenced by the one new line of code. The team knows they are working with a body of source code which was tested thoroughly during the last major release.
The patch can go out quickly. The developers are relaxed. Business is ecstatic.
Anecdotes 