►
Description
Presented by:
Victor Martinez, King
Raul Pareja, King
Raul and Victor will talk about how King adopted GHE as a sharing and collaborative tool, their journey since they started with the initial setup, the need to boost collaboration between departments and game studios to follow the openness culture of the company, the challenges found in the way, how they were faced and how they've ended up with our current setup.
At Satellite 2017, attendees came to exchange cutting edge practices on how to bring together the people and tools you need to build great software. Watch the recordings to find out what GitHub's been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.
We'll be getting together again in San Francisco on October 10th-12th for GitHub Universe. We hope you'll join us for three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
Welcome
thanks
for
attending
to
our
talk
during
the
next
2025
minutes,
approximately
my
colleague,
Victor
Martinez
and
myself
Ralph
arica.
We
will
share
with
you
our
experiences
adopting
github
Enterprise
at
King.
We
will
tell
you
the
story
about
how
it
all
began
and
the
issues
we
found
in
our
journey
like
the
challenges
in
how
to
manage
an
overwhelming
amount
of
users
and
how
to
optimize
the
utilization
of
gates
from
the
continuous
integration
ecosystem
in
order
to
to
be
friendly
with
the
performance
that
the
resources
it
consumed.
A
Let
me
introduce
briefly
ourselves
Victoria
and
I.
We
are
building
configurations
engineers
and
we
work
together
in
the
engineering
systems
and
support
team.
Our
team
is
a
cross-functional
team.
We
have
people
with
different
skill
sets.
We
have
C's
engineers
working
closely
with
infrastructure.
We've
got
people
with
expertise
in
the
tools,
they
are
technical
administrators
and
we,
the
villain,
configuration
engineers.
We
work
closely
with
the
development
teams
in
order
to
work
with
them,
together
with
the
workflows
and
the
tools
for
the
continuous
integration
ecosystem,
but
we
all
together
in
our
team,
we
share
the
same
wheel.
A
We
share
the
same
goal,
which
is
to
provide
all
the
tech
teams
that
King
with
the
best
suite
and
portfolio
of
systems,
services
and
tools
in
order
to
hopefully
make
the
world
fights
better
and
at
the
end,
what
we
want
to
do
is
deliver
games
better
and
faster
about
the
company.
What
we
do
at
King,
a
team
we
make
games
for
the
mobile
wall.
We
have
a
wide
portfolio
of
fun
and
popular
games
and
we
have
for
global
franchises.
A
A
king,
we
value
a
lot
our
company,
we
have
a
strong
company
culture
which
is
raising
to
five
pillars.
Those
pillars
are
what
we
say,
what
we
call
sorry
the
King
values.
During
this
talk,
we
will
be
putting
the
focus
specials
in
two
of
them,
because
the
importance
they
took
in
some
decisions
we
made
we
in
regarding
how
we
administrate
the
github
enterprise
and
how
we
adapt
it
to
openness,
culture,
those
are
fast
and
fluid.
We
want
to
be
agile,
we
want
to
be
problem,
solvers
and
humble
and
open.
A
We
are
open
to
listen
to
share
ideas
and
those
are
the
main
values
that
we
will
be
repeating.
During
all
talk,
our
team
was
founded
back
in
2014
and
in
those
days
we
got
already
few
offices
across
Europe.
We
got
one
in
Momo
stock
hall,
in
London
and
in
Barcelona
and
in
each
location
we
got
lyrics
boxes,
running
subversion,
mercurial
and
Burgett.
A
At
this
point,
we
started
to
evangelize
the
Jews
of
get
in
the
company
and
to
provide
some
guidelines
and
some
scripts
in
order
to
help
them
to
migrate
the
subversion
of
mercurial
repositories
to
get,
but
at
the
end,
it
was
easier
than
we
expect
because
most
of
the
teams
to
be
honest
it
by
themselves,
they
were
migrating.
So
it
was
straightforward
and
little
by
little
we
started
to
migrate
some
libraries,
some
game
engines
and
we
end
up
with
the
first
game,
fully
migrated
and
we
were
very
happy.
A
We
got
all
what
we
need
to
start
moving
the
games,
possibly
from
the
old
platforms
to
get
up,
and
at
this
point
we
got
this
set
up.
We
have
held
up
by
means
of
an
active
directory,
Club
membership
in
order
to
grant
you
access
or
not
to
the
github
Enterprise
instance,
and
we
were
using
the
teams
because
in
those
days
the
github
enterprise
is
the
wait
work.
A
You
got
the
organizations
that
you
got
several
teams
and
you
granted
on
those
teams,
read
or
write
permissions
into
the
repositories,
and
here
is
where
the
fun
began,
because
we
started
to
face
the
first
issues,
especially
with
the
administration
of
the
users
and
the
management
just
to
have
some
context.
In
those
days
we
were
growing
a
lot.
We
were
opening
brand
new
offices
in
the
United
States
in
Seattle
and
San
Francisco,
and
we
were
also
opening
new
offices
in
Berlin
and
Bucharest
and
just
to
have
a
big
picture.
We
reach
the
time.
A
We're
just
in
Barcelona
office,
we
got
an
average
of
20
new
joiners
per
week,
which
was
actually
a
lot.
That
implies
a
big
queue
of
support
for
people
that
wanted
to
join
the
github.
We
got
the
dependency
on
the
active
directory
group
membership
and
we
at
at
some
point.
We
need
to
contact
the
IT
guys
that
manage
the
active
directory
in
order
to
tell
them.
Please
include
those
users
at
the
end
because
we
came
to
them
over
and
over.
A
They
end
up
back
and
overing
to
us
that
administration,
but
even
that
we
were
slowing
down,
we
were
not
fast
and
fluid.
We
were
not
a
giant,
we
were
slowing
down
the
machine
and
that's
not
the
way
that
we
wanted
to
be.
No,
so
the
first
thing
that
we,
but
that
we
opted,
is
to
remove
the
LDAP
dependency,
so
any
Active
Directory,
existing
user
@king
will
be
able
to
get
a
github
account.
A
And
furthermore,
as
long
as
you
are
inside
the
king
Network,
you
will
need
even
an
LDAP
account
just
to
read
the
code.
We
were
opening.
We
were
embracing
the
openness
culture,
but,
and
we
done
that
we
end
up
with
plenty
with
an
overwhelming
amount
of
users
claiming
for
the
right
permissions
in
such
a
dynamic
company
as
ours,
where
we
provide
the
freedom
and
the
openness
to
all
the
teams
to
create
their
organizations
wherever
they
need.
It's
really
challenging
to
keep
track
of
the
owners.
A
A
The
games
are
building
the
top
of
game
engines
and
we
got
a
set
of
libraries
and,
if
you're,
working
in
a
specific
game,
you
may
need
to
tweak
a
bit
of
a
library
and
if
you
don't
have
write
permissions,
you
can
do
some
workarounds
like,
for
example,
forking.
The
repository
create
your
own
branch,
ask
for
a
pull
request,
or
maybe
you
can
change
the
continuous
integration
scripts
in
order
to
point
to
your
own
or
to
your
own
user.
But
that's
not.
We
are
adding
the
hassle.
No,
that's
that's.
A
Why
do
we
have
more
context
why
we
need
to
to
be
more
agile
in
order
to
grant
write
permissions?
So
we
end
up
with
the
decision
to
allow
everybody
at
King
all
the
users
to
have
write
permissions
to
all
the
repositories
in
all
the
organization's,
the
CTO
and
the
pipe
and
the
BP
from
engineering.
They
got
the
feedback
from
the
teams
and
they
supported
the
openness
idea
as
it's
part
of
our
culture.
A
We
had
some
teams
that
wanted
to
be
open
that
wanted
everybody
at
King
to
contribute
into
their
into
their
code
and
at
the
end
we
took
the
decision
to
let's
remove
the
per
ears.
Let's
try
to
find
a
way
to
change
the
default
behavior
of
the
gift
enterprise
in
order
to
be
by
default,
open
doors.
At
this
point
we
contacted
the
github
enterprise
support.
A
You
know
to
have
some
guidance
and
some
some
inspiration
how
we
can
do
that,
and
we
end
up
with
the
github
Enterprise
API
to
the
rescue
by
means
of
the
github
Enterprise
API,
which
is
pretty
cool.
You
can
do
plenty
of
things,
not
everything
at
all,
but
it's
very
good.
We
started
to
cause
our
own
scripts
that
actually,
the
intention
is
to
add
all
the
active
kick
app
users
as
members
of
all
the
organizations.
A
During
this
context,
github
Enterprise
changed
the
approach
from
organizations
and
teams
to
memberships
and
that
helped
us
to
to
make
our
script
better
and
easier.
We
test
it
on
our
testing
instance
and
hands.
It
was
working.
We
said.
Ok,
let's
go
to
all
the
tech
directors
and
let's
tell
all
the
kingdom
that
a
guy's
that's
our
attention.
We
want
to
low
write
permissions
to
all
the
organizations
and
obviously
what
do
you
think
people
were
happy
with
that?
A
A
For
example,
if
you
are
working
with
some
automatic
automations-
and
you
want
to
be
pretty
sure
that
you
will
only
be
able
to
push
in
a
certain
amount
of
repositories
because
of
that
we
add
those
features
in
the
script
and
we
end
up
with
a
solution
that
works
for
everybody,
we
are
opening
all
the
repositories
to
all
the
github
users.
We
are
taking
into
account
those
organizations
that
still
wanted
to
work
your
way
and
we
were
shrieking
the
amount
of
repositories
to
certain
set
of
users.
A
Actually
we
wanted
to
take
the
chance
that
we
are
here
in
the
github
satellite
to
announce
the
release
of
the
first
version
of
this
script,
but
we
got
other
priorities
and
we're
sorry,
but
we
will
soon
provide
those
we
will
provide
to
the
community
our
script.
So
please
stay
tuned
on
the
next
slide,
as
Victor
will
point
out
to
our
tech
block.
A
A
At
the
beginning,
we
were
just
scaling
up
beefing
up
the
machine
by
means
of
providing
more
CPU,
more
RAM,
more
disk,
but
we
end
up
that
the
number
of
users
did
not
correlate
with
the
amount
of
resources
we
were
using,
and
that
was
mainly
because
our
most
active
user
is
a
continuous
integration
infrastructure
and
that's
why
we
have
Victor
here
to
provide
more
details.
So
please
Victor
thank.
A
B
Hi
everyone
so
regarding
the
performances
would
like
to
highlight
how
we
title
diseases
with
git
and
yes,
berry
mine
for
us.
Continuous
integration
is
quite
important
in
the
sense
how
it
has
been
increase,
the
usage,
so
we
started
just
to
grab
some
figures
and
back
four
years
ago
we
used
to
do
just
a
few
bills
per
day.
So
up
to
a
few
thousands
per
a
year
last
year,
we
did
about
two
million,
so
even
more
or
build
we
use
Jenkins.
So
it
could
be
any
other
tool.
B
So
that's
the
one
we
use
we
use
actively
by
every
single
side.
So
it's
about
25,
27,
ranking
instances
about
6,
700,
Genki,
millions
more,
which
are
really
static,
and
also
we
have
some
flexibility
to
run
Amazon
and
this
sort
of
things,
but
we
respecting
this
year
to
be
like
3.6
million
Bill's
such
a
lot.
So
every
year
we
are
growing
a
lot
I
mean
the
way
we
use
continuous
integration
and
the
way
we
use
github
are
really
tight.
I
would
want
to
provide
the
best
experience
to
all
the
users
and
to
reduce
the
bottlenecks.
B
So
you
see
that
we
do
have
this
practice
is
something
we
use.
Obviously,
the
first
approach
is
having
a
wiki
page.
You
say:
how
do
you
think
your
system
of
continuous
integration
exception
work?
You
just
use
naming
convention
just
say
you
do
some
git
clone
in.
Please
use
hello
clone
evil,
so
you
just
specify
some
best
practices,
but
it's
up
to
the
people
in
our
case,
to
decide
to
whether
to
use
this
or
not.
So
it's
marked
like
giving
just
some
advice.
We
run
some
trainings.
B
B
When
you
are
cloning
from
browser,
when
you're
planning
to
your
repos
to
use
by
the
continuous
integration-
and
you
need
to
ensure
the
lost
history,
you're
tracking
on
the
history,
you
might
not
really
require,
so
you
reduce
that
by
using
it
select
learning
the
impact
of
your
github
Enterprise
performance
is
really
much
better,
so
it
means
this
is
the
first
iteration
using
the
gates
aluminum.
So
you
don't
need
all
the
history.
Obviously
it
did
work
well,
but
github
support
also
help
us
to
analyze.
B
Why
we're
really
using
doing
a
github
too
much,
rather
than
trying
to
improve
the
continuous
integration?
The
first
approach
of
sorry,
the
second
approach
we
did
is
just
reducing
the
pooling
and
using
what
hooks.
So
what
who
has
been
released
back
in
2008
so
as
the
keynote
I
were
saying
that
so
it'd
been
there
for
a
while.
So
it's
a
tailor
you
can
use
and
it
will
make
sense
when
you
do
continuous
integration.
As
you
want
to
be
sure
you
test,
you
build
your
system
based
on
delays,
the
commit
you
do
know
every
five
minutes.
B
We
find
four
minutes.
So
this
is
one
of
the
cases
we
realize,
like
almost
1500
jobs
were
polling
every
minute.
It's
really
just
a
lot
and
it's
up
to
the
team
to
decide
to
move
away
of
this,
but
we
agree
between
all
the
King
engineering
teams
and
users
to
move
away.
How
do
we
tackle
this?
Just
highlighting
this
is
just
an
example
of
one
of
the
janky
jobs.
Just
highlighting
a
you
are
using
the
job
which
is
folding
your
shirt.
Do
you
want
to
use
it?
This
is
deprecated
is
affecting
the
github
performance.
B
So
let's
try
to
to
move
a
way
to
use
what
hooks
the
second
and
third
step
is
just
trying
to
remove
sorry.
This
was
going
the
second
and
the
third
step
is
more
about
encouraging
people
to
move
away
of
that
by
disable
all
the
Jenkins
jobs.
This
is
just
the
probably
the
use
case.
People
move
from
one
project
to
another
one.
B
They
are
project
that
they
are
just
dead
and
they
don't
keep
going
in
that
production
and
therefore
you
would
like
to
disable
them
because
you
don't
need
to
prove
that
you
don't
need
to
reduce
that
job
anyway,
and
this
is
the
third
iteration
we
did
to
improve
the
polling
and
by
using
pushing
this
is
really
working
well,
but
still
we
work
with
games.
We
work
with
creativity,
people
artists,
that
our
house
there
are
a
bunch
of
different
teams;
they
just
hit
up
some
of
them
just
with
large
file
systems.
B
That's
why
this
is
one
example
about
the
community.
At
Kean
we
try
to
meet
everyone
that
use
junking
that
use
github.
We
normally
would
meet
every
two
weeks
or
three
to
share
ideas,
knowledge.
How
do
you
do
these
in
your
team?
How
a
game
studio
can
develop
this
faster,
how
you
can
improve
your
workflows
and
so
on?
So
this
is
one
other
example
of
this
guy
Simon
who's
in
Berlin,
one
of
the
bill
engineers
we
have
during
Berlin,
and
he
took
the
idea
of
why
we
don't
use
get
reference,
repos
you're
familiar
with
this.
B
This
is
the
way
you
can
cache
in
the
local
system
copy
of
your
repo.
This
is
what
we
do
with
all
the
six
seven
hundred
Jenkins
slaves,
so
basically,
caching,
all
the
repos
locally
and
then
you're
changing
jobs
are
just
synchronized
with
the
particular
repo,
and
the
only
difference
is
that
the
delta
that
you
need
to
synchronize
between
the
last
night
or
whenever
you
run
your
grid
reference
repo
to
the
current
bill
that
you
are
running,
so
it
reduces
a
lot.
The
impacts
from
the
CPU
RAM
usage
and
also
it
reduce
a
lot.
B
B
This
is
something
about
the
action
with
it
were
more
about
reactive,
so
we
found
an
issue.
We
are
github
Satori.
They
have
some
best
practices
recommendation
based
on
the
CPU
load.
Log
files
on
the
bundler
based
on
our
experience,
is
writing
a
wiki
page,
but
we
want
to
up
we
like
to
add
more
Cali
quality
in
the
way
we
use
the
tools
you
can
use
to,
such
as
shown
our
PMD
check
a
style
code
code
code
see
I
also
remember
now.
B
The
name
is
just
a
few
example
that
people
use
these
tools
to
automatically
detect
whether
Jesus
best
practices
or
not.
In
the
way,
you
use
the
tools,
so
we
decided
to
do
something
similar
for
Jenkins
scene
junk
in
idea
based
on
XML
file,
jobs,
which
are
just
doing
something.
Do
we
really
apply
the
best
practice?
If
we
were
talking
it's
a
low
cloning
get
word
from
ripples
it
pushing
rather
than
polling.
B
So
we
came
up
with
a
kind
of
linking
tool
for
Jenkins,
so
it's
already
a
public,
so
you
can
download
from
from
the
junkies,
plugin
and
use.
In
our
case,
we
have
also
an
internal
solution
based
on
our
specific
requirements,
which
are
more
specific
about.
How
is
that
internally,
but
is
the
same
up?
What
I'm
going
to
talk
about
that?
So
the
call
the
name
of
this
tool
is
Dolores,
which
is
yes
a
way
of
having
fun
a
friendly
name,
which
is
exactly
the
opposite.
B
Is
you
translate
that
in
Spanish
it
means
pain,
so
we
want
to
just
make
a
joke.
How
painful
PBG
don't
use
the
best
practices
as
a
joke
yeah
we
just
do
the
name,
but
basically
it
just
analyzing
whether
you
follow
some
practices
or
not.
This
is
just
an
example
of
one
of
the
yanking
instances
we
have
in
Sweden,
so
it's
about
4000
jobs
in
there
in
that
particular
iStent
is
2
or
3
days
ago,
when
I
took
the
picture,
so
the
snapshot
display
greenie
means
more
or
less
all
the
best
practice.
B
If
you
have
it
means
people
are
using
them.
So
in
every
single
column
you
see
a
particular
rule.
Let's
say:
do
I
use
kid
polling,
then
you
will
see
in
red,
yes
or
not,
but
this
is
an
overall
picture.
You
can
have
a
better
picture
of
specific
jobs,
so
we're
trying
to
give
this
information
to
every
user
of
github
chunking
and
it's
already
integrated
with
our
wiki
page-
is
already
within
Jenkins.
So
there
are
different
ways
you
can
interact
with
this.
Based
on
the
action
we
talked
about,
keep
Salah
cloning
and
restaurant
repos.
B
Now,
in
this
case,
we
see
that
they
are
not
really
polling
anymore,
so
it's
just
using
what
books,
which
is
good.
In
other
cases,
they
are
using
its
electron
in
which
skirt
is
60%
of
Louis,
more
or
less
of
of
a
of
use
in
this
feature
by
all
the
jobs,
but
as
I
mentioned,
some
of
these
use
cases
might
not
really
imply,
might
not
really
be
required
by
the,
but
that
particular
Jenkins
job
or
team,
because
they
might
need
to
push
then
they
don't
need
to
use
shallow
cloning
get
referent.
B
Repose
is
also
quite
good
in
that
sense.
So
it's
a
overall
metric
of
60%
excessive
in
this
case,
which
is
good
again.
These
cases,
like
do
I,
do
continuous
integration
of
once
per
day
of
this
particular
ripple.
Why
do
I
need
to
cash
that
local
get
referent
repo?
It
doesn't
really
makes
any
sense
because
human,
you
might
need
more
spaces
in
your
alias
aliens.
So
this
is
just
an
overall
view
how
we
automated
practically
tried
to
encourage
to
use
these
practices
of
these
tools,
which
are
really
related.
B
Continuous
integration
on
the
github
yeah
I'll
say
now
is
what
about
how
you
use,
how
it
looks
like
a
github
we're
talking
about
what
how
was
our
journey?
What
was
the
issue
we
face,
how
we
title
these
issues,
how
we
automatically
improve
our
way
of
using
them,
but
this
is
more
or
less
an
overall
view
of
our
infrastructure.
Just
really
have
you
high
view?
We
use
pcenter.
We
have
two
instances.
They
are
synchronized
every
hour.
B
We
do
a
backup
as
well
nightly,
just
for
the
overall
view:
Phil
Han,
Cheol,
two
hundred
active
users,
two
thousand
organizations
and
six
thousand
repository,
that's
more
or
less
the
number
of
the
figures
we
have
at
the
moment.
It's
a
really
big
vCenter
server.
We
have
but
yeah
that's
more
or
less
how
it
looks
the
infrastructure.
B
What
did
we
learn
from
this
journey?
We
still
work
in
a
continuous
improvement,
but
I'll
say
there
are
three
major
topics.
The
first
one
is
about
the
culture.
How
you
use
that
culture
to
match
with
the
tool.
It
was
good
to
know
like
the
decision
worth
taking,
be
directional
from
the
VP
CTO,
and
also
from
the
engineering
team
to
elaborate
this
and
collaborate
together
to
have
a
tool
that
you
can
just
use
and
share
code
between
everyone.
So
it
really
helps
the
company
culture.
B
In
our
case,
sharing
best
practices
is
good
and
having
a
place
where
you
can
serve,
this
idea
is
even
better,
so
some
people
got
good
ideas
of
workflows
on
processes
in
our
case
is
meeting
these
users
every
two
or
three
weeks
and
just
get
the
idea
of
how
they
use
the
system.
It
really
helped
us
to
put
this
in
practice
for
sure
the
github
support
was
really
good
now,
which
means
any
issues
we
face
any
doubt
we
really
ask
them,
so
they
are
really
awesome.
B
So
you
have
any
doubt,
they're
really
kind
to
please
and
I'm
pleased
to
help
you
our
journey
hasn't
been
finished.
Yet
our
big
next
actions
are
related
with
how
we
can
improve
our
large
file
system
using
it.
How
do
we
use
locking
files
based
on
the
users
that
they
are
not
really
techie
so
as
an
artist
or
creative
or
part
of
the
creative
team,
they
might
need
a
different
way
of
using
it.
B
So
having
the
same
feature
that
you
have
in
the
public,
you
might
really
help
it's
one
of
the
feature
we
are
willing
to
use
in
the
next
release
of
the
exact
enterprise.
The
proxy
Miro
is
also
good.
Continuous
integration
is
just
one
of
the
users,
but
they
are
used
that
they
need
to
interact
from
different
sides
and
just
having
a
central
repo
at
the
moment.
For
us,
it
works
by
just
reducing
the
time
for
cloning
and
interact
with
the
children
github
in
instant.
B
Projects
peek
too
much,
so
you
have
different
yeah
sources
that
you
can
read
further
what
we
do
and
you
would
like
to
to
read
about
more
in
the
technical
aspect.
We
have
a
tape
clock
just
you
have
here
some
details
as
a
roll
mention
we're
going
to
public,
publish
this
particular
open
source
project
shortly,
and
it
will
be
some
entries
in
the
tab
block
to
teach
it
to
just
have
more
to
engage
people
to
use
this
if
they
want
to
regarded
a
the
Dolores.
B
One
was
a
really
specific
in
our
use
case,
but
there
is
a
public,
as
I
mentioned
a
public
Jenkin
instance.
Sorry,
public
kink
is
plugin
that
you
can
use
in
your
drinking
instance.
Otherwise
you
can
apply
the
same.
You
just
Travis
or
anything
similar.
You
can
apply
this
best
practices
which
are
already
de
the
last
week.
We
are
hiring
so
you
want
to
speak
with
us
afterwards,
just
please
PLEASE
wrong
and
yeah.
Thank
you,
everyone
and
yeah.
You
have
any
question.
We
can
speak
afterwards.
Thank.