What? Why? Tailor for unique tradeoffs, focusing on risk mitigation.Trans: what is cd? What is CI?
Incremental logical step. Coined the term, didn’t invent the concept.(IMVU took it to the next level, but others were doing very similar things before IMVU existed)
Ancient concept:Expect it on local dev boxes (php-style)SqueakGenera : An entire OS, locally deployable instantly. Musical Live CodingTrans: So… why?
Story? System Chat. Threw away a week of work! Dark launch via CD.Bad Assumptions: Code does what it says Code doesn’t negatively affect other code Code is scalable Code handles edge cases correctly 3rd party API allows for certain behavior
“Continuous Deployment” coined August 2007, 20k google hits (phrase is only 4 years old)Feb 2009: Blog post lands
Where we were: 2008Handful of companiesZero documentationNo common languageWhat changed?Pattern got a name.People started talking about it.
Talk through commit deploy processGit pushGithubPing JenkinsJenkins runs python ./manage.py test canvasRuns through a couple hundred automated tests
Does it scale?IMVU: Profitable MMO + Virtual Economy, 50 person technical staffCommit-to-live in about 15 minutes.Massive cluster, massive parallelism. Extensive stats tracking.
“Gregory House Theory”Not a theory of CDWaterfallApply the theory on a per-change basis (schemas vsTrans: How to change that curve?
Hypothesis commits: What happens if I X?Pay attention to your S/N ratio. Refactoring in separate commits to pull out noise. (Behavior preserving? Behavior changing?)
Bank that IVLots of “Lean Startup” and “Lean Thinking” benefits, covered elsewhere.
Flickr switchesChrome dev-channel crashes constantly, but I still love it. (WebGL!)Google Labs
Website is down! Write tests.“Install the client” test, fear barrier.
Nagios alerts are an extension of test coverage.Cluster Immune is a hedge against the cost of big regressions. Does a subset of Nagios alerts with finely tuned parameters.Instant rollback (<15s) is so critical. Human processes (how do I do it? Who does it? What’s a serious regression?)Just go read “Release It!” – Michael NygardCan’t take out a MySQL instance with a bad queryApp works even if search is downIsolation: Think AppEngine.Schemas: Lock down. Review. Try to avoid. Key-value store (NoSQL or YesSQL)
Schema changes are high friction; they’re often slow and expensive to deploy: most data stores fight the natural order of Continuous Deployment: small discrete schema changes.Everyone has established practices, patterns and unique situations given choice of database, Code works with schema v0 and v1 (i.e. adding a new row; code explicitly selects the columns it wants and ignores new row)Means you can always step the code and the database back (potentially multiple times, but that takes many steps)
Schema changes are computationally expensive and risky
Nike method: Just do itHot tub method: Ease into itNuclear option: quit your day job (amazon: switch teams)(Last one’s mostly a joke, but f you look at how the growth of agile methodologies: successful projects and dev environments attract talent; talent came from somewhere!)
Putting it all together, examples:Web Startup: forget riskEstablished Service: velocity IMVU“Big Business”: CD to opt-in customers, daily deploy of baked functionality.Medical: CD to test-environment.Principles apply everywhere.
Continuous Deployment Timothy Fitz CTO of Canvas
“Continuous integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce timely rework and thus reduce cost and development time.”
“Continuous deployment involves deploying early and often, so as to avoid the pitfalls of "deployment hell". The practice aims to reduce timely rework and thus reduce cost and development time.”
The Vision On every key press Compile Run automated tests Deploy
Deploying code validates assumptions
Bad assumptions cause waste Code built on top is waste Designbuilt on top is waste Thought built on top is waste
The Reality Change has risk Infrastructure isn’t free
Decrease Exposure Dark launch non-frontend changes Controlled exposure via feature rollout code Expose to staff/QA only Expose to opt-in beta testers Gradually increase exposure from 1-100% Feature-level rollback
Decrease Probability Automated tests Regression / Functional / Integration tests Unit tests Browser tests / Click tests 3rd party integration tests Manual QA prior to exposing features Build code in a deploy mindset
Decrease Severity Decrease length of degradation Production Alerts
Decrease effects of degradation Stability through isolation Product level fault tolerance Lock down core infrastructure
FAQ Whatabout shema changes? Great, how do I get started?
Schema Changes: They hate your code Code and schema move in locked steps Favor schemaless design Minimize classical schema changes Offend DBAs with your lack of normalization Lightweight/Schemaless databases(“nosql”)
Schema Changes: They hate your uptime Did I mention schemalessdatabases yet? Apply updates to standbys Blue/Green cluster setup
Great, how do I get started? Nike method: Just do it
tl;dr We’ve come a long way We have a long way to go IV + DV > Exposure * Probability * Severity. Rethink schema changes Continous Deployment: Just do it Questions?