Continuous Deployment (CITCON 2010)
Some brief notes from the continuous deployment discussion at Citcon Europe 2010:
- Mention of Martin Fowler’s “continuous integration page” Apparently the original idea was to go all the way through to production.
- Political limitations and compromises meant that was limited to developer-controlled part of the process.
- 2 weeks now seems like a long time to wait for a release to live.
- Granularity of change affects how quickly/easily a change can be deployed
- Is it just visual e.g. CSS change?
- Does it require a database schema change?
- Jason Huggins: “You have to be able to deal with schema migration. Or better: just do NoSQL.”
- Non-destructive schema upgrades
Google Chrome as an example of a piece of software that isn’t built in discrete releases — background downloads and updates.
Virtuous circle of removing deployment obstacles. Making deployments easier so they happen more often instead of happening rarely because they’re so painful.
- Gilad Bracha’s OOPSLA talk (Concepts from dynamic languages in applications for continuous deployment.)
- Kent Beck’s idea of “going for the longball” on the Industry Misinterpretations podcast. (Talk about continuous deployment of foundation classes and other parts of a Smalltalk system starts at 40 minutes in…)
Jez Humble, David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010, http://continuousdelivery.com/
- Blog post: “Doing the impossible 50 times a day” — Tim Fitz
How should continuous deployment affect user interaction?
- Flickr’s concept of “feature flex” for UI changes
- experiments with A-B testing for a small subset of the user population
- “the immune system” — try with user subset (Monitor usage.)
- did that user subset actually use it? (Are the users electing to use those features after the change?)
- did you break it? (Are you seeing at least some successful usages from that user subset in logs?)
- if not -> roll it back from the user subset
- concepts from IMVU
- feature not “done” until used on live
- roll back after a time if not used
- Kent Beck’s idea from the Agile Start-Ups podcast - display a “pay” button (but no payment gateway) to test demand
- can be used for documentation — to see how many users are looking for help on certain topics. Seeing how looks at which empty documentation pages can be used to prioritise documentation work.
- might need to apologise to users for lack of functionality/content though
- cost of annoying users against value of feedback data on actual demand for that feature
- Cultivating the idea that developers take an interest in a feature beyond check-in — right to live deployment and live monitoring
- Developers taking an interest in how users respond to features they’ve developed because the usual time-lag of weeks or months has gone away.
- Possibility of creating an emotional feedback loop between working on something and observing people use it for real.
- not just about developers seeing the financial success of a feature they’ve worked on:
- Killing the “it works on my machine” attitude.