Deployment Confidence is a measure of a change’s likelihood to break the production environment. Some changes are trivial, and after code review and testing have little to no chance of breaking the production system. Other changes, especially when they are sourced from long-lived branches and involve many changes, would be riskier. The higher the risk, the lower the Deployment Confidence is.
It doesn’t take much skill to identify changes that have a high likelihood of breaking production, but it does take some experience. In general, things to look for that should decrease your Deployment Confidence include:
local development == staging === production
How consistent are your Development, Staging, and Production environments? If they are extremely dissimilar, then you simply cannot have high confidence in your changes functioning properly in production.
Some dev teams believe they can work around this by having a staging environment that is near perfectly identical to production. Staging should always be extremely similar to production. If your development environment is not extremely similar to staging, then you’re introducing waste into your value stream. [Context Switching Kills Productivity]
- Many changes made without deployment (more than a thousand lines of code added net)
- Long-Lived Branches
- Major refactoring
- Complex database migrations