►
Description
Presented by Dylan Vassallo, Stripe.
Stripe recently moved 600 repos from GitHub to GitHub Enterprise with (almost) no disruption to our internal users. We considered declaring a “git holiday” for this, but even one day of downtime would have been unacceptable and we needed to be able to roll back quickly if something went wrong. We instead developed an incremental and reversible plan that made it possible for us to perform a nearly-seamless online migration. In this talk I’ll explain our approach to risky infrastructure changes like this one and share some specific learnings from our GitHub Enterprise project.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
My
name
is
Dylan
and
I'm.
An
engineer
at
stripe
and
stripe
is
a
software
platform
for
building
and
running
an
online
business,
and
today
I'm,
going
to
tell
you
about
our
project
for
migrating
600,
private
repositories
from
github
com
to
get
up
enterprise,
and
we
did
this
in
a
way
that
was
pretty
seamless
for
our
internal
customers
as
well
as
fairly
painless
for
us
on
the
migration
team
as
well,
and
we
did
this
by
leveraging
techniques
that
stripe
is
used
for
a
long
time
for
making
big
under
the
hood
changes
without
too
much
end-user
disruption.
A
The
preparation
work
we
had
to
put
in
to
be
able
to
execute
on
that
plan
in
production
and
how
our
production
migration
actually
went.
So
stripe
uses
github
in
a
lot
of
ways.
Just
like
you.
We
use
github
as
part
of
a
broader
development
productivity
tool
chain
that
allows
us
to
deliver
software
that
processes
over
a
hundred
million
API
requests
per
day
and
billions
of
dollars
per
year.
A
Now,
because
stripe
is
a
global
company
operating
global
economic
infrastructure,
there's
no
good
time
for
us
to
just
take
this
down
when
we
need
to
make
changes
to
it.
Imagine,
for
example,
that
you
couldn't
get
a
lift
home
from
the
conference
today,
because
stripe
was
down.
I
know
I,
wouldn't
be
very
happy
about
that,
and
because
we're
a
global
company
working
on
this
infrastructure
all
the
time
we
have
similar
availability
expectations
for
our
developer
tools
as
well.
A
Stripe
has
over
600
private
git
repositories
over
550
people
at
stripe,
actively
use
github
in
one
way
or
another,
and
at
our
peak
we've
pushed
up
to
200
requests
per
second
to
github.
Now
this
includes
HTTP
and
SSH
transactions,
and
a
lot
of
it
comes
from
our
build
system,
as
well
as
a
pretty
tight
integration
that
we
built
on
top
of
pull
requests
to
implement
our
own
code
review
flow.
A
A
There
were
many
reasons
for
us
to
move
together
of
enterprise,
but
the
main
one
is
that
we
wanted
to
run
an
instance
of
it
within
our
Amazon
Web,
Services
Network,
so
that
we
could
host
our
source
code
within
our
private
network
and,
as
you
might
expect,
we
kicked
off
this
project
by
defining
our
requirements.
The
things
that
would
have
to
be
true
for
us
to
consider
this
project
a
success.
A
So
we
wanted
to
move
all
of
our
users
and
all
of
our
private
repositories
over
to
github
enterprise,
and
we
didn't
want
to
impact
Incident
Response
in
any
way.
So
you
can
imagine
that
maybe
we
were
exporting
all
these
repositories
and
then
importing
them
and
then
maybe
reconfiguring
our
systems
to
talk
to
github
enterprise
where
they
used
to
talk
to
github.com
and
at
any
point
in
this
process,
some
unrelated
production
incident
could
occur
and
we
weren't
able
to
say
sorry.
A
You
can't
deal
with
this
production
incident
because
we're
working
on
github
that
just
wasn't
an
option
for
us
and
we
didn't
want
to
disrupt
developer
productivity
either
either
during
or
after
the
migration
and
I'm
gonna
dig
into
this
one.
A
little
bit
more
because
there's
a
lot
to
it,
so
what
does
it
mean
to
protect
productivity
during
a
migration
like
this?
A
Well,
the
first
consideration
we
had
to
make
was
around
repository
unavailability,
and
this
is
because
we
decided
that
we
would
restrict
access
to
our
repositories
on
github
calm
before
copying
them
over
to
get
up
enterprise.
In
order
to
ensure
data
consistency,
we
basically
wanted
to
ensure
that
no
one
would
be
making
changes
to
the
github
comm
copy
once
we
had
already
started
moving
it
over
to
get
up
enterprise.
A
A
Another
part
of
protecting
productivity
is
just
keeping
everything
working
after
the
migration
once
we
were
fully
on
github
Enterprise,
so
we
needed
confidence
that
all
of
our
core
development
workflows
would
continue
to
work
just
like
they
did
before
so.
I'm.
Writing
some
code.
I
push
a
branch
to
github.
Our
continuous
integration
system
runs
a
build
I.
Look
at
my
test
results.
Maybe
I
ate
some
more
I
open.
A
pull
request.
Do
code
review
merge
that
deploy
it
with
a
deploy
system.
A
So
you
may
be
familiar
with
this
quote
that
says
that
any
complex
working
system
evolved
from
a
simple
working
system,
and
this
has
served
me
pretty
well
throughout
my
engineering
career,
and
this
is
where
we
started
for
a
github
enterprise
project
as
well.
We
thought
what
is
the
simplest
possible
plan,
the
most
straightforward
plan
we
can
think
of
that
will
get
all
of
our
repositories
moved
over,
and
this
is
what
we
came
up
with.
A
A
A
A
A
Things
like
adding
new
payment
methods
or
enabling
new
business
models
or
rewriting
our
PCI
infrastructure
from
Ruby
to
go,
or
even
moving.
All
of
our
servers
from
a
data
center
in
Northern
California
to
a
data
center
in
Oregon
we
figured
if
a
team
at
stripe
could
move
all
of
our
servers
to
a
new
data
center
and
have
stripe
stay
up.
We
could
probably
change
this
one
little
internal
piece
of
stripe
and
have
that
go
okay
and
what
all
of
these
changes
had
in
common
is
that
they
weren't
actually
big
changes.
A
They
were
a
bunch
of
small
changes
so,
instead
of
having
one
big
risky
change,
those
teams
broke
that
change
down
into
a
bunch
of
smaller
ones
that
they
could
apply
at
their
own
pace
so
that
they
would
apply
each
change
and
then
only
proceed
to
the
next
one.
Once
they
had
verified
that
that
smaller
incremental
change
had
worked,
and
if
it
didn't
work,
they
would
just
roll
it
back,
and
this
incremental
migration
pattern
seemed
like
something
we
really
wanted
to
be
able
to
try
for
our
github
Enterprise
migration.
A
So,
in
order
to
develop
an
incremental
migration
plan,
we
had
to
answer
a
few
questions.
First.
The
first
question
is:
what
are
our
increments,
so
moving
incrementally
means
moving
piece
by
piece.
What
are
those
pieces
going
to
be
where
we
going
to
move
some
teams
over
at
a
time?
Some
repositories
are
over.
At
a
time
we
weren't
sure
we
had
to
figure
that
out.
We
also
had
to
know
if
we
could
undo
any
of
these
increments
if
necessary,
so
that
we
could
roll
back
and
always
be
in
a
known
good
State.
A
And
then
how
is
everything
going
to
work
during
this
transitional
phase,
where
we
had
some
repositories
and
some
users
on
github.com
and
some
repositories
and
some
users
moved
over
to
get
up
enterprise?
And
we
knew
we
didn't
want
to
be
in
this
to
github
world
for
too
long,
because
having
everyone
have
to
use
to
github.
Just
has
more
cognitive
overhead
than
using
one.
But
we
wanted
to
be
in
that
face
for
long
enough
so
that
we
could
sort
of
gradually
build
confidence
in
our
ability
to
run,
get
AB
enterprising
and
have
that
work
for
everyone.
A
So,
to
enter
the
first
question,
what
our
unit
of
migration
was
going
to
be.
It
made
a
lot
of
sense
for
us
to
choose
repositories.
So
this
is
the
github
API
endpoint
for
starting
a
migration,
and
you
basically
just
give
it
a
list
of
repositories
that
you
own
and
then
github
will
kick
off
an
asynchronous
job
to
export
those
for
you.
But
we
didn't
want
to
export
all
600
of
our
repositories
at
once,
because
that
wouldn't
be
very
incremental.
A
A
So
this
is
a
graph
of
our
repositories
on
the
x-axis
and
then
the
y-axis
is
the
y-axis
is
how
many
recent
commits
that
repository
has
seen,
which
is
a
pretty
good
proxy
for
just
how
active
that
repository
is
at
stripe
and
you
can
see
towards
the
bottom
there.
There
are
a
whole
bunch
of
repositories
that
have
had
no
recent
activity.
A
Basically,
no
one
was
touching
them,
and
so
we
figured
those
were
probably
going
to
be
the
least
risky
to
move
so
could
start
with
those,
and
if
we
mess
that
up,
that
probably
wouldn't
be
as
much
of
a
big
deal
as
if
we
messed
up
some
of
these
ones
towards
the
top
that
had
a
lot
of
activity
happening
on
them,
and
this
becomes
a
lot
more
apparent
when
you
reorder
these
by
the
number
of
commits
activity.
So
these
are
the
phases
that
we
ended
up
with.
A
We
were
going
to
start
with
a
single
canary
repository.
This
is
a
repository
that
my
team
was
working
in
every
single
day,
but
not
many
other
people
at
stripe
were
using,
and
this
would
get
ass
dog
fooding
github
enterprise
very
early
on
in
production
and
allow
us
to
quickly
suss
out
any
very
glaring
problems
that
we'd
have
to
fix
before
we
would
expose
the
rest
of
the
company
to
them.
A
Then
there
were
about
50
that
were
pretty
business
critical
to
us
and
also
just
had
a
lot
of
people
working
on
them.
So
we've
moved
those
toward
the
ends,
because
we
wanted
to
have
more
confidence
that
we
could
move
those
correctly
on
the
first
try
and
then
there's
our
mono
repo,
the
single
largest
most
important,
most
critical.
Most
everything
repository
to
strike.
This
one
was
really
important
and
we
really
needed
to
get
that
migration
right.
So
we
saved
that
one
toward
the
end.
A
A
Well,
I
mentioned
at
the
start
that
we
chose
to
restrict
access
to
our
repositories
on
the
github
comp
side
in
order
to
ensure
data
consistency
before
maegyr
than
them
migrating
them
over,
and
we
were
able
to
do
this
using
a
boolean
parameter
in
the
ghetto
migration.
Api
called
lock
repositories,
and
this
is
what
a
locked
repository
looks
like,
as
you
can
tell
you
can't
change
the
repository
or
modify
it
in
any
way
from
the
web
interface,
and
you
also
can't
modify
it
through
gates
or
through
the
API.
A
So
this
is
a
really
effective
way
to
make
sure
that
no
one
is
going
to
make
changes
to
this
repository
and
then,
as
you
might
expect,
there's
a
corresponding
API
endpoint
for
unlocking
a
repository.
So
normally
the
way
you
would
use
this
is
that
you've
locked
the
repositories
on
the
github,
comm
side
export,
then
import
them
and
then
unlock
them
on
the
github
enterprise
side.
A
But
this
unlock
API
endpoint
actually
turned
out
to
be
our
key
to
a
quick
roll
back
as
well,
because
what
we
would
do
is
if
we
were
migrating
a
batch
of
locked
repositories.
If
anyone
urgently
came
to
us
and
said
hey,
I
really
need
to
push
a
fix,
I
really
need
to
access
this
repository.
All
we
would
have
to
do
is
issue.
A
The
way
we
chose
to
handle
this
is
by
keeping
state
of
the
exact
migration
status
of
all
of
our
repositories
in
a
single
configuration
file
that
we
called
migrated
AML,
and
we
kept
this
in
a
git
repository
itself,
so
that
we
could
track
changes
to
it.
Just
like
you
would
collaborate
on
any
file
in
any
kit
repository.
A
So
in
this
example,
I
am
committing
a
change
to
change
the
llama
repository
from
false
to
true
indicating
that
we
moved
it
over
to
get
AB
Enterprise
and
that's
where
it's
new
home
is-
and
this
is
great
because
we
could
collaborate
it
on
it
as
a
team
and
all
sort
of
know
exactly
what
was
going
on
with
our
repositories.
But
we
were
also
able
to
use
the
github
API
to
have
all
of
our
services
read
from
that
file
as
well,
so
that
they
would
know
where
to
dispatch,
API
requests
and
that
works
out
pretty
well.
A
A
We
would
achieve
this
sort
of
controlled
turn
up.
That
would
allow
us
to
gain
the
confidence
that
we
wanted,
that
all
of
our
development
workflows
would
work
and
that
github
enterprise
would
just
run
for
us.
So
great.
This
seemed
like
a
plan
that
was
going
to
work
so
once
we
had
a
plan
that
we
thought
was
going
to
work,
it
was
time
to
just
put
in
a
bunch
of
work
to
get
ready
to
execute
on
that
in
our
production
environment.
A
A
So
I
get
a
better
price
set
up.
Looked
a
little
bit
like
this.
We
had
a
production
primary
instance
and
a
production
replica
instance.
We
also
had
another
pair
of
these
in
our
staging
environment,
which
would
allow
us
to
do
things
like
test
new
releases
of
github
enterprise
before
rolling
them
out
to
our
production.
Environment.
A
Github
also
provides
backup
tools
for
backing
up
your
get
up
Enterprise
instance
and
they're
pretty
good,
so
I
really
recommend
that
you
use
them,
and
so
we
wanted
to
set
up
servers
to
run
those
and
then
upload
the
backups
to
where
the
rest
of
our
backups
are
stored.
And
then
there
were
just
all
these
touch
points
where
we
had
to
integrate
YouTube
Enterprise
with
all
of
our
existing
infrastructure.
So
we
had
to
wire
it
up
to
things
like
our
user
authentication
system
or
logging
system,
our
metrics
and
monitoring
system
and
our
system
for
sending
email.
A
It's
once
we
wired
all
that
up.
It
was
time
to
test.
So
what
do
we
test?
First,
we
tested
all
of
those
core
development
workflows
that
we
knew
would
need
to
work
so
I'm.
Writing
some
code.
I
push
a
branch.
My
test
run,
I
ate
some
more
open.
A
pull
request.
Do
code
review,
merge
it
deploy
it.
We
tested
all
of
that
multiple
times
over,
we
tested
all
the
operational
procedures
that
we
knew.
We'd
have
to
be
familiar
with
in
order
to
sustainably
run
get-up
enterprise
in
the
long
term.
A
So
these
are
things
like
failing
over
from
the
primary
to
the
replica.
In
case
anything
happened
to
the
primary
upgrading
to
a
new
release
of
get
a
better
prize
or
restoring
from
backup
if
we
needed
to-
and
we
also
tested
our
entire
migration
plan-
that
entire
phase
plan
of
moving
all
600
of
those
repositories
over
in
phases.
We
tested
that
entire
thing
multiple
times
and
github
recommended
that
we
do
this,
and
we
were
really
really
happy
that
we
did
this
so
take
it
from
both
of
us.
A
You're
gonna
really
really
want
to
do
this,
and
there
are
a
few
reasons
for
this
first
you're
going
to
learn
how
to
transform
your
data
and
what
I
mean
by
that
is
the
process
that
github
tools
go
through
as
they're
importing.
Your
repository
into
gated
enterprise
is
that
they're,
basically
mapping
database
records
from
github
com
into
your
database
under
github
Enterprise
instance,
and
depending
on
the
order
in
which
you
migrate
things,
some
inconsistencies
might
occur
there,
and
this
is
expected,
get
up
documents
how
to
handle
this,
and
they
provide
tools
for
handling
this.
A
First,
there
were
just
some
bugs
and
how
we
integrated
YouTube
Enterprise
with
our
systems.
So
we
worked
out
the
kinks
there.
Then
we
had
to
figure
out
how
to
best
transform
our
data
using
github
tools.
We
figured
out
how
to
use
those.
Then
we
found
that
there
was
some
data
that
just
didn't
migrate
over.
So
normally
this
wouldn't
be
a
problem
because
git
is
designed
to
be
decentralized.
A
So
it's
really
hard
to
push
a
git
repository
from
one
server
to
another
and
experience
any
data
loss,
but
github
adds
all
of
the
interesting
data
around
and
get
repository
things
like
user
accounts
and
settings
and
pull
requests,
and
all
of
this
is
migrated
using
github
proprietary
tools
and
those
tools
migrate
most
of
this
stuff,
but
not
all
of
it,
and
some
of
that
stuff
was
pretty
important
to
us.
Things
like
pull,
request,
assignees
and
commit
statuses.
A
So
we
ended
up
writing
our
own
scripts,
using
the
API
to
migrate
that
stuff
for
us
and
then,
as
we
were,
txt
testing
exporting
these
repositories
out
of
github
com.
Sometimes
those
exports
would
just
fail
and
it
would
fail
for
a
few
reasons,
the
asynchronous
jobs
that
github
runs
to
export
the
repositories
for
you
have
time
limits.
So
if
you
give
it
a
big
enough
list
of
repositories,
you
could
just
trip
that
time
limit.
A
So
you
might
have
to
sort
of
rework
how
you
split
your
repositories
up
into
phases
in
order
to
fit
all
of
your
phases
underneath
that
time
limit
and
similarly
the
exported
archives
that
this
API
gives.
You
also
have
size
limits,
so
you
may
need
to
change
how
your
repositories
are
split
up
to
fit
under
that
limit
as
well,
and
then
there
was
what
we
affectionately
came
to
call
the
emoji
bug
which
get
a
bit
since
fixed.
So
thank
you,
but
I
want
to
tell
you
about
it
anyway,
because
I,
just
like
it
so
much
so.
A
The
deal
with
the
emoji
bug
is
that
we
were
trying
to
export
one
of
our
repositories
and
it
kept
failing,
and
we
weren't
sure
why
it
was
not
very
big.
It
wasn't
taking
very
long.
It
should
be
totally
unremarkable,
but
it
kept
failing.
So
we
reached
out
to
github
support
and
had
them
take
a
look,
and
this
is
what
they
told
us.
A
So
it's
since
been
fixed,
but
a
good
rule
of
thumb.
If
you're
trying
to
sell
software
to
stripe
or
trying
to
get
us
to
use
your
software
is
that
if
a
text
field
exists,
my
co-workers
are
gonna,
try
to
put
emoji
into
it,
so
you
better
let
them
so
once
we
worked
out
all
the
kinks
and
had
a
migration
plan
that
we
had
tested
and
verified.
It
was
time
to
do
the
actual
production
migration.
So
how
did
it
go?
A
Well,
several
things
went
wrong,
but
we
also
kind
of
knew
that
this
was
going
to
happen,
which
is
why
we
spent
so
much
time
on
an
incremental,
reversible
plan
in
the
first
place.
So,
instead
of
saying
that
several
things
went
wrong
instead,
I'm
gonna
say
we
got
better
at
migrating
after
quickly
rolling
back
several
times,
and
this
doesn't
sound
quite
as
good.
A
One
of
us
would
get
paged
and
there
was
nothing
we
could
actually
really
do
about
it,
except
to
watch
code
review,
break
for
the
entire
company,
which
wasn't
fun,
and
then
we
just
have
to
cross
our
fingers
and
hope
that
the
quota
would
reset.
So,
as
you
can
see
at
the
end
there
as
it
levels
off,
this
became
a
thing
of
the
past
when
we
moved
all
of
our
stuff
over
to
get
AB
Enterprise.
A
A
So,
to
tell
you
this
story,
I
want
to
first
tell
you
about
shift
at
which
is
my
favorite
mailing
list
at
stripe,
and
maybe
my
favorite
mailing
list
ever
but
I.
Don't
actually
have
a
list
of
my
favorite
banning
lists,
but
if
I
did
it
would
be
at
the
top
I
think
and
they
do
let's
ship.
That
is
that,
whenever
you're
about
to
ship
something
big
or
you
have
shipped
something
big
or
maybe
fix
something
big
within
the
company,
you
write
an
email
and
send
it
to
this
list,
describing
what
it
is
that
you
did.
A
How
you
did
it's,
why
you
did
it
why
it
was
hard
what
challenges
you
overcame
when,
perhaps,
most
importantly,
how
our
users
lives
would
be
better
for
what
you
did
and
what
I
really
like
about
ship.
That
is
I
mean,
of
course,
like
everyone
sends
to
this
list,
and
everyone
gets
to
see
it
and
celebrate
each
other's
work.
So
that's
great,
but
the
other
thing
that
I
really
like
is
that
we
will
often
write
the
ship
that
emails,
not
at
the
end
of
the
project.
A
But
at
the
beginning,
and
the
reason
for
this
is
it
forces
us
to
figure
out
exactly
what
we're
going
to
deliver
to
our
users,
which
is
a
really
good
exercise
to
undertake
before
you
start
writing
any
code.
So
what
would
an
aspiration?
Will
ship
that
email
look
like
for
I
get
AB
Enterprise
project.
It
might
look
like
this.
A
Instead,
they
would
see
this
repository
not
found,
and
this
is
because
their
local
clone
of
the
repository
had
no
knowledge
of
the
fact
that
we
had
moved
the
repository
from
github
com2
get
up
Enterprise,
so
their
local
clones
would
still
be
trying
to
pull
from
github
comm
and
fail,
but
there
is
a
command
that
you
can
run
to
change
the
the
local
remote
for
a
git
repository.
So
we
thought,
okay,
we
can
totally
fix
this.
A
We
can
just
run
that
command
to
change
the
origin
on
all
the
affected
repository
clones
on
all
the
laptops
of
all
the
get
users
at
stripe
once
for
every
phase
of
the
migration
and
more
every
time
we
had
to
rollback
and
roll
forward.
So
this
is
another
one
of
those
things
were
like:
maybe
it
would
have
worked,
but
even
if
it
did
this
is
what
I
would
have
looked
like
at
the
ends.
Had
we
gone
this
route,
it
really
didn't
feel
like
something
that
was
going
to
scale
well
for
500
50
50
active
github
users.
A
For
this
part,
what
we'd
love
to
say
is
your
locally
cloned
repositories
are
going
to
continue
to
work
without
intervention,
because
we've
pre-configured
your
git
client
to
dynamically
route,
get
operations
to
the
correct
origin.
Now
we
had
no
idea
how
to
actually
do
this,
but
we
wrote
it
down
because
it
sounded
great.
A
So
what
we
did
is
we
worked
as
our
IT
engineering
team
to
first
distribute
a
software
package
to
everybody's
laptop
before
the
migration
even
started,
and
that
software
package
installed
a
couple
of
things.
First,
it
installed
some
get
configuration
that
would
override
the
origin
urls
for
all
of
our
private
repositories
to
instead
invoke
a
remote
helper
script.
Now
with
get
a
remote
helper
script
is
a
way
to
teach
it.
A
A
new
protocol
soget
understands
SSH
and
HTTP
and
other
protocols,
and
if
you
want
to
cheat
a
new
one,
you
could
write
a
remote
helper
script
for
that
we
didn't
actually
want
to
do
that.
We
just
wanted
to
call
out
to
SSH,
but
first
insert
a
little
bit
of
custom
code
so
that
we
could
basically
change
where
that
SSH
was
calling
out
to
and
what
that
custom
code
would
do
is
perform
queries
against
our
service
discovery
system,
which
we
could
keep
up
to
date
with
the
location
for
every
repository.
A
So
throughout
the
migration,
as
we
were
moving
repositories
over
or
rolling
back,
we
would
just
update
the
service
discovery
system.
We
use
console,
but
you
could
use
whatever
you
use.
We
would
update
that
with
the
contents
of
that
migrated
imo
file
and
then
this
remote
helper
script
would
know
where
to
send
SSH.
A
So,
let's
go
through
that
git
pull
again
with
this
configuration
installed,
so
the
origin
would
start
out
configured
to
be
talking
to
get
up
comm,
which
may
be
wrong
for
this
repository
at
this
time
and
then
the
gate
configuration
would
override
the
origin
to
invoke
our
remote
helper
scripts
and
then
get
would
invoke
the
remote
helper
script.
Whenever
would
someone
did
a
git
push
or
get
pull?
A
Our
scripts
would
talk
to
our
service
discovery
system,
to
figure
out
the
real
location
of
the
repository,
and
then
our
script
would
exact
SSH
with
the
real
origin
substituted
in
and
so
now
all
the
get
operations
were
in
fact
routed
to
the
right
place
so
awesome.
This
did
actually
work,
I'm
sort
of
a
little
bit
surprised
that
it
did,
but
it
was
cool.
We
got
some
good
feedback
about
it.
Someone
said
nice
that
console
lookup
is
really
clever.
I
was
curious.
A
How
that
works
so
seamlessly-
and
this
is
my
favorite
piece
of
feedback
from
the
whole
project.
I-
can
barely
believe
this
happened.
This
is
really
what
we
were
going
for
in
terms
of
seamlessness,
so
we
learned
a
whole
lot
from
this
project.
It
was
pretty
uniquely
shaped
and
not
like
anything
we
had
ever
seen
before,
but
what
I
actually
was
we're
happy
about
was
that
we
also
revalidated
all
these
engineering
practices.
A
So,
instead
of
from
starting
from
where
you
are,
maybe
you
have
some
code
written
and
then
make
some
changes
and
hope
that
you're
sort
of
getting
towards
a
better
user
experience,
and
maybe
you
can
make
local
decisions
and
do
that
instead
take
a
step
back
and
think
about
what
is
the
absolute
best
possible
thing.
You
could
ship
to
your
users,
regardless
of
what
you
already
have.
What
is
the
absolute
best
possible
thing?
You
could
ship
to
them
and
work
backwards
from
there
now.
A
This
process
of
back
solving
to
where
you
are
right
now
can
be
really
difficult,
and
it
can
also
cause
you
to
have
to
do
a
lot
more
work,
but
it's
an
incredibly
effective
exercise
to
make
sure
that
you're
doing
what
your
users
really
want
and
similarly
treat
your
infrastructure
like
a
product.
So
just
because
you're,
not
unlike
the
product
team
shipping
product,
doesn't
mean
you're
not
working
on
a
product.
A
If
you
have
to
and
put
your
users
first
but
think
about
yourself
too.
So
it's
no
accident
that
the
migration
plan
that
we
came
up
with
did
not
involve
a
bunch
of
engineers
locked
in
a
conference
room
for
72
hours,
that
would've
been
really
fun,
but
also
the
truth
is
just
that
a
engineering
team,
that's
well-rested
and
hasn't
been
up
for
72
hours.
It's
just
gonna,
do
much
better
work
and
make
many
fewer
mistakes
than
a
team
that
is
totally
sleep-deprived.
A
So
don't
let
anyone
try
to
convince
you
that
sleep
deprivation
is
necessary
for
finishing
a
big
project
like
this
and
finally
asked
for
help.
I
can't
tell
you
the
number
of
times
when
the
two
or
three
of
us
that
were
working
on
this
project
full-time
would
sit
down
at
lunch
and
talk
to
our
co-workers
and
tell
them
about
the
latest
problem
we
were
facing
with
our
enterprise.
A
Migration
tell
them
about
the
latest
challenge
we
were
chewing
on
and
we
come
away
from
that
lunch
with
tons
of
new
ideas
from
these
people,
with
expertise
in
different
areas
and
tons
of
just
offers
to
help
too.
So
this
is
how
we
got
contributions
from
within
stripe,
from
teams
like
security
and
IT
and
storage
and
observability,
and
that
was
all
just
because
we
talked
to
them
and
said:
hey
like
this
is
what
we're
dealing
with
do.
You
know
something
we
could
try,
and
similarly,
we
asked
for
github.
A
We
asked
for
help
from
github
too,
because
we
really
needed
to
know
the
limits
of
the
migration
tools
as
well
as
a
lot
about
how
github
Enterprise
worked
in
order
to
uplevel
the
user.
Experience
that
we
were
able
to
achieve
during
a
migration
like
this.
So
I
really
want
to
thank
everyone
at
stripe
who
helped
us
with
this
project,
as
well
as
everyone
at
getup
who
helped
us
with
this
project
and
I
want
to.
Thank
you
too,
for
coming.