►
Description
Presented by Jeff Josephson, Senior Systems Engineer, Expedia Group
In 2018, Expedia Group started a project to consolidate all their source code into a single instance of GitHub Enterprise. The team wanted to drive more collaborative development and improve developer efficiency. In this talk, you'll learn about the background of the project, goals, and objectives for success, the design and architecture of the new instance, migration methods used and how they were automated, and details on the challenges faced and how they were resolved.
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
All
right,
hello,
everyone
welcome
to
the
last
group
of
sessions
here
at
Universe
2019
thanks
for
sticking
with
me.
My
name
is
Jeff
Josephson
I'm,
a
senior
system
engineer
at
Expedia
group
and
I'm,
going
to
be
talking
to
you
today
about
Expedia
group's
ongoing
project
to
consolidate
all
of
our
source
code
into
a
single
instance
of
github
and
how
we're
using
that
to
allow
our
developers
to
be
more
efficient
and
better
collaborate
with
each
other.
So,
first,
a
little
bit
about
me.
A
I've
been
a
speedy
group
for
about
five
years,
I'm,
a
member
of
the
developer
collaboration
team
and
I,
primarily
work
on
cloud
design
and
architecture
for
our
developer
tools.
That
includes
all
new
Greenfield
deployments,
as
well
as
legacy
tool
migrations
out
of
our
data
center
and
into
the
cloud
when
I'm
not
work.
You
probably
find
me
right
in
my
mountain
bike
or
playing
soccer,
so
the
start
was
a
little
background.
How
do
we
get
started
on
our
consolidation
project?
A
Well,
if
we
go
back
in
time
about
three
years
ago,
we
can
see
that
Expedia
group
has
been
growing
organically
for
a
long
time.
We've
added
a
lot
of
brands
to
the
group
and
in
general,
each
of
those
brands
has
brought
with
them
their
own
source
code
instance.
That's
been
great,
it's
let
our
developers
be
very
agile.
They
sort
of
have
their
own
place
through
their
work.
They
can
work
quickly.
A
You
do
what
they
need
to
do,
but
they're
also
very
siloed,
they're
generally
working
by
themselves
in
their
own
place,
they're
not
easily
able
to
share
code.
They
may
not
even
know
about
all
the
other
instances
that
exist
out
there.
That
also
leads
to
decentralized
administration.
Different
teams
run
all
these
instances.
If
you
want
to
get
access
to
one
or
permissions
or
learn
something
more
about
it,
you
have
to
figure
out
what
team
to
talk
to
you
not
even
know.
A
So
why
do
we
decide
to
consolidate
well?
For
starters,
we
want
a
single
source
of
truth.
We
want
all
of
our
code
in
one
place.
We
want
our
developers
know
that
if
you're
looking
for
code,
you
only
have
to
go
to
one
place
to
find
it.
We
also
want
to
give
our
developers
a
unified
development
experience
across
all
these
other
systems.
If
you
change
teams
or
orgs,
you
might
have
to
completely
relearn
how
to
just
commit
code
in
the
source
control.
A
We
all
know
developers
be
able
to
do
things
the
same
way,
no
matter
where
they
are
in
the
company.
We
also
want
to
be
able
to
enable
embrace
a
collaborative
development
practices
we're
on
our
developers
to
be
able
to
work
together
with
each
other
to
find
other
teams
code
to
contribute
to
it
too
use
it
themselves.
We
want
them
to
be
able
to
easily
find
that
and
take
advantage
of
it
and
that's
true
for
both
inter
sourcing
and
open
sourcing.
A
We
want
our
developers
to
be
able
to
both
work
with
each
other
and
contribute
to
each
other
inside
the
company
and
also
be
able
to
be
part
of
the
greater
community
at
large.
And
finally,
we
want
to
reduce
some
costs.
We've
got
a
lot
of
infrastructure
rolling
these
two
different
systems.
We
got
a
license,
all
of
them.
We
got
it,
have
different
teams
administering
them
and
we
have
to
train
users
to
use
them
when
they
move
around
inside
the
company
or
there's
a
reorg,
or
something
like
that.
A
So
that
sounds
great.
We
get
a
lot
of
benefits
out
of
consolidating,
but
we
had
some
sources
of
resistance
when
he
tried
to
start
this
project.
So
for
starters,
there's
just
plain
organizational
inertia
to
a
lot
of
developers.
The
current
systems
work.
Just
fine.
You
check
out
your
code,
you
make
your
changes,
you
submit
it
you
deploy
it.
Everything
seems
good.
It's
difficult
for
the
teams
to
see
the
immediate
benefits
of
going
through
a
large-scale
migration
like
this
go
into
a
central
system
also
requires
teams
to
accept
some
compromises.
A
When
they
own
their
own
system,
they
can
do
whatever
they
want.
They
can
fully
customize
it
make
things
work,
however,
they
want
if
they
go
to
a
central
system,
they're,
giving
up
some
of
that
control
and
they're
letting
another
team
make
some
decisions
that
may
not
always
be
ideal
for
them.
There's
also
potential
loss
of
historical
metadata
with
any
sort
of
migration
project.
We'll
do
our
best
to
migrate
everything
over
get
all
their
data,
get
everything
they
need,
but
it's
always
possible
that
we'll
lose
something
in
the
transition.
A
They're,
also
going
to
lose
ownership
of
their
systems.
They're
not
going
to
be
able
to
control
themselves.
Have
you
no
system,
Ataman
lights,
that
sort
of
thing
they're,
giving
all
that
up
to
another
team,
and
it
also
just
creates
a
lot
of
churn
you're,
changing
all
the
things
about
your
code
pipeline,
you
may
have
to
redo
existing
customizations
or
integrations
all
that
has
to
take
place
before
you
can
really
take
advantage.
The
new
system
and
finally,
there
could
just
be
a
lack
of
feature
parity
there.
A
The
system
they
were
using
might
not
have
the
exact
same
features
at
the
new
system
or
they
might
work
in
a
different
way.
So
how
do
we
move
forward?
Well?
For
starters,
executive
sponsorship
is
always
important
for
something
on
this
scale.
You
need
an
executive,
that's
willing
to
to
go
out
there
and
say
this
is
a
useful
project.
This
is
important
to
us.
It's
worth
the
pain,
we're
gonna
actually
make
this
happen.
That
kind
of
mandate
is
extremely
helpful,
but
it
can't
be
the
only
thing
you
do.
A
You
also
need
to
make
a
new
system
awesome.
Make
it
great
make
it
something
that
teams
are
going
to
want
to
use
if
you
give
them
some
new
features
or
better
performance
or
easier
connectivity,
or
something
like
that,
then
it's
it's
going
to
be
something
that
they
want
to
switch
to
and
they're
willing
to
accept
the
the
short-term
pain
of
the
migration.
A
We
also
want
to
simplify
the
migration
process.
We
really.
This
is
all
about
it,
making
it
easy
for
our
developers.
We
want
them
to
be
able
to
move
from
one
system
to
another
without
it
being
some
big,
drawn-out
process.
We
want
to
make
it
as
easy
as
possible
for
them
to
get
their
code
in
the
new
system
and
to
start
taking
advantage
of
it.
We
also
want
to
make
as
much
of
this
self
service
and
self
owned
as
possible.
Our
teams
love
to
have
their
own
control
over
things.
A
We
want
to
allow
them
to
do
that
and
we
much
rather
that
they
solve
their
problems
and
they
figure
things
out.
Then
they
have
to
constantly
come
to
the
support
team
for
it.
So
we
want
to
do
as
much
self
service
and
self
ownership
as
we
can.
We
also
want
to
have
thorough,
high-quality
documentation
and
we
want
to
have
it
ready
before
the
questions
are
even
asked.
We
want
to
allow
our
developers
to
move
quickly
to
get
on
board
with
a
new
system
and
to
start
reusing
it.
A
We
don't
want
them
to
have
a
constantly
stopped.
Ask
questions.
Wait
for
us
to
respond.
That's
for
thing,
so
we
want
to
get
them
some
Docs.
Have
them
ready
to
go,
make
it
easy
to
search
and
find
so
they
can
help
themselves.
And,
finally,
it's
important
to
listen.
You're,
not
the
one.
That's
likely
going
to
be
using
your
system,
the
most
you're,
probably
more,
of
an
engineering
team,
so
patients
are
what
your
developers
are
trying
to
do.
What
are
their
challenges?
What
are
their
struggles?
A
What
are
the
things
that
they're
they're
having
trouble
with
in
their
current
system,
and
what
can
you
do
in
your
new
system
to
make
things
easier
for
them?
So
we
came
up
with
a
plan.
It's
pretty
easy.
We're
gonna,
build
a
new
system,
we're
gonna
migrate.
All
relevant
code
to
it
relevant
is
a
bit
of
a
key
word
there.
We
only
want
to
ring
over
what
actually
matters
tons
of
stuff
builds
up
in
source
control
over
time.
We
want
to
leave
all
that
junk
behind.
A
We
want
to
just
bring
over
what
really
matters
what's
going
to
be
used
in
the
future,
it's
our
chance
to
kind
of
get
a
fresh
slate,
clean
slate
and
finally
want
to
enable
our
developers.
We
want
them
to
be
organized.
We
want
them
to
be
able
to
encourage
and
embrace
collaborative
development
practices,
and
you
want
to
make
sure
that
we
remove
any
roadblocks
that
are
preventing
them
for
being
more
efficient.
A
So
we
start
with
the
build
process.
We're
gonna
build
our
all
new
instance
of
gettime
Enterprise.
So
why
did
we
pick
get
our
enterprise?
Well,
it's
the
industry
standard.
When
you
think
about
get
you
think
of
github.
It
also
has
a
common
experience
with
github
calm,
so
anybody
that's
been
working
with
github,
calm
and
familiar
with
the
user
interface.
They
come
to
enterprise.
It
looks
the
same
works.
The
same
feels
the
same.
So
it's
something
that
everybody's
pretty
used
to.
A
It
is
already
in
use
in
parts
of
expedia
group,
so
we
have
some
organizational
momentum
there.
We
have
some
users
that
are
already
on
board
with
it
happy
with
it.
So
it
was
easy
to
make
this
decision.
And
finally,
it's
familiar
to
most
everyone
developers
coming
out
of
college
and
probably
using
it
for
the
project's
they're
people
involved
in
open
source
and
their
personal
lives,
I've
been
using
it.
It's
something
that
isn't
gonna
seem
foreign
to
a
lot
of
people
getting
started
for
the
first
time.
A
And
finally,
we
love
the
get-ups
dedicated
to
continuous
product
improvement.
I
mean
we've
just
seen
over
the
last
couple
days
that
there's
all
sorts
of
new
features
getting
added
to
get
up
every
six
months,
really
crossing
our
fingers
that
we
get
all
that
stuff
from
an
enterprise
server
pretty
soon,
and
we're
also
really
happy
about
enterprise
support.
We
like
knowing
that
there's
a
team
behind
us
that
if
we
have
problems,
if
something
doesn't
go
right,
that
we
can
go
to
them
and
get
the
help
we
need
and
move
forward.
A
So
we
came
up
with
a
list
of
requirements
that
we
wonder
instance
to
have.
First,
we
want
to
built
in
the
cloud.
Building
in
cloud
gives
us
easy
scalability.
We
can
turn
up
the
resources
if
we
need
them
without
much
pain
lowers
our
costs.
We
only
have
to
pay
for
what
we
need
and
finally,
we
can
use
automatic
and
deployment
configuration
tools.
We
also
want
to
make
sure
that
we
have
a
single
endpoint,
an
only
single
endpoint.
A
Some
of
our
old
systems
had
six
seven,
maybe
eight
different
proxy
servers,
four
different
network
locations
and
regions
of
the
globe.
We
don't
want
our
developers
to
have
to
deal
with
that
anymore.
That's
a
lot
of
configuration
overhead,
a
lot
of
tribal
and
knowledge
you
have
to
remember
if
they
want
to
get
the
best
performance,
we
want
them
to
just
remember
a
single
address,
that's
all
they
ever
need
to
use.
We
also
want
to
be
geographically
available.
We
want
to
be
in
multiple
regions.
A
We
want
intelligent
around
in
those
regions
so
that
you're,
the
user
traffic
will
go
wherever
look
at
the
best
performance.
We
also
want
it
to
be
redundant
so
that
if
we
have
a
problem
in
one
reason
we
can
easily
failover
keep
going,
the
users
may
not
even
notice,
and
finally,
it
should
be
secure.
We
want
our
intent
to
be
fully
protected
upon
a
laugh
in
front
of
it,
make
sure
that
we're
protected
from
malicious
traffic,
DDoS
attacks,
things
like
that,
and
we
want
to
only
allow
trusted
access.
A
We
want
to
make
sure
that
only
Expedia
owned
that
approved
sources
can
access
our
source
control.
So
we
take
those
designs
and
put
them
all
together.
We
get
something
that
looks
a
little
bit
like
this
and
it's
pretty
straightforward.
You
start
at
the
top.
You
can
see
our
user
traffic
coming
in.
We
use
Akamai
for
our
IP
whitelisting
and
geolocation
services.
Akamai
will
look
at
the
incoming
traffic
figure
out,
which
of
our
three
regionals,
give
it
the
best
performance
and
route.
A
So
what
kind
of
user
experience
do
we
get
with
that
design?
Well,
there's
a
single
URL!
There's
only
one
address
that
our
developers
ever
need
to
know
you
get
code.
You
always
just
go
to
the
same
place.
Doesn't
matter
if
you're
in
the
lab,
if
you're
in
production
it
you're
working
on
the
VPN
or
working
at
home
in
a
Chicago
office
London,
whatever
one
address
is
all
you
ever
need,
and
you
also
get
automatic
regional
proxying
from
that
use
that
one
address
and
an
outcome.
A
I'll
figure
out
the
right
place
to
send
you,
so
you
get
the
best
performance
possible,
no
additional
configuration
needed.
We
also
support
HTTPS
and
SSH,
so
teams
can
use
whichever
authentication
method
works
best
for
them
and
it's
responsive
and
fast.
Since
it's
built
in
a
cloud,
we
can
easily
just
crank
the
knobs
up
if
we
need
a
little
bit
more
horsepower
and,
finally,
it's
reliable
with
very
little
downtime
and
upgrades
with
get
of
enterprise
or
quick
and
very
low
impact.
A
So
we've
got
a
new
instance
built
now.
I
need
to
migrate
all
my
stuff
to
it.
So
what
are
we
dealing
with?
Well
Expedia
Group.
We
got
about
a
little
over
10,000
active,
get
users.
We've
got
something
like
60,000
git
repos
across
both
bitbucket
and
get
of
enterprise,
hundreds
of
thousands
of
pull
requests
in
those
repos.
We
also
15
perforce
systems
about
1,800,
active
perforce
users
and
then
minor
amounts
of
code
in
subversion,
TFS
get
lab
and
some
other
things,
so
some
challenges
that
we
face
with
this
kind
of
a
migration
scope.
A
Well,
for
starters,
that
migration
process
is
different
for
each
system.
The
way
you
migrate
code
out
a
bit
bucket,
isn't
the
same
as
you
migrate
code
out
of
github
or
perforce
there's,
also
pretty
big
impact
to
our
development
teams.
With
this
kind
of
migration,
any
existing
automation
or
reporting
systems
will
need
to
be
updated
for
the
new
system
and
there
could
just
be
differences
if
you're
working
in
perforce
that's
a
very
different
experience
than
if
you're
working
in
github
and
finally,
this
kind
of
migration
is
going
to
have
an
impact
to
our
teams.
A
Your
roadmap
is
going
to
be
affected.
Your
release,
cadence
might
not
be
able
to
stay
the
same
first
more
time,
there's
probably
some
impacts
to
milestones.
There's
also
impact
to
our
support
team.
Our
sport
team
isn't
huge.
If
there's
a
lot
of
problems
with
migrations
it
could,
they
could
get
overwhelmed.
A
They
may
not
be
able
to
keep
up
with
the
flow
of
tickets
if
they
fall
behind,
that's
going
to
slow
responses
to
teams
and
that
could
slow
development
teams
down
even
more
and
finally,
there's
just
plain
processing
time
we're
talking
about
a
huge
amount
of
data,
and
you
can
only
move
so
much
data
so
quickly,
so
it
very
base
level.
We
just
have
to
wait
for
all
this
data
and
move
where
it
needs
to
go
and
get
processed
into
the
system.
So
what's
our
plan?
A
Well,
we
want
to
automate
as
much
as
possible
doing
automated
graison's
means
we
can
drastically
lower
the
amount
of
manual
effort
is
required
from
our
support
teams.
We
also
want
to
allow
our
teams
to
migrate
on
their
own
terms.
We
want
make
migration
a
self-service
process
for
them.
We
want
them
to
be
able
to
decide
when
the
time
is
right,
make
the
choice
themselves
and
then
execute
the
entire
migration
without
having
to
contact
us
or
the
support
team.
A
We
also
want
to
make
sure
that
we
give
our
teams
reasonable
deadlines,
so
provide
them
the
tools,
let
them
self
service
the
migration,
but
give
them
a
deadline
that
they
have
to
meet
and
hold
them
to
it.
If
we
keep
letting
teams
push
things
out,
things
are
never
gonna
get
done.
One
of
the
great
things
about
self-service
migrations
is
that
you
also
can
let
your
team's
test-first
they
can
move
over
a
repo,
maybe
to
check
all
their
pipelines
check
the
CI
CD
make
sure
that
everything
is
working
with
a
new
system,
get
everything
ready.
A
So
when
that's.
Finally,
the
time
is
right.
They
can
push
the
button
migrant
everything
and
be
ready
to
keep
going.
We
also
make
sure
that
our
migrations
of
easy-to-follow
instructions
we
want
to
make
sure
our
instructors
are
clear
and
concise
that
when
teams
are
ready
to
migrate,
they
can
follow
the
documentation.
Follow
the
steps
move
the
repos
over
and
everything
works
on
the
first
shot.
We
want
to
make
sure
that
we
document
anything
that
gets
asked
frequently
so
that
all
the
answers
are
right
there
waiting
for
them
and
they
don't
have
to
come
to
us.
A
That
said,
if
they
do
have
problems
or
have
questions,
we
want
to
have
a
dedicated
support
contact
point.
We
want
to
make
sure
that,
if
teams
have
problems,
if
they
need
to
get
a
quick
answer,
we
don't
want
them
to
have
to
look
through
some
service
directory
or
some
sort
of
ticketing
system.
Something
want
them
to
be
able
to
get
to
someone
quickly.
That
has
the
information
they
need,
so
they
can
answer
the
question
and
move
on
with
their
migration.
A
So
what
do
we
do
for
automated
migrations?
Well,
for
us,
we
were
able
to
support
them
for
github
Enterprise
in
bitbucket.
We
use
two
different
utilities
for
that
versus
ghe
migrator.
This
is
the
native
github
import/export
tool,
it's
included
on
every
github,
Enterprise
appliance,
and
you
run
it
on
both
the
source
and
the
destination.
So,
if
you're
coming
out
of
getting
enterprise,
you
run
GT
migrate,
export,
the
repo
transfer
that
to
your
destination,
get
of
enterprise
appliance
and
then
GHU
migrator
again
to
import
it
in
BBS.
A
Migrator
is
for
bitbucket,
and
that
is
a
github
developed,
bitbucket
export
tool
and
export
to
repo
data
through
the
bitbucket
REST
API,
and
it
generates
a
ghe
migrator,
compatible
repo
bundle,
which
means
that
you
can
take
your
repo
bundle,
export
it
out
a
bit
bucket
copy
to
your
clients
and
then
run
GG
migrator
to
import
it,
and
the
combination
of
these
two
utilities
covers
about
95%
of
all
Expedia
group
repos.
That
need
to
be
migrated.
So
this
is
where
the
bulk
of
our
automation
efforts
were
focused.
A
So
what
are
the
challenges
of
trying
to
automate
these
migrations?
Well,
for
starters,
these
migration
tools
require
high
level
permissions.
There
they're
generally
man
line
utilities,
then
Gigi
migrators
meant
to
run
on
the
github
appliance
itself,
see
any
root
level
access
there
and
BBS
migrator
requires
system
admin
permissions
in
bitbucket
there
also
a
manual
process
by
default.
These
are
just
command
line
utilities
that
take
a
bunch
of
parameters.
It's
not.
The
sort
of
thing
has
been
designed
to
be
automated
migration.
Are
these
tools
are
also
generally
meant
to
be
used
asynchronously.
A
So
the
export
process
is
completely
different
from
the
import
process,
so
you
have
to
have
some
way
to
communicate
from
the
export
to
the
import
and
make
sure
they
stay
in
sync
with
each
other,
and
it's
also
a
serial
process.
Github
only
allows
one
instance
of
ghe
migrator
to
xu
at
a
time.
So
that
means
that
the
speed
that
you
can
import
repos
in
to
get
of
enterprise
is
limited
by
how
fast
you
can
execute
ghe
migrator,
it's
also
difficult
to
paralyze
these
migrations.
A
While
it
is
possible
to
batch
repos
into
GG
migrator,
you
have
to
use
a
single
conflicts
file
during
conflicts,
processing
for
all
of
those
repos
and
that
can
make
doing
that
with
automation
pretty
difficult.
So,
let's
go
into
a
little
more
detail
about
conflicts
processing.
This
is
one
of
the
trickiest
parts
of
dealing
with
these
migrations
conflicts.
Processing
is
basically
where
github
will
compare
the
incoming
metadata
from
your
repo
that
you're
importing
to
what
already
exists
in
your
destination.
A
So
it's
looking
at
things
like
users,
teams
or
anything
that
would
collide
github,
will
generate
a
conflict
on
CSV
file
and
it'll
list
out
all
of
the
things
that
are
a
conflict
between
the
source
and
the
destination
and
allow
you
to
tell
github
what
you
want
to
do
with
that
conflict.
You
can
use
this
to
map
things
together.
If
they're
the
same,
you
can
rename
things
you
can
remove
things,
it's
a
pretty
powerful
and
flexible
tool,
but
it
needs
to
be
customized
to
every
repo
that
you're
importing.
A
A
It's
a
really
good
way
to
pollute
your
nice
new
github,
Enterprise
appliance
with
a
bunch
of
garbage
data
that
can
be
a
real
pain
to
clean
up
afterwards,
so
generally
I
definitely
use
it
carefully
and
test
everything
thoroughly
before
you
try
to
use
in
production.
In
our
specific
case,
one
of
the
most
difficult
things
to
handle
was
when
we
had
inconsistent
user
bases
between
our
source
instance
and
our
destination
incidents.
So
this
means
that
the
user
directory
that
the
repo
is
coming
from
is
different
from
the
user
directory
of
our
new
github
Enterprise
appliance.
A
It
could
also
be
the
case
that
even
if
J
Smith
didn't
exist
in
the
destination
he
might
someday
get
hired
and
if
they
did,
then
they
probably
wouldn't
allow
again
to
get
up
for
the
first
time
and
see
that
they
had
four
hundred
commits
under
their
name
from
ten
years
ago.
It's
the
kind
of
thing
you
don't
want
to
run
into
in
the
future
either.
A
So
our
solution
to
this
problem
is
that
whenever
we
import
repos
from
a
system
that
does
not
have
the
same
user
directory,
we
rename
all
of
the
users
coming
in
with
a
special
tag
that
shows
where
they
came
from,
but
also
make
sure
that
we
never
have
any
user
name
conflicts
with
our
destination
instance.
We've
also
done
something
similar
with
importing
teams,
since,
in
general,
the
teams
on
a
source
instance
are
not
going
to
exactly
match
up
with
the
teams
that
the
users
want
on
the
destination.
A
So
to
handle
all
this
automated
migration,
we
created
something
we
called
Gus
Gus
stands
for
github
self
service.
This
was
developed
by
Expedia
group
and
essentially
wraps
the
existing
migration
tools
to
allow
their
use
by
non
edmonds
with
Gus.
Our
users
can
do
one-click
migrations
of
repos
from
their
source
instance
to
the
destination
instance.
Gus
is
written
in
Python
uses,
JIRA
for
tracking
and
notification
uses
an
s3
bucket
for
repo
storage,
and
it
has
a
cron
job
on
the
appliances
to
handle
scheduling.
A
So
this
is
the
flow
chart
for
Gus.
This
kind
of
lays
out
the
processes
that
it
takes,
and
you
can
see
there's
only
a
single
user
interaction
for
this
entire
flow
chart.
In
the
top
left.
You
can
see
it
says:
user
completes
Gus
migration
form,
that's
the
only
thing
the
user
ever
does
for
this
entire
process.
The
user
fills
out
the
migration
form
clicks,
the
go
button
and
they're
done.
Gus
takes
it
from
there.
Gus
will
check
their
input,
make
sure
it's
valid
check.
Their
permissions
make
sure
they're
allowed
to
migrate.
A
The
repo
it'll
create
a
JIRA
ticket
for
tracking
and
then
it'll
export,
the
repo
from
either
get
of
enterprise
or
bitbucket.
Once
the
export
is
complete,
it'll
transfer
the
bundle
up
to
s3
and
it'll
update
your
ticket
to
say
that
the
export
was
successful
from
there.
The
second
half
of
Gus
takes
over
on
the
destination,
github
appliance
it'll
download
the
repo
bundle
from
s3
process,
conflicts
on
the
repo
and
generate
a
custom
conflict
CSV
file,
and
then
it
will
import
the
repo
into
github.
A
Using
that
custom
conflicts,
file,
repo
will
be
unlocked,
the
JIRA
ticket
will
be
resolved
and
the
repo
is
ready
to
use
in
github
if
anything
happens
along
the
way.
That
goes
wrong.
There's
an
error
so
like
that
it'll
update
the
dirt
ticket
with
the
arrow
details
and
escalate
it
to
our
support
team
for
them
to
take
a
look,
so
we
look
at
a
screenshot
of
Gus.
This
is
what
it
actually
looks.
Like
text
is
a
little
small
up
there,
but
that's
okay.
A
You
can
see,
there's
some
documentation,
some
links
to
our
migration
stuff
up.
There
are
some
instructions.
If
people
don't
want
to
read
the
documentation
and
some
simple
boxes
at
the
bottom,
if
you
wanted
Margarito
you
paste
in
your
repo
URL
select
to
github
or
go
send
it
to
you
can
put
in
a
repo
name
prefix.
If
you
want
and
your
email
address
and
that's
it
click.
The
green
button.
Wait
a
little
bit
and
your
repo
magically
pops
out
and
github
ready
to
go
with
all
of
its
history.
A
All
of
its
pull
requests
all
of
its
metadata,
everything
that
it
needs.
One
of
the
cool
things
that
our
engineer
did
with
this
is
he
you
work
to
mimic
the
user
interface
of
github
itself
in
the
migration
tool,
so
Gus
looks
very
similar
to
github.
It
really
helps
tie
the
migration
process
together
with
the
new
system
that
our
users
are
going
to
be
using,
and
you
can
also
see
up
at
the
very
top
there's
a
couple
other
tabs
up.
A
There,
we've
even
extended
Gus,
since
we
created
it
and
given
up
some
additional
self-service
functionality
to
handle
things
like
org
creation
and
a
permission
viewer,
so
some
stats
on
using
Gus.
Well
so
far,
we've
migrated
over
5,500
repos
with
get
a
better
prize.
We
see
99%
success
on
our
first
migration
attempt
with
bitbucket.
A
We
see
about
90%
success,
though,
in
the
last
couple
of
weeks,
we've
even
been
able
to
shove
that
number
up
a
little
higher
by
doing
some
things
like
reducing
latency
between
Gus
and
our
bitbucket
servers,
and
also
making
sure
that
Gus
has
enough
resources
to
handle
exporting
our
largest
repos
that
are
in
bitbucket
or
average
migration
time
for
repos
forget
of
enterprise
takes
about
15
minutes,
doesn't
matter
how
big
the
repo
is.
Brew
bucket
takes
30
minutes,
plus
an
hour
for
every
thousand
pull
requests.
A
The
main
reason
that
bitbucket
takes
a
bit
longer
is
everything's
being
done
over
the
REST
API,
so
there's
pagination
involved
if
you've
got
a
whole
lot
of
data
coming
out.
There's
a
lot
of
HTTP
overhead
things
like
that.
Just
takes
a
bit
longer.
One
of
the
cool
things
that
that
were
is
an
example
of
the
collaboration.
We're
hoping
to
see
more
from
going
to
github
is
originally
we're
only
migrated
a
single
repo
at
a
time
it
just
has
you
pasted
in
one
repo
click
the
button?
A
That's
it
well,
one
of
our
dev
teams
took
a
look
at
Gus,
figured
out
the
right
way
to
submit
an
HTTP
request
to
it
and
figured
out
that
it
was
possible
to
script
submitting
migration
requests
to
Gus,
so
they
were
able
to
write
up
a
list
of
all
the
Reba's
that
wanted
to
move,
make
sure
they
were
ready
to
go
and
then
write
a
script
to
submit
them
all
through
Gus,
all
at
once.
They'd
queue
up,
100,
120,
different
repos
to
Mike
and
Gus
was
just
chew
through
them
over
the
next.
A
You
know
period
of
hours.
This
script
was
done
pretty
much
without
our
interaction.
They
came
to
us
said:
hey,
we
wrote
the
script
and
a
migration
repose,
that's
good!
That's
awesome!
Give
it
to
us:
let's
get
it
on
our
site,
let's
share
it
and
we've
since
had
a
lot
of
other
developer
teams
that
have
been
using
the
same
script,
enhanced
it
with
their
own
requirements.
It's
been
a
great
way
to
lower
teams
to
move
things
over
in
bulk,
once
they're
ready
to
go
without
having
to
go
through
the
user
interface
a
whole
bunch
of
times.
A
So
we
can
look
at
some
of
the
statistics
of
migrating
things
with
Gus
so
know
the
numbers
are
pretty
small
in
here
and
that's
okay,
that
the
the
shape
of
the
line
is
really
the
more
important
thing
here,
and
this
is
showing
our
migrations
over
time.
The
red
line
is
migration.
Request
created
the
Green,
Line
is
migration
request
completed,
and
you
can
see
that
when
you
first
introduced
Gus
a
little
over
a
year
ago,
we
migrated
our
first
instance
pretty
quickly.
A
We
did
about
2,500
repos
in
about
a
month
and
a
half
things
slowed
down
for
a
little
bit
after
that,
and
then
you
can
see
at
the
beginning
of
this
summer,
we
added
a
couple
more
instances
to
Gus
and
a
repos
of
migrations
have
taken
off
again.
The
really
cool
thing
about
this
graph,
though,
is
that
you
can
see
that
the
two
lines
tracked
very
closely
on
top
of
each
other,
and
that
really
shows
the
impact
of
automation
and
how
successful
it's
been.
A
We
can
clearly
see
that
a
migration
request
comes
in
Gus
migrates,
it
Gus
closes
it
moves
on
to
the
next
one.
We're
not
seeing
a
lot
of
waviness
where
Gus
was
struggling
or
having
problems.
We
can
look
at
the
same
data
in
a
slightly
different
form.
If
you
look
at
the
non-cumulative
graph-
and
it
looks
a
bit
more
like
this,
so
we
can
see
that
this
is
the
same
thing
again.
A
Red
line
is
my
cursor
of
Gus
created,
Green
Line
is
migrations
completed,
and
you
can
see
that
the
two
lines
have
basically
the
same
pattern,
and
that
just
shows
us
that,
even
when
we
get
up
to
100
120
migration
requests
in
a
single
day,
Gus
is
doing
this
job.
It
sees
them
migrate
them
through
chews.
Through
all
the
migrations.
We
don't
see
a
lot
of
impact
or
support
team
from
it.
A
So
that's
great
we've
got
our
automated
migrations,
but
that
doesn't
cover
all
of
our
code
bases
we're
trying
to
centralize.
So
we
have
some
other
migration
methods
as
well.
We
call
them
assisted
migration.
This
is
if
you're
migrating
from
github,
calm
or
perforce.
This
still
includes
your
full
history.
All
your
pull
requests
all
your
issues,
projects
things
like
that,
but
they
have
to
be
scheduled
with
our
support
team.
So
it's
something
that
takes
a
bit
of
effort
on
our
part,
there's
a
bit
of
manual
work
involved,
but
these
could
be
automated
through
Gus.
A
If
they
became
requirement,
we
don't
have
a
whole
lot
of
code
and
get
into
common
perforce
as
moving
over.
So
we
haven't
done
that
yet,
but
it's
always
an
option
and
find
there's
just
a
plain
old
manual
migration,
basically
just
doing
a
gift
phone
and
get
push
anybody
can
do
that
doesn't
require
anything
from
the
sport
team.
It's
totally
self
service.
A
You
still
get
your
full
commit
history,
you
just
don't
get
pull
requests
or
issues
or
other
metadata
like
that,
but
it's
a
great
thing
to
use
if
you're,
just
moving
over
a
test,
repo,
a
hackathon
repo,
a
sandbox
repo
or
something
like
that,
so
we
might
grow
to
code
over
I've
got
a
new
system
online.
How
do
we
get
our
developers
to
be
more
efficient
in
to
collaborate
with
each
other?
Well,
for
starters,
we
want
to
get
organized
first
thing
we
do.
Is
we
created
some
standards
for
how
we're
going
to
use
github
organisations?
A
We
disable
the
ability
for
users
to
create
them
by
default,
and
we
wanted
to
make
sure
that
order
to
reuse
thoughtfully
and
carefully,
because
we
didn't
want
to
wind
up
with
a
whole
bunch
of
clutter,
in
our
brand-new
kit,
of
instance,
right
off
the
bat.
So
we
published
some
standards
for
when
an
org
is
a
good
idea
when
it's
not
and
we
limited
creation
of
orgs
to
our
senior
level
engineers
and
above
so
that
there's
some
thought
that
goes
in
to
creating
one
and
it's
not
something
that
just
spur
the
moment.
A
Somebody
can
throw
up
if
they
decide
they
want
to.
We've
also
tried
to
set
some
source
control
standards
for
our
developers
to
meet.
Now
we
want
to
make
sure
that
they
use
good
naming
conventions
for
things
like
organizations,
repos
and
teams.
We
also
want
them
to
use
discoverability
AIDS,
so
right,
good,
readme
files
use
repo
topics,
things
like
that,
and
we
want
our
developer
use
to
branch
protection
features.
We
want
to
embrace
up
a
pull
request,
driven
model.
We
want
to
make
sure
there's
code
review
on
everything.
A
People
are
looking
at
things
and
giving
their
feedback,
and
we
want
our
developers
to
define
a
contribution
process
to
the
repost,
make
sure
they're
adding
a
contributing
MD
file
that
lays
out
what
the
code
that
they're
using
is
how
they
expect
it
to
be
used.
What
kind
of
standards
they
want
it
to
meet.
Things
like
that.
A
We
want
to
make
sure
our
repo
containers
are
clearly
noted
and
clearly
identified
and
that
they're
paying
attention
to
their
repos,
and
we
want
to
make
sure
that
our
developers
are
all
comfortable
working
with
pull
requests
and
Forks
and
so
their
primary
means
of
doing
collaborative
development,
so
how
we
try
to
encourage
collaborative
development.
Well,
we've
created
an
internal
inner
and
open-source
foundation
at
Expedia
group.
This
is
a
team
that
has
broad
representation
across
the
company.
A
It's
not
limited
any
one
brand
or
any
one
part
of
the
company
and
their
mission
is
to
develop
standards
and
best
practices
for
code
development,
collaborative
development
working
together.
Things
like
that
they're
also
there
to
try
and
communicate
the
message
of
collaborative
element.
What
are
the
benefits
that
can
be
gained
from
it?
Why
is
it
valuable?
Why
is
it
worthwhile?
Why
is
it
something
we
should
be
trying
to
do?
They
also
try
to
foster
a
bit
of
a
community.
Get
people
talking
about
working
together,
get
sharing
stories.
Things
like
that.
A
One
of
the
things
they've
done
is
set
up
what
we
call
lean
coffee
sessions.
These
are
basically
informal
meetings
between
developers
on
different
teams
that
are
happens
for
to
spontaneously
at
our
offices
around
the
globe,
and
the
point
is
just
to
get
together
talk
about
what
you're
working
on
talked
about
your
challenges.
A
Finally,
we
also
want
to
make
sure
that
we
celebrate
our
successes
with
collaborative
development.
This
is
a
big
shift
in
development.
For
us,
it's
something
we
are
developers
weren't
super
familiar
with
before
we
want
to
make
sure
that
people
know
when
it's
gone
well,
know
when
it's
been
a
good
idea
and
when
things
have
worked
out
for
them,
so
write
some
blog
posts
about
it.
A
If
you've
found
someone
else's
project
and
you
used
it-
and
it
worked
really
well
make
sure
people
know
about
that,
make
sure
people
know
that
you
work
together
with
them
and
that
it
really
save
you
time
and
effort,
and
that
sort
of
thing
it's
also
great,
to
bring
these
things
up
in
product
reviews
of
leadership.
Leadership
gloves
to
hear
when
things
have
gone
well
and
you've
done
good
things
so
make
sure
they
know
about
it.
A
Tell
people
that
I
worked
with
this
developer
in
you
know
the
other
side
of
the
continent,
and
we
came
up
with
this
project
together
and
you
know
we
both
had
a
need
and
we
both
made
it
happen-
make
sure
that
people
know
that
you've
had
that
kind
of
success
with
collaboration,
and
we
also
want
to
make
sure
that
teams
don't
just
have
plain
roadblocks
blocking
them
for
trying
to
work
in
a
collaborative
model.
For
starters,
it
seems
really
simple
but
use
a
public
repo.
A
A
Seeing
your
code,
everyone
else,
seeing
what
you're
doing
another
part
of
that
is
to
get
used
to
working
with
a
fork
based
reflow
using
a
fork
on
a
public
repo
means
that
you
can
commit
pull
requests
back
to
that
source
repo
without
even
needing
write
permissions
on
it.
That's
a
common
paradigm
in
the
open-source
world
on
github.com,
something
our
developers
haven't
been
very
familiar
with
so
far.
It's
also
important
that
our
developers
are
open
outside
ideas
in
the
past,
they've
really
owned
their
systems
themselves.
A
They
felt
like
it
was
their
thing
to
decide
how
it
was
used,
ick
Tait
what
people
did
with
it,
but
that's
something
to
really
get
away
from
in
the
collaborative
mindset.
It's
really
important
to
avoid
an
ownership
mindset
if
you're,
maintaining
a
repo
you're,
really
more
of
a
guide
of
that
repo
you're
there
to
make
sure
that
it
moves
in
the
right
direction
that
people
are
making
worthwhile
changes
to
it.
But
you
don't
really
control
and
dictate
exactly
how
people
take
advantage
of
it.
It's
good
to
kind
of
think
yourself
more
like
a
park
ranger.
A
If
you're
going
to
a
national
park,
the
Ranger
doesn't
own
the
park.
He
doesn't
tell
everyone
exactly
what
to
do
there
instead
he's
just
there
to
make
sure
that
you
take
advantage
of
the
features
of
the
park
in
a
safe
way
that
he
keeps
the
place
tidy.
That
keeps
it
ready
for
the
next
person
and
finally
make
sure
that
our
developers
review
their
pull
requests
promptly,
there's
nothing
worse
than
finding
a
repo
out
there
that
can
really
help
you.
It
needs
a
to
line,
changes
to
make
it
work
with
your
environment.
A
You
submit
a
pull
request,
it's
really
simple,
and
then
you
hear
nothing.
Two
weeks
go
by
nobody's
gotten
back
to
you,
it's
just
the
worst
thing.
You
really
want
to
use
their
code.
You
don't
want
to
just
completely
fork
the
thing
yourself,
but
nobody
will
get
back
to
you
about
one
and
never
merge
your
pull
request.
So
pay
attention
to
your
pull,
request,
provide
honest,
unbiased,
helpful
feedback
and
do
it
quickly.
A
So
how
do
we
measure
success?
How
do
we
know
if
this
project
have
been
successful?
Well,
for
starters,
we're
using
something
called
Autodesk,
Hubble
Hubble
was
demonstrated
here
at
universe
a
couple
years
ago.
It's
essentially
an
application
that
crawls
your
github
instance
and
it
generates
statistics
of
your
development
activity,
so
it'll
create
some
reports
on
all
of
your
practices
and
things
like
contributions
to
orgs
total
contributors,
pull
request,
usage,
fork,
usage
system
activity,
there's
tons
of
different
statistics
that
it
has
it's
a
free
application.
A
It's
on
github,
you
can
go
download
yourself
and
turn
it
loose
on
your
own
github
and
you
might
find
something
out
specifically
we're
really
interested
in
the
collaboration
graph.
So
it
looks
like
just
a
whole
bunch
of
colors
bunch
of
lines
everything,
but
it's
actually
showing
when
our
developers
are
contributing
to
organizations
outside
of
the
sort
of
home
org
that
they
normally
live
in.
So
as
we
see
more
collaboration,
we
should
hopefully
start
seeing
more
and
more
of
these
lines
connecting
different
segments
together
as
it
stands
right
now.
A
This
is
the
the
actual
graph
from
Expedia
group
github
at
the
moment,
and
if
we
zoom
in
a
little
bit
on
one
org,
we
can
see
that
org.
One
here
has
seen
a
little
bit
of
collaboration.
They've
contributed
to
our
organizations
and
they've
received
the
contribution
of
another
one.
So
it's
a
good
start
and
we
hope
to
see
more
of
that
in
the
future.
A
So
what
kind
of
lessons
have
you
learned
from
doing
this
whole
thing
well,
for
starters,
avoid
some
things
to
avoid
avoid
overly
rigid
thinking.
It's
really
easy
to
get
fixated
on,
trying
to
do
things
perfectly,
trying
to
come
up
with
the
absolute
best
of
everything
and
actually
doing
things
the
perfect
way
all
the
time
and
that's
just
unrealistic.
You
really
can't
expect
everyone
to
be
able
to
work
the
same
way.
Teams
have
different
needs,
different
requirements,
different
skill
levels,
you're
gonna,
have
teams
that
are
technically
advanced
and
teams
that
are
a
bit
more.
A
You
know
behind
the
times,
and
you
still
need
to
support
all
of
them.
Your
system
still
needs
to
support
all
of
them,
so
it's
important
that
you
be
flexible,
be
willing
to
adapt
to
what
your
team's
need
and
don't
get
caught
up
on,
trying
to
be
the
absolute
latest
and
greatest
all
the
time.
So
I
can
make
sure
that
you
listen
to
your
users.
Your
users
are
the
ones
that
are
having
to
deal
with
what
you've,
given
them,
so
pay
attention
to
their
sources
of
friction.
What
are
their
unique
challenges?
A
A
It
might
just
be
that
a
small
tweak
to
your
your
design
will
make
things
so
much
easier
for
them,
or
it
could
even
be
that
they
just
aren't
aware
of
a
certain
feature
in
github
and,
if
you
explain
it
to
them
and
how
it
works,
have
a
face-to-face
conversation
you'll
be
able
to
get
them
started
on
the
right
foot,
and
let
me
feel
much
more
confident
and
comfortable
with
migrating
to
new
system
and
having
to
move
all
their
code
over
basically
ignoring
your
users.
You
could
miss
out
on
some
really
big
wins.
A
Noakes
has
be
some
of
the
best
things
to
celebrate
is
if
you
find
a
problem,
they've
had
solve
it
for
them
and
then
they're
more
efficient
as
a
result.
And
finally
you
don't
want
to
ignore
reality.
We
all
have
technical
debt,
it's
a
thing.
It
exists,
we
don't
like
it,
but
we
all
have
to
deal
with
it
as
much
as
we'd,
like
all
of
our
developers,
to
be
writing
micro
services
that
are
containerize
and
auto
scaled
and
all
that
sort
of
stuff
it
just
doesn't
exist.
A
Everybody
isn't
ready
for
that,
and
it's
something
that
you
just
can't
expect
so
pay
attention.
Your
technical
debt
make
sure
that
you've
addressed
it
and
that
you're
supporting
it
and
that
your
system
isn't
leaving
behind
some
of
the
legacy
teams
that
are
still
maintaining
code
that
is
critical
to
your
business.
Now.
That
said,
you
also
don't
want
to
try
to
cover
100%
of
every
use
case.
A
You're
going
have
those
teams
out
there
that
have
just
never
had
a
good
reason
to
change
their
practices,
they're
still
using
some
old
waterfall
deployment
process,
they're
still
eating
some
awful
batch
file,
script
deployment
system
or
something
like
that.
They
have
no
way
to
pass
ooofff
tokens
to
github
in
a
secure
way.
Those
are
the
teams
that
you're
going
to
want
to
really
talk
to,
because
you
probably
don't
want
to
compromise
your
design
to
support
what
they're
trying
to
do
the
migration
project.
A
A
So
some
key
takeaways
from
this
whole
thing
that
we
can
work
on
well.
For
starters,
these
migrations
take
time.
We've
been
going
at
this
for
almost
two
years.
Now
it's
probably
going
to
be
another
year,
maybe
even
two.
It's
a
long
project.
There's
a
lot
of
stuff
going
on,
so
be
ready
for
that.
So
as
part
of
that,
you
want
to
set
reasonable
deadlines
for
your
users,
but
you
want
to
hold
them
to
it.
A
The
worst
thing
is
when
you
try
to
say:
okay,
let's
get
this
done
by
May
1st
and
then
April
30th
comes
around.
They
go!
Oh
yeah.
We
didn't
get
started
on
that
you're!
Never
gonna
get
done.
If
you
let
that
stuff
happen
too
often,
it's
important
that
you
get
teams
involved,
get
them
the
information
they
need,
make
sure
they
can
move
forward
and
then
hold
them
to
a
deadline
to
make
sure
they
actually
get
it
done
also
automate
and
self-serve
as
much
as
possible.
A
The
more
you
can
get
teams
doing
the
work
for
Migration
themselves,
the
less
you
have
to
do
so.
Put
your
legwork
in
up
front.
Get
your
migration
tools
in
place.
Get
your
automation
place,
get
your
documentation
in
place,
and
you
let
teams
be
able
just
do
it
on
their
own
things
just
happen,
while
you're
sleeping
it's
great
to
leave
work
one
day
and
come
in
the
next
and
find
the
200
repos
got
moved
into
github
overnight,
and
you
didn't
lift
a
finger
also
find
ways
to
encourage
passion
and
excitement
with
your
project.
A
New
systems
can
be
cool.
They
can
be
exciting,
like
getting
frustrated
and
bogged
down
with
some
old
system
that
has
horrible
network
connectivity
or
poor
performance,
or
something
like
that
when
they
find
a
way
to
get
your
users
excited
that
they're
gonna
have
something
new
that
can
do
cool
new
things.
You
know,
if
you
come
to
universe,
and
you
see
some
great
features
added
to
github,
communicate
that
to
your
users.
A
Make
them
realize
that
hey
when
we
get
onto
github
you're
gonna
be
able
to
do
this
this
and
this,
and
you
can't
do
that
right
now.
Anything
you
can
do
to
get
users
to
get
excited
about
the
project
they're
doing
get
them
talking
to
their
co-workers
about
how
much
better
it's
going
to
be
when
they
move
to
their
system.
That's
nothing,
but
a
good
thing.
It
just
tells
people
get
on
the
same
page
as
you
and
be
willing
to
forward
and
make
the
changes
that
are
necessary
to
make
a
project
like
this.
A
A
success
keep
management
up-to-date
with
successes.
The
executive
that
made
the
decision
to
make
this
all
happen
in
the
first
place.
He's
gonna
love
it.
When
you
get
to
go
to
and
say
hey
that
big
decision,
you
made
that
thing
that
you
took
a
risk
on
it's
paid
off.
We've
done
all
of
this.
We've
made
all
these
things
happen.
Everybody
is
this
much
more
productive.
We've
been
able
to
deploy
this
much
faster.
You
know
whatever
it
is,
whatever
you've
got
to
communicate,
how
great
things
have
been
make
sure
they
know
about
it.
A
They
love
to
hear
when
their
decisions
have
led
to
good
things.
That
said,
make
sure
they
know
about
your
challenges.
To
these
kinds
of
projects
always
come
with
conditions.
There's
always
things
that
you're
you're,
trying
to
figure
out
that
you're
still
working
through
that
aren't
ideal
right
at
the
moment,
make
sure
they
know
that
you're
you're
working
on
them.
A
So
they
know
that
you're
making
progress,
but
that
you
have
a
path
forward
and
you
have
a
process
to
make
sure
that
you
solve
the
problem
and
that
you
can
move
on
and
finally
keep
your
head
up.
These
projects
are
huge.
It
there's
so
many
teams
involved.
We've
delivered
have
been
talking
to
people
across
the
entirety
of
expedia
group
in
every
office.
A
We
have
trying
to
make
sure
that
we
can
get
them
on
board
and
that
they're
able
to
move
the
code
over
and
that
every
all
of
their
deployment
systems
and
integration
system
build
systems
are
all
working
correctly.
It
can
be
really
easy
to
kind
of
get
bogged
down
and
start
to
worry
about.
How
were
ever
going
to
accomplish
this
for
everyone?
How
everybody's
ever
going
to
be
happy?
A
It's
a
long
project
but
keep
moving
forward,
pay
attention
to
what
your
users
want
and
solve
the
problems
talk
to
them
and
stay
on
the
same
page
as
them
and
you'll
find
that
you'll
just
keep
moving
on
and
that
graph
I
showed
you
earlier
we'll
just
keep
creeping
up
things
just
keep
moving
forward
so
be
confident,
know
what
you're
doing
and
take
care
of
things
for
users,
and
everything
will
turn
out
fine.
So
that's
all
I
have
for
today.
If
you
have
any
questions
or
comments,
feel
free
to
come
up
afterwards.