Design for Continuous Deployment

What is continuous deployment? Why design for continuous deployment? How can engineers help designers think and work in this environment. An overview of how it’s done at Etsy.

Transcript

1. hello Hello
2. What is Etsy? Etsy is a commerce platform & a community where people buy direct from designers & artists who make & sell their own products.
3. 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...
4. 96% goes straight to the seller.
5. There are products made by hand or with very small scale production.
6. There are vintage and antique products.
7. There are supplies for making.
8. Etsy is more than products. It’s a community.
9. End to End I’m in the lucky position to be creative director at Etsy. I get to be the arbiter of Etsy's experience end-to-end across all channels...
10. ...out in the world...
11. ...on your phone...
12. ...and at etsy.com. I’m the design cheerleader, with a critical eye. And I make sure great design work gets done.
13. 10+ million members There’s a lot to get done. In a complex environment.
14. 800,000+ sellers
15. 11 million+ items
16. 1 billion+ page views a month
17. $600 million this year And...
18. About 140 people in Product Design & Engineering (that’s designers, product managers, engineers, and devops). We have to make that all work!
19. Design for Continuous Deployment Which brings me to the topic at hand. Design for Continuous Deployment.
20. Design for Continuous Deployment HELL YES! Which is awesome.
21. “What is he doing here?” You might be asking yourself, “why is a designer talking to room of developers about deployment?”
22. get Great Work done Return to this idea of helping great work get done.
23. How Things are Made Getting great work done means working together. And it means valuing how things are made.
24. Making Together In fact, it means Making Together. THAT is designing for continuous deployment. If our engineers practice continuous deployment, so must we. We’re building one product.
25. Designers...
26. ...and engineers...(no wait)...
27. ...and engineers working together.
28. “What is continuous deployment?” That brings us to our next question. You might be asking, “What is continuous deployment?”
29. “deployment” Release Changes “Deployment” is really just releasing changes to your product.
30. “continuous” All of the Time “Continuous” means those changes are being released all of the time.
31. Always Improve Assuming that each change is intended to be an improvement (and why wouldn’t it be?), then that means the product is always improving.
32. Frequent Boring Low-Risk 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.
33. Release Early Release Often 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.
34. Easy to Identify Easy to Fix Again, because the changes are small (and we measure what happens) problems are easier to find and easier to fix.
35. “Why design for continuous deployment?” So, you ask, “why design for continuous deployment?”
36. We’re all in this together. 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.
37. Share Early Share Often This is the collaboration counterpart to releasing early and often. You encounter problems sooner. You learn sooner. You fix sooner. This isn’t about speed, it’s about quality.
38. You sketch it out...
39. code ...make it real...
40. code ...and share it! You’ve made your design in the actual application environment. For engineers, no big deal. For designers, this is huge!
41. Empowerment, Responsibility & Trust And when you get to the point of releasing, you’re empowered and trusted to do that. (yep, designers deploy to production too)
42. People like these things. Being trusted feels good. As Kellan our CTO says, “optimize for developer happiness.” When you’re happy, you do better work.
43. Decentralize Work When everyone can access code and everyone can deploy, there’s not single bottleneck or central deployment authority.
44. Engineers Deployers 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.
45. Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov 0 10 20 30 40 50 60 70 Engineers Deployers 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.
46. Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov 0 10 20 30 40 50 60 70 15 20 23 26 30 35 42 47 49 55 58 Engineers Deployers 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.
47. Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov 0 10 20 30 40 50 60 70 15 20 23 26 30 35 42 47 49 55 58 7 8 10 15 22 26 32 50 54 57 62 Engineers Deployers 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.
48. Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov 0 10 20 30 40 50 60 70 15 20 23 26 30 35 42 47 49 55 58 7 8 10 15 22 26 32 50 54 57 62 Engineers Deployers 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.
49. Share Language Share Knowledge 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.
50. Version Control Design Assets As an added bonus. When you have designers working this way, you get version control of your design assets happening naturally. Nice!
51. “How do you do it?” Enough with the philosophy and motivational messages. “How does this work at Etsy?”
52. Tools & Process I’ll describe the tools and basic process we use on the product design team (and where we intersect with engineering).
53. Dev Environment We all have a dedicated virtual machine that serves as our development environment. They are configured as mirrors of production in almost every way.
54. Local Environment 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.
55. Quick Start Guides & Packages Along with our engineers, we’ve made quick guides to help designers get started in this environment.
56. Some engineers even made us a handy package to install. Ta- da!
57. Chat & Share
58. The whole company uses IRC to communicate.
59. 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.
60. send Local Changes to Dev Environemnt Remember those set up tools? Well there’s a handy script that auto-sends local changes to your development environment.
61. Pattern Library 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. It covers mark-up, style, and behavior.
62. 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. If we do something more than once, we patternize it.
63. Config Flags We put every feature behind config flags. They’re dead simple. They live in a few simple PHP files. These allow us to safely work in production code and only deliver designs to the right people at the right time.
64. These flags turn things on and off. They determine what environment they’re on/off in. They can determine what specific users. And they integrate with our a/b experiment framework.
65. On/Off These flags turn things on and off. They determine what environment they’re on/off in. They can determine what specific users. And they integrate with our a/b experiment framework.
66. On/Off Dev/Prod These flags turn things on and off. They determine what environment they’re on/off in. They can determine what specific users. And they integrate with our a/b experiment framework.
67. On/Off Dev/Prod Whitelist/Co./All These flags turn things on and off. They determine what environment they’re on/off in. They can determine what specific users. And they integrate with our a/b experiment framework.
68. On/Off Dev/Prod Whitelist/Co./All %A/%B These flags turn things on and off. They determine what environment they’re on/off in. They can determine what specific users. And they integrate with our a/b experiment framework.
69. URL Params We’ve implemented very simple template tags that allow us to specify URL parameters and next design states or variations inside them.
70. {% if $smarty.get.url_param == url_param_value %} a design for review {% /if %}
71. {% if $smarty.get.url_param == version-A %} a design for review {% /if %}
72. {% if $smarty.get.url_param == version-B %} another design for review {% /if %}
73. Commit & Review Before we send our changes back to master, we get code reviews from our peers.
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.
75. Test Before we send changes to master, we run functional and unit tests.
76. Push Then we push it.
77. Push it to Master in Git Wow, tech-y slide. What about merging? We merge when we pull. No 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.
78. Deploy Queue Who’s turn is it? We find out by joining the Deploy Queue. So how do you manage 100 people pushing and deploying code to production? You make them talk to each other.
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.
80. Deployinator 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.
82. It patternizes behavior.
83. It’s so easy, even our investors deploy! ;-)
84. etsy.github.com Deployinator (and several of our other home-brew tools) are open-sourced and avaliable on github.
85. Measure After we deploy, we measure, measure, measure.
86. We monitor performance immediately and over the long term. We look at business metrics immediately and over the long term. And we watch behavioral metrics and funnels using our analyzer tool.
87. Performance We monitor performance immediately and over the long term. We look at business metrics immediately and over the long term. And we watch behavioral metrics and funnels using our analyzer tool.
88. Performance Business Metrics We monitor performance immediately and over the long term. We look at business metrics immediately and over the long term. And we watch behavioral metrics and funnels using our analyzer tool.
89. Performance Business Metrics A/B Analyzer We monitor performance immediately and over the long term. We look at business metrics immediately and over the long term. And we watch behavioral metrics and funnels using our analyzer tool.
90. Repeat And we do this over and over and over again, deploying up to 50 times day.
91. “Why ‘hell yes’?” Why’s it all so exciting to designers...and engineers?
92. Simplify the Complex Working continuously, and releasing small pieces breaks complex things down into simpler things.
93. Work Closely You end up working closely together, because we use the same tools and languages. This is good.
94. Make Change Easy This makes it easier to make changes happen, and get them out in the world.
95. Make Great Work Develop a way of working that facilitates great work.
96. Make People Happy And when you make great work, the people you make it and the people who use it are better for it.
97. Make People Happy Afterall, it’s people that matter most.
98. That Is a Beautiful Thing
99. That Is an Awesome Thing If you find that as awesome as I do...
100. That Is an Awesome Thing WE’RE HIRING
101. randy@etsy.com @randyjhunt Please come talk to me.
102. Thank you so much.