�ݺ�ߣ

What is Etsy?
Etsy is a commerce platform & a community where people buy
direct from designers & artists who make & sell their own
products.

Any creative person can open a shop, list items, receive and
fulﬁll orders, promote themselves, connect with other people,
curate collections of items, watch site activity...

96% goes straight to the seller.

There are products made by hand or with very small scale
production.

There are vintage and antique products.

There are supplies for making.

Etsy is more than products. It’s a community.

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...

...and at etsy.com. I’m the design cheerleader, with a critical
eye. And I make sure great design work gets done.

10+ million
members

There’s a lot to get done. In a complex environment.

$600 million
this year

And...

About 140 people in Product Design & Engineering
(that’s designers, product managers, engineers, and devops).
We have to make that all work!

Design
for
Continuous
Deployment

Which brings me to the topic at hand. Design for Continuous
Deployment.

HELL Design
for

YES!
Continuous
Deployment

Which is awesome.

“What is he
doing here?”

You might be asking yourself, “why is a designer talking to
room of developers about deployment?”

get
Great
Work
done

Return to this idea of helping
great work get done.

How
Things
are
Made

Getting great work done means working together.
And it means valuing how things are made.

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.

...and engineers...(no wait)...

...and engineers working together.

“What is
continuous
deployment?”

That brings us to our next question. You might be asking,
“What is continuous deployment?”

“d��ǲ⳾��Գ�”

Release Changes

“Deployment” is really just releasing changes to your product.

“c�ǲԳپ��Գܴǳܲ�”

All of the Time

“Continuous” means those changes are being released all of
the time.

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.

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.

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.

Easy to Identify

Easy to Fix

Again, because the changes are small (and we measure what
happens) problems are easier to ﬁnd and easier to ﬁx.

“Why design for
continuous
deployment?”

So, you ask, “why design for continuous deployment?”

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 ﬂuid when it’s close to engineering.

Share Early

Share Often

This is the collaboration counterpart to releasing early and
often. You encounter problems sooner. You learn sooner. You
ﬁx sooner.
This isn’t about speed, it’s about quality.

code

...and share it!
You’ve made your design in the actual application
environment. For engineers, no big deal. For designers, this is
huge!

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)

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.

Decentralize
Work

When everyone can access code and everyone can deploy,
there’s not single bottleneck or central deployment authority.

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.

Engineers Deployers
70

60

50

40

30

20

10

0
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov


Engineers Deployers
70

60
58
55
50
49
47
40 42

35
30
30
26
20 23
20
15
10

0


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


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.

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!

“How do you do it?”

Enough with the philosophy and motivational messages.
“How does this work at Etsy?”

Tools
&
Process

I’ll describe the tools and basic process we use on the product
design team (and where we intersect with engineering).

Dev Environment

We all have a dedicated virtual machine that serves as our
development environment. They are conﬁgured as mirrors of
production in almost every way.

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.

Quick Start Guides
&
Packages

Along with our engineers, we’ve made quick guides to help
designers get started in this environment.

Some engineers even made us a handy package to install. Ta-
da!

The whole company uses IRC to communicate.

The product design team also uses Campﬁre (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.

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.

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.

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.

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.

These ﬂags turn things on and off.
They determine what environment they’re on/off in.
They can determine what speciﬁc users.
And they integrate with our a/b experiment framework.

On/Off


On/Off
Dev/Prod


On/Off
Dev/Prod
Whitelist/Co./All


On/Off
Dev/Prod
Whitelist/Co./All
%A/%B


URL Params

We’ve implemented very simple template tags that allow us to
specify URL parameters and next design states or variations
inside them.

{% if $smarty.get.url_param ==
url_param_value %}

a design for review
{% /if %}

version-A %}

a design for review
{% /if %}

version-B %}

another design for review
{% /if %}

Commit & Review

Before we send our changes back to master, we get code
reviews from our peers.

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.

Test

Before we send changes to master, we run functional and unit
tests.

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 conﬁg ﬂags.
That saves us from any annoying merging issues and keeps
everyone accountable. It’s also just simple and easy to
understand.

Deploy Queue

Who’s turn is it? We ﬁnd 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.

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.

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.

Design For Continuous Deployment

It’s so easy, even our investors deploy! ;-)

etsy.github.com

Deployinator (and several of our other home-brew tools) are
open-sourced and avaliable on github.

Measure

After we deploy, we measure, measure, measure.

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.

Performance

term.
analyzer tool.

Performance
Business Metrics

term.
analyzer tool.

Performance
Business Metrics
A/B Analyzer

term.
analyzer tool.

Repeat

And we do this over and over and over again, deploying up to
50 times day.

“Why ‘hell yes’?”

Why’s it all so exciting to designers...and engineers?

Simplify
the
Complex

Working continuously, and releasing small pieces breaks
complex things down into simpler things.

Work Closely

You end up working closely together, because we use the
same tools and languages. This is good.

Make Change Easy

This makes it easier to make changes happen, and get them
out in the world.

Make Great Work

Develop a way of working that facilitates great work.

Make People Happy

And when you make great work, the people you make it and
the people who use it are better for it.

Make People Happy

Afterall, it’s people that matter most.

That Is
a
Beautiful
Thing

That Is
an
Awesome
Thing

If you ﬁnd that as awesome as I do...

WE’RE
That Is
an

HIRING
Awesome
Thing

randy@etsy.com
@randyjhunt

Please come talk to me.

�ݺ�ߣ

Design For Continuous Deployment

Recommended

More Related Content

Similar to Design For Continuous Deployment (20)

Recently uploaded (20)

Design For Continuous Deployment