Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

About me: IMVU, Canvas, Continuous Deployment)Ground rules: I don’t demand your attention, please tweet / follow links while I’m talking. If you have questions, shoot up a hand. If I don’t see you, yell at me.

ContinousDeployment vs Continuous Delivery (next slide)

Very similarContinuous Delivery is “agile as it should be”Continuous Delivery does NOT advocate for deploy-on-commit (Book and term reaction to Continuous Deployment)Continuous Deployment advocates for MORE THAN deploy-on-commit. (August 2007, 5 years old!)At the end of the day, I don’t care. People seem to be using both terms interchangeably. Whatever you call it, however far you take it, it’s better than not deploying very often.

These are the problems I get asked about all the time.No silver bullets.

In general I assume some sort of LAMP stack.

Seems straightforward, but often means what would’ve been a 1 step process (with downtime) is now a 15 step process. BUT! If you follow it well, you can always step backwards, one small step at a time, in the event that it doesn’t work out / is wrong

Sharding your data and keeping your shards balanced (and measured) means you can quantitatively assess this, especially if you keep an offline copy of a single shard.i.e. keep 100k users per shard, letting you do almost anything to any O(user) table.

Example: All metrics green, everything looks great, but got to metrics by shaming anyone who breaks build. Culture of tip-toeing through the bulid system leads to reduced happiness (and reduced throughput!)Sidenote: Measure throughput! Deploys per engineer (avg/median/extremes), is it scaling up with org or are you getting less deploys?

6.
Schema rev. N, N+1 compatible• Add the column in production• Push the code that writes to that column• Optionally, run a data migration to populate the existing rows with data• Push the code that reads from that column.

7.
Apply only cheap changes• Only apply changes that are cheap enough to not affect live traffic• More complex changes split into tiny steps: – Create new table – Write to both – Cut over eventually – Drop old table

24.
How do you make tests fast?• Tests can exercise large amounts of code without being slow• Minimize system calls (no I/O, no disk)• Minimize test data size• Make sure all systems are cheap to instantiate/teardown• No external state makes tests more reliable

29.
Single trunk• Do this until it doesn’t work for you• Gets painful in the 16 – 32 developer range• Faster commit->deploy reduces the pain – But effort becomes prohibitive

30.
“Try” pipeline• Conceptually, a second tree that “doesn’t matter” but still gets tested for feedback• Buildbot implements a patch-pushing version• Takes a significant amount of pressure off of trunk builds

32.
Feature branches• All incremental development happens on branches, branches land when feature is “ready”• If “feature” is kept small, can be 2-3 per engineer per week on average• Less continuous, but scales much better – Feature branches tested before merge