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.)
  • Youtube version of this talk
• 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

Developer Attitude

• 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.