Downloaded 30 times
Uploaded by500 Startups
Randy Hunt, Etsy - Warm Gun Conference
This document discusses continuous deployment and how to design systems for continuous deployment. It advocates for frequent, low-risk releases by empowering engineers and decentralizing work. Tools and processes like version control, configuration flags, and performance measurement are recommended to enable engineers to easily and safely deploy changes. The overall message is that continuous deployment can simplify complex work, enable great work, and make people happy by facilitating ongoing improvements.
More Related Content
Similar to Randy Hunt, Etsy - Warm Gun Conference
Randy Hunt, Etsy - Warm Gun Conference
- 2.
- 10.
- 14. 10+ million members
- 15.
- 16. 11 million+ items
- 17. 1 billion+ page viewsa month
- 18. $600 million this year
- 20. Design for Continuous Deployment
- 21. HELL Design for YES! Continuous Deployment
- 22. “What is he doing here?”
- 23.
- 24.
- 25.
- 29. “What is continuous deployment?”
- 30.
- 31.
- 32.
- 33.
- 34.
- 35. Easy to Identify Easy to Fix
- 36. “Why design for continuous deployment?”
- 37. We’re all in thistogether.
- 38.
- 40.
- 41.
- 42. Empowerment, Responsibility & Trust
- 44. Decentralize Work
- 45. Engineers Deployers
- 46. Engineers Deployers 70 60 50 40 30 20 10 0 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
- 47. Engineers Deployers 70 60 58 55 50 49 47 40 42 35 30 30 26 20 23 20 15 10 0 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
- 48. Engineers Deployers 70 62 60 57 58 54 55 50 50 49 47 40 42 35 32 30 30 26 26 22 20 23 20 15 15 10 10 7 8 0 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
- 49. Engineers Deployers 70 62 60 57 58 54 55 50 50 49 47 40 42 35 32 30 30 26 26 22 20 23 20 15 15 10 10 7 8 0 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
- 50.
- 51. Version Control DesignAssets
- 52. “How do youdo it?”
- 53.
- 54.
- 55.
- 56. Quick Start Guides & Packages
- 58.
- 61. send Local Changes to Dev Environemnt
- 62.
- 64.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71. {% if $smarty.get.url_param== url_param_value %} a design for review {% /if %}
- 72. {% if $smarty.get.url_param== version-A %} a design for review {% /if %}
- 73. {% if $smarty.get.url_param== version-B %} another design for review {% /if %}
- 74.
- 76.
- 77.
- 78. Push it to Masterin Git
- 79.
- 81.
- 85.
- 86.
- 88.
- 89.
- 90. Performance Business Metrics A/BAnalyzer
- 91.
- 92.
- 93. Simplify the Complex
- 94.
- 95.
- 96.
- 97.
- 98.
- 99. That Is a Beautiful Thing
- 100. That Is an Awesome Thing
- 101. WE’RE ThatIs an HIRING Awesome Thing
- 102.
Editor's Notes
- #2 Hello\n
- #3 Hello\n
- #4 What is Etsy?\nEtsy is a commerce platform & a community where people buy direct from designers & artists who make & sell their own products.\n
- #5 Any creative person can open a shop, list items, receive and fulfill orders, promote themselves, connect with other people, curate collections of items, watch site activity...\n
- #6 96% goes straight to the seller.\n
- #7 There are products made by hand or with very small scale production.\n
- #8 There are vintage and antique products.\n
- #9 There are supplies for making.\n
- #10 Etsy is more than products. It’s a community.\n
- #11 I’m in the lucky position to be creative director at Etsy.\nI get to be the arbiter of Etsy's experience end-to-end across all channels...\n
- #12 ...out in the world...\n
- #13 ...on your phone...\n
- #14 ...and at etsy.com. I’m the design cheerleader, with a critical eye. And I make sure great design work gets done.\n
- #15 There’s a lot to get done. In a complex environment.\n
- #16 \n
- #17 \n
- #18 \n
- #19 And...\n
- #20 About 140 people in Product Design & Engineering\n(that’s designers, product managers, engineers, and devops).\nWe have to make that all work!\n
- #21 Which brings me to the topic at hand. Design for Continuous Deployment.\n
- #22 Which is awesome.\n
- #23 You might be asking yourself, “why is a designer talking to room of developers about deployment?”\n
- #24 Return to this idea of helpinggreat work get done.\n
- #25 Getting great work done means working together.\nAnd it means valuing how things are made.\n
- #26 In fact, it means Making Together.\nTHAT is designing for continuous deployment.\nIf our engineers practice continuous deployment, so must we. We’re building one product.\n
- #27 Designers...\n
- #28 ...and engineers...(no wait)...\n
- #29 ...and engineers working together.\n
- #30 That brings us to our next question. You might be asking, \n“What is continuous deployment?”\n
- #31 “Deployment” is really just releasing changes to your product.\n
- #32 “Continuous” means those changes are being released all of the time.\n
- #33 Assuming that each change is intended to be an improvement (and why wouldn’t it be?), then that means the product is always improving.\n
- #34 These changes happen often, they’re trivial, and because they’re small, they should be low risk. This is really the philosophy of continuous deployment.\n
- #35 This is saying frequency another way: a catchy way. This is how you say it if you want to remind someone they haven’t released small enought or frequently enough.\n
- #36 Again, because the changes are small (and we measure what happens) problems are easier to find and easier to fix.\n
- #37 So, you ask, “why design for continuous deployment?”\n
- #38 Well, we’re working together building one product, so we should work similarly. Design doesn’t get left behind in a powerful engineering culture. In fact, design can scale and be more fluid when it’s close to engineering.\n
- #39 This is the collaboration counterpart to releasing early and often. You encounter problems sooner. You learn sooner. You fix sooner.\nThis isn’t about speed, it’s about quality.\n
- #40 You sketch it out...\n
- #41 ...make it real...\n
- #42 ...and share it!\nYou’ve made your design in the actual application environment. For engineers, no big deal. For designers, this is huge!\n
- #43 And when you get to the point of releasing, you’re empowered and trusted to do that. (yep, designers deploy to production too)\n
- #44 People like these things. Being trusted feels good.\nAs Kellan our CTO says, “optimize for developer happiness.”\nWhen you’re happy, you do better work.\n
- #45 When everyone can access code and everyone can deploy, there’s not single bottleneck or central deployment authority.\n
- #46 Here we can see the moment in 2010 when the number of people deploying to production surpassed the number of engineers on staff. This is good.\n
- #47 Here we can see the moment in 2010 when the number of people deploying to production surpassed the number of engineers on staff. This is good.\n
- #48 Here we can see the moment in 2010 when the number of people deploying to production surpassed the number of engineers on staff. This is good.\n
- #49 Here we can see the moment in 2010 when the number of people deploying to production surpassed the number of engineers on staff. This is good.\n
- #50 When designers and engineers work in the same environment, they share a language. This makes is easier to share knowledge. It also means you sympathize more with each other’s motivations and challenges.\n
- #51 As an added bonus. When you have designers working this way, you get version control of your design assets happening naturally. Nice!\n
- #52 Enough with the philosophy and motivational messages.\n“How does this work at Etsy?”\n
- #53 I’ll describe the tools and basic process we use on the product design team (and where we intersect with engineering).\n
- #54 We all have a dedicated virtual machine that serves as our development environment. They are configured as mirrors of production in almost every way.\n
- #55 And we all work locally on our Macs. This is like some engineers, but not most of them. Most of them like to work in their development environment directly. Us designers don’t like things like Vim.\n
- #56 Along with our engineers, we’ve made quick guides to help designers get started in this environment.\n
- #57 Some engineers even made us a handy package to install. Ta-da!\n
- #58 \n
- #59 The whole company uses IRC to communicate.\n
- #60 The product design team also uses Campfire (and the Propane client) to share visual designs in conversation as well. We’ll post links to dev environments, as well as still and motion screen captures.\n
- #61 Remember those set up tools? Well there’s a handy script that auto-sends local changes to your development environment.\n
- #62 We’ve built a design Pattern Library. It allows us to quickly get designs roughed. Don’t duplicate efforts. Be more consistent throughout the product.\n\nIt covers mark-up, style, and behavior.\n
- #63 This doesn’t solve everything, every time, but a patterns solves many things many times. Makes it easy to get started. Helps share design decisions between designers and with engineers.\n\nIf we do something more than once, we patternize it.\n
- #64 We put every feature behind config flags. They’re dead simple. They live in a few simple PHP files.\n\nThese allow us to safely work in production code and only deliver designs to the right people at the right time.\n
- #65 These flags turn things on and off.\nThey determine what environment they’re on/off in.\nThey can determine what specific users.\nAnd they integrate with our a/b experiment framework.\n
- #66 These flags turn things on and off.\nThey determine what environment they’re on/off in.\nThey can determine what specific users.\nAnd they integrate with our a/b experiment framework.\n
- #67 These flags turn things on and off.\nThey determine what environment they’re on/off in.\nThey can determine what specific users.\nAnd they integrate with our a/b experiment framework.\n
- #68 These flags turn things on and off.\nThey determine what environment they’re on/off in.\nThey can determine what specific users.\nAnd they integrate with our a/b experiment framework.\n
- #69 We’ve implemented very simple template tags that allow us to specify URL parameters and next design states or variations inside them.\n
- #70 \n
- #71 \n
- #72 \n
- #73 Before we send our changes back to master, we get code reviews from our peers.\n
- #74 We use Crucible or Github or really anything you’d like to use to do a code review. The important thing is that we check our work. Designers can learn a ton from engineers in this step.\n
- #75 Before we send changes to master, we run functional and unit tests.\n
- #76 Then we push it.\n
- #77 Wow, tech-y slide.\nWhat about merging? We merge when we pull.\nNo branches. We only “branch in code” using the config flags. That saves us from any annoying merging issues and keeps everyone accountable. It’s also just simple and easy to understand.\n
- #78 Who’s turn is it? We find out by joining the Deploy Queue.\nSo how do you manage 100 people pushing and deploying code to production? You make them talk to each other.\n
- #79 That’s right, IRC. There’s a special IRC room just for Pushes. There’s a little bot that helps you be polite, but the only policy enforcement is self enforcement. We respect the system and respect our peers.\n
- #80 When the queueu says it’s okay to deploy, we turn to our tool, Deployinator. It’s a dashboard and simple UI for 1-button deploys.\n
- #81 \n
- #82 It patternizes behavior.\n
- #83 It’s so easy, even our investors deploy! ;-)\n
- #84 Deployinator (and several of our other home-brew tools) are open-sourced and avaliable on github.\n
- #85 After we deploy, we measure, measure, measure.\n
- #86 We monitor performance immediately and over the long term.\nWe look at business metrics immediately and over the long term.\nAnd we watch behavioral metrics and funnels using our analyzer tool.\n
- #87 We monitor performance immediately and over the long term.\nWe look at business metrics immediately and over the long term.\nAnd we watch behavioral metrics and funnels using our analyzer tool.\n
- #88 We monitor performance immediately and over the long term.\nWe look at business metrics immediately and over the long term.\nAnd we watch behavioral metrics and funnels using our analyzer tool.\n
- #89 And we do this over and over and over again, deploying up to 50 times day.\n
- #90 Why’s it all so exciting to designers...and engineers?\n
- #91 Working continuously, and releasing small pieces breaks complex things down into simpler things.\n
- #92 You end up working closely together, because we use the same tools and languages. This is good.\n
- #93 This makes it easier to make changes happen, and get them out in the world.\n
- #94 Develop a way of working that facilitates great work.\n
- #95 And when you make great work, the people you make it and the people who use it are better for it.\n
- #96 Afterall, it’s people that matter most.\n
- #97 \n
- #98 If you find that as awesome as I do...\n\n
- #99 \n
- #100 Please come talk to me.\n\n
- #101 Thank you so much.\n\n