Saturday, October 6, 2012
Please implement the following at your nearest software development company:
- make stories sequentially deployable
- architect for continous delivery
- create small units
- let each component access only its own data and otherwise call other components' APIs
- share services/infrastructure (leads to low impact deployments)
- design for continous delivery
- make it easy to release
- make it easy to change
- make it easy to deploy
- reduce risk of deployment
- leave the system always runnable
- manage 'traffic':
-- fast lane for weekly releases
-- slow lane for less frequent releases, using feature switches and dark launches
- use feature switches
- branch by abstraction = branch in code (not in version control)
- test for continous delivery
- create predictable tests
- run system on development environment
- acceptance-test in non-integrated environment
- integrate with main line every day
- keep short build times
- script to rebuild environment from scratch (phoenix environments)
- parallelize builds
- split builds from deployments
- use a configuration server
- use a package repository
Deployment (of code changes):
- deploy in small steps
- make non-breaking database expansions
- separate deployment from release
- use blue-green deployment
- run smoke tests
- use canary releases
Release (of a feature):
- flip a feature flag
- launch in the dark
- split test
- let developers follow product into production
- monitor and study usage in production
- data mine and analyse feedback
- get real user feedback
- allow everyone fast feedback on effect of change
- deploy daily
- release when features are done
- create a 'devops' mentality
- keep the software releasable on-demand
- remember that the delivery process is never perfect
- measure improvements
- create intermediate goals
- take small steps towards continous delivery
- automate what you're doing manually
- get measurable change fast, even if goal takes years
- how many lines of code gets deployed per week?
- how long does it take from feature development is 'dev done' to it reaches production?
- how long after deployment does it take to discover new errors?
- how many man-hours does it take to quality-assure before each deployment?
- how many man-hours does it take to sign-off each deployment?
- how many man-hours does it take to deploy per week?
- how many manual steps are involved in a deployment?
Thanks to Sam Newman, Josh Graham, Michael Nygard, Mike Brittain and Jez Humble at GOTO Århus 2012.
Submitted by Ole Lynge Sørensen at 22:08