Etsy is a community-driven commerce platform where creative individuals sell their handmade, vintage, and craft supply items, with 96% of sales going directly to the sellers. The presentation discusses the significance of continuous deployment, emphasizing collaboration between designers and engineers to enhance product quality and streamline the design process. It highlights the tools and practices at Etsy that facilitate efficient deployment and constant product improvement, fostering a culture of empowerment and trust among team members.

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. HELL Design
for
YES!
Continuous
Deployment
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. Engineers Deployers
70
60
50
40
30
20
10
0
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
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. 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
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. 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
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. 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
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. WE’RE
That Is
an
HIRING
Awesome
Thing

101. randy@etsy.com
@randyjhunt
Please come talk to me.

102. Thank you so much.