Making a Continuous Deployment Model Succeed
So I’m not going to go into the specifics of what a continuous delivery model is or what it’s supposed to do. I wanted to talk about what I felt could make a continuous delivery model succeed.
Short Iterations
Short and quick iterations are proven to provide more value and allow engineers focus more on getting code written and out the door. Facebook is a great but extreme example of this by pushing code into production on a daily basis. In an ideal world we should be pushing code live at least once a week. This forces us as engineers to rethink how we write code, forcing us to develop in incremental and batch changes.
Quick Reaction
When we are deploying code in small batches, it gives you the ability to quickly react to situations such as bugs or changes in your MVF. If a feature that was implemented was deemed to be a failure in an AB test we can quickly remove it and not have wasted time, resources and money. This quick reaction time is critical but an excellent side effect.
Fallback
Always have a fallback mechanism in place.
Better Planning of your Backlog
The faster code can be written, tested and deployed the better we can plan our backlog. This gives is a more accurate insight into each story that needs to be planned and reacted upon based on changes in previous features than have been released. In addition to this, the shorter the sprint is the less the planning and grooming process needs to be.
Focus More on Product
If we can not get caught up in overplanning, infrasture and other distracting things we can focus more on developing features for the product. The faster we can get code into a live environment with an assurance and comfort level that each piece of code tested the more we can focus on the new features.
Discipline
Each member of the team and organization needs to be involved in the discpline of a continuous delivery model. This includes engineers, product, release as well as management. I believe these are all aspects of SCRUM but they need to be existant to allow this sort of delivery model to work. If you are wrapped up procedures, overhead, old mentality of releasing code it will never work. These are very generic points but a start in following some decent guidelines for continuous deployment.
Evolving article, more to come.
