►
From YouTube: Building GitHub - GitHub Satellite 2016
Description
Building the technology that powers the world's largest code host is a challenge. Dirkjan explores GitHub's internal tools, processes, and technologies behind the scenes and look at what it takes to meet this challenge. GitHub uses GitHub to build GitHub, and in this talk he'll show you how.
Dirkjan Bussink joined GitHub in December 2013 and is currently the engineering manager for GitHub Enterprise.
About Satellite:
GitHub Satellite 2016 was a celebration of the latest and greatest in development. Watch the recordings to learn how engineers, founders, activists, and beyond tackle the latest and most difficult challenges in software.
For more, join us in San Francisco on September 13th-15th for GitHub Universe, three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
How
do
we
internally
use
their
own
products?
What
are
the
things
that
we
do
outside
of
just
our
own
product?
What
are
the
things
that
you
know
we
automate
and
we
do
and
we
build
around
our
products
like
we
use
things,
and
we
do
things
that
you
know
not
the
product
of
product
itself
doesn't
always
solve.
We
have
the
same
problems
in
the
same
things
that
a
lot
of
people
probably
also
have
and
might
recognize.
A
A
Everyone
probably
knows
that
you
know
we
always
we
there's
been
a
lot
of
talks
about
like
how
we
use
github
to
build
github.
So
one
of
the
things,
of
course
we
do
is
use,
get
up
a
lot.
So
for
a
recent
feature
that
we
build
is
this
case
where
you
know
we
build
pre
receive
hooks
or
enterprise
2.6,
which
is
one
of
the
things
that
we
also
do
as
our
as
our
team.
We
build
those
kind
of
specific
features,
so
that's
outside
of
the
just
packaging
in
box.
This
is
another
thing
we
do.
A
One
of
the
things
we
just
try
to
like
describe
the
feature
try
to
like
summarize
discussions
we
have
so
in
this
case
we
had
a.
We
were
together
for
a
meetup
in
real
life
with
everyone,
and
we
discussed
about
this
topic
because
you
know
there
was
a
lot
of
like
technical
details
and
problems
and
things
we
had
to
solve
to
solve
this.
To
tackle
this
problem,
but
we
also
like
we
don't
want
to
keep
that
conversation
isolated
in
just
an
in-person
meeting,
so
it
always
means
you
know
we
try
to
write
up
the
summaries.
A
We
write
up
what
we
discuss
what
we
talked
about,
also
for
other
people
who
are
not
there,
we're
now
able
to
make
it
so
they
can
contribute,
and
they
can
also
be
part
of
this
part
of
this
discussion.
So
this
is
kind
of
like
ends
up.
We
talk
about
this
whole
thing
and
we
try
to
usually
work
on
on
all
those
things.
So
we
don't
only
do
that
with
issues.
We
also
do
that.
Actually,
a
full
request,
like
we
don't
use,
pull
request
just
for
code.
A
We
also
use
it
a
lot
for
our
internal
documentation
or
internal
process
and
our
internal
priorities.
So
this
case
this
is
like
our
future
priorities
like
deliberately
there's
no
content
here,
because
this
is
talking
about
the
things
we
will
be
doing
and
like
the
next
six
months.
Probably,
but
we
start
this
discussion
by
opening
a
pull
request
and
somebody
who
has
some
ideas
in
this
case.
It's
Daniel
he's
part
of
the
product
team.
He
started
out
with
some
suggestions
about
like
hey.
A
These
are
some
of
the
things
we
want
to
work
on
in
the
future
on
get
up
enterprise.
What
does
everybody
else
think
you
know
what
are
the
opinions
of
people
in
the
team?
What
to
think?
What
do
we,
as
a
team
think,
is
important?
What
is
the
external
like?
What
do
our
customers
ask
of
us
and
like?
How
do
we
combine
those
things
into
actually
integrating
and
building
those
in
their
products?
A
These
are
the
things
and
Reese
discussions
about
while
we're
doing
it,
and
if
somebody
has
a
question
of
like
hey,
why
did
we
do
this
solve
this
problem?
In
a
certain
way,
they
can
always
look
back
and
see.
Oh,
this
is
where
the
discussion
was.
This
is
how
how
it
went.
We
use
a
lot
of
checklists,
so
this
is
part
of
like
how
we
break
down
feature
development.
A
We
just
put
it
into
like
awesome,
which
a
big
checklist
of
like
we're
working
on
this
thing
first-
and
this
is
like
the
specific
parts
of
building
this
feature
in
this
product,
so
this
is
kind
of
the
same
problem
around
we
had
with
the
pre
receive
hook,
so
it
talks
about
like
these
are
some
of
the
steps
we
need
to
take.
We
need
to
set
up
like
an
environment
in
which
these
hooks
run.
A
We
need
to
set
up
that
they
just
don't
not
only
run
if
you
push
code,
but
also,
if
you
do
like
a
web
edit
and
all
those
all
those
kind
of
things
so
and
those
kind
of
like
lists,
evolve
and
change
over
time.
It's
not
like
when
you
write
this
list
and
it's
like
static
and
you
never
change
it.
It's
like
a
continuously
developing
process
where
somebody
realizes
hey,
we
missed
this
thing
or
somebody
starts
building
something,
and
it's
like
wait.
This
is
not
going
the
right
way.
A
A
So
if
you
know
sometimes,
you
start
something
with
a
really
small
question
and
something
that
seems
really
innocent,
but
you
end
up
talking
about
the
problem
and
discussing
it
way
deeper
than
you
originally
anticipated.
So
what
we
do
is
like
we
take
those
links
to
those
discussions
may
be
summarized
them
in
an
issue
or
ProQuest
and
add
a
reference
to
like
hey.
This
is
where
people
can
read
our
discussions
where
people
can
read
about
how
we
did
things,
especially
like
on
our
team.
A
It's
really
important
to
make
those
things
transparent,
so
the
team
I'm
on
is.
We
don't
have
anybody
who
lives
in
the
same
city
as
anybody
else
on
the
team
so
we're
mostly
based
in
Europe
and
the
US,
but
it
means
like
whatever,
but
somebody's
working,
there's
always
like
a
good
chance
that
have
some
team
is
asleep
that
they're
not
around
and
that
you
cannot
do
like
a
really
quick
question
with
them.
A
So,
like
people
read,
the
chat
backlogs
might
actually
comment
on
a
chat
discussion
like
five
hours
later,
when
they
wake
up
because
they
have
like
a
new
point
of
feedback
or
a
new
insight
into
this
problem
that
some
other
colleagues
were
discussing
later
and
that's
like
fine
to
know
it's
like
that's
something
we
try
to
encourage
and
that's
something
we
try
to
be
able
to
embrace
that.
You
know
that's
a
very
nature
of
asynchronous
communication
and
that's
a
very
nature
of
how
those
things
work.
A
Other
things
we
do
with
chat
and
tooling
around
that
and
automation
is.
We
do
a
lot
of
things
with
operations
and
chats
in
this
case.
This
is
a
graph
of
I.
Think
last
week
of
the
number
of
the
ploys
that
happened
on
github
com,
so
you
can
see
it's
around
total
around
400
deploys
to
the
website
in
a
week
which
is
fairly
common.
It's
a
pretty
normal
normal
week.
A
So
this
is
the
thing
we
is
available.
I
can
deploy,
so
I
can.
Actually.
This
is
like
I
did
a
bug
fix
and
I
deployed
it
to
production
and
was
able
to
merge,
merge
the
issue,
so
this
is
also
something
that's
like
a
very
day
to
day
work
flow.
This
is
the
kind
of
thing
that
you
know
you
do
every
day
you
try
to
automate
and
try
to
improve.
I
think
that's
for
us.
That's
a
really
important
part
of
all
these
things
that
I'm
talking
about
today
is
like.
A
How
do
you
make
this
process
for
yourself
easier,
and
how
do
you
make
this
smoother
and
happen
every
day
and
make
it
a
part
of
your
day
to
day
routine
instead
of
making
deploying
or
dating
or
changing
your
website
really
intensive
and
heavy
heavy
process?
This
is
another
example
more
specific
to
our
our
internal
process.
For
enterprise,
so
I
don't
know
if
everybody
saw
image
tragic
last
week.
A
This
is
about
this
case,
so
with
a
negative
enterprise,
we
have
multiple
versions
that
we
support
for
our
customers,
like
not
everyone
once
to
always
upgrade
to
the
last
feature
release,
so
it
means
in
this
case
we
support
like
we
have.
The
last
version
is
2.6
that
we
release,
but
we
still
support
2.5
and
up
until
2.2,
with
security
fixes
and
critical
updates.
In
this
case,
image
tragic
could
lead
to
remote
code
execution,
so
it
was
fairly
critical
that
we
actually
release
a
buck
figs
and
a
security
fix
for
all
our
supported,
supported
versions.
A
So
this
case,
what
we
do
is
we
deploy
a
fit.
We
write
a
fix.
We
always
merge
it
and
continuously
integrate
on
masters.
So
we
try
to
like
masters
always
green
master
is
always
something
that
we
can
deploy
a
test
instance
with
with
enterprise,
but
we
also
keep
these
branches
for
longer
running
and
maintain
versions.
So
in
this
case,
what
we
do
we
have
built
tooling
around
making
automating
that
process
for
us
like
we
don't
want
to
be.
A
A
We
do
like
a
weekly
team,
but
that's
not
like
obligatory,
so
if
somebody
can
make
it
if
somebody's
traveling
or
somebody's
like
oh,
it's
like
super
early
for
me,
I
don't
want
to
be
there
every
week.
That's
totally
fine.
It's
like
we
use
the
first
time
the
guys
I
had
high
bandwidth
discussions,
but
also
has
like
a
social
mechanism.
Since
we
work
all
together,
it's
good
to
kind
of
see
faces
every
week,
even
though
it's
not
really
about
the
content
of
the
meeting.
A
It's
just
nice
to
hang
out
a
little
bit
virtually
and
to
talk
to
people,
and
the
last
thing
is
what
we
do
is
like.
We
try
to
meet
up
in
real
life
at
least
twice
a
year
with
everybody
to
socialize
and
I.
Think
that's
a
very
important
part
of
if
you're,
a
company
that
like
forget
up.
We
really
embraced,
like
the
the
culture
of
being
able
to
work
remotely
to
be
able
to
work
wherever
you
are
I.
Think
like
for
me
personally
and
I.
A
Think
for
their
companies,
like
a
big
value
of
that
is
that
you're
able
to
work
with
some
of
like
the
best
people
all
over
the
world
and
you're
not
constrained
to
only
having
people
in
like
Silicon
Valley
or
only
in
Amsterdam
or
wherever
you
are
as
a
company,
but
that
you're
allowed
you're
able
to
get
people
from
everywhere.
I
think
that,
as
part
of
the
company
you
have
to
accept
that
part
of
that
is
also
means
that
you
know
those
people
want
to
meet
up
with
each
other.
A
They
want
to
bond
socially,
because
you
know
it's
a
lot
easier
to
communicate
with
somebody
virtually
and
chat
and
all
those
things
if
you
actually
know
somebody-
and
you
know
it's
like
oh,
this
is
the
way
they
communicate.
This
is
their
style
of
talking.
Oh,
this
is
the
kind
of
the
way
they
make
jokes
and
all
those
things
are
always
very
good
to
know.
Also
in
like
the
virtual
conversation,
because
it
prevents
a
lot
of
potential
misunderstandings
or
like
hey.
Why
did
you
say
that
that
way?
A
It's
like
oh
yeah,
that's
their
style
of
communication,
especially
if
you're
with
like
a
group
of
people
for
whom,
like
English,
is
not
their
first
language.
So
you
always,
you
know
it
can
be
not
not
a
thing
like.
Maybe
they
use
an
expression,
that's
not
familiar
for
a
for
other
people
on
the
team
and
all
those
things.
So
it's
really
important
to
us
to
do
that
embrace
that.
So
that's
all
good
and
you
know
everybody.
It's
kind
of
interesting
like
when
I
talk
about
these
things
like
people.
Ask
me
like.
A
Oh
hows
it
to
work
like
forget
up
with
people
everywhere
around
thing
and
the
first
thing,
and
really
people
often
always
ask
about,
was
like
like
what
do
you
use
like
you
know,
is
like
Oh
use
get
up,
but
like
Oh,
what
do
you
use
for
chat
or
like?
What
do
you
use
for
like
videos
like?
Well,
it's
it's.
Maybe
it's
a
it's
a
useful
question,
but
it's
not
really
the
point.
So
it's
really
more
about
the
process
that
you
build
in
the
process
that
those
tools
support
like
you
can
like
you
can
use.
A
Google
hangouts
you
can
use
like
we
use
a
tool
called
blue
jeans
or,
like
there's
a
lot
of
video
conferencing
tools,
and
yes,
some
of
them
are
better
than
others,
and
some
of
them
have
like
very
specific
annoyances,
but
you
can
work.
If
you
have
a
good
process,
you
can
work
with
almost
all
of
those
tools.
That's
not
really
depart
it's
more
about
deliberately
thinking
of
like
how
do
we
want
to
work
together,
and
how
do
we
want
to
make
sure
that
we're
able
to
to
be
a
productive
and
happy
your
team
together?
A
You
know
I
was
like
I
think
like
Christmas,
you
know
it's
really
about
like
we
want
to
design
the
way
we
work
together
as
a
way
that
makes
the
people
that
work
like
making
people
happy
to
do
the
work
and
not
be
frustrated
because
you
know
I
have
yet
another
video
meeting
at
9pm
like
that's
like
for
me.
Personally,
that's
really
like
I
just
get
annoyed
by
those
things,
and
let
people
know
that
and
it's
like
I
was
trying
to
limit
those
because
they're
a
lot
more
invasive
and
interrupting.
A
Then
you
know
somebody
asking
you
or
pinging
you
a
question
on
not
at
9pm,
which
may
be
like
sometimes
feels
the
same,
but
you're
like
oh
I,
just
I'm,
not
I'm,
just
hanging
on
the
couch
and
I
can
just
answer
them
even
though,
like
it's,
all
I
need
to
set
up
a
video
meeting
like
oh
I
feelin,
go
into
my
room
and
like
set
up
my
microphone
and
like
by
my
headstone
and
all
that
kind
of
stuff.
So
it's
really
I
think
it
really
important
that
you
know
to
be
conscious
about
those
things
and
I.
A
Think
for
us
in
our
organization,
really
forces
us
to
do
that.
I
think
like.
If
you
do
you
work
as
a
person
or
is
it
in
a
company
where
you
do
have
people
who
work
remotely?
It's
really
important
that
everybody
embraces
that
remote
workflow,
not
just
a
person,
if
there's
only
one
person
outside
the
team,
while
the
rest
is
in
the
same
office
that
that's
really
when
it
kind
of
breaks
down.
If
you
have
it
set
up
like
that,
all
right.
So
the
other
thing
I
think
I
mentioned.
A
I
already
mentioned
a
few
times
that
we
do
a
lot
around
making
our
own
life
better
is
automating
those
processes.
So
we
have
a
lot
of
things
where
you
nose
like
this.
This
is
something
that's
manual
labor.
This
is
something
that
you
know
somebody
does
every
week.
Why
do
we
do
that?
Can
we
automate
that?
Can
we
make
that
easier?
A
If
you
are
able
to
ship
a
bug
fix
if
you
were
able
to
deploy
a
change
or
add
a
feature
in
like
a
matter
of
hours,
instead
of
having
to
do
that
and
do
a
release
three
three
months
later,
I
think
that's
like
super
important
and
it's
kind
of
interesting
because,
like
I
work
on
the
enterprise
product,
so
we
have
like
us.
We
do
feature
releases
every
few
months.
It's
kind
of
like
wait,
that's
not
continuous
delivery,
but
what
we
do
do
is
like
our
bill,
like
we
make
sure
that
our
bills
are
always
green.
A
We
can
deploy
a
test
instance
with
the
current
code,
as
it
is
right
now
at
every
moment
in
time.
So
it's
always
trying
to
make
sure
that
the
system
works.
The
system
is
integrated
and
the
system
is
healthy,
so
really
important,
for
that
is
you
know,
making
sure
that
it
happens
every
time
so
continuously
duration,
like
always
runs
yeah
I
always
be
fast,
and
the
big
big
part
of
that
is
like
make
sure
you
have
that
fast
feedback.
A
So
we're
talking
about
a
few
minutes
here,
what
it
does.
It
actually
builds
an
entire
getup
enterprise
products
and
runs
a
set
of
integration
tests
against
it.
So
it
does
the
whole
process
building
like
gathering
all
the
components
that
are
part
of
the
problem
and
building
them
and
run
CI
on
them.
So
we
do
a
lot
of
things
to
make
that
fast,
like
we
cache
aggressively.
So
because
it's
a
build
process
like
any
intermediate
artifact
that
you
can
cash
cash
it
so
next
time
you
build
it's
faster
because
not
everything
changes
on
every
commit.
A
A
It
across
a
lot
of
servers
really
helps
a
lot
like
if
you,
for
example,
if
we're
talking
about
the
build
that
actually
runs
github
com,
the
website,
so
that
CI
build
usually
takes
I,
think
between
one
and
two
minutes,
and
but
if
you
would
run
it
like
Sarah
Lee
on
your
local
laptop,
it
would
take
like
maybe
an
hour
or
longer,
but
we
just
farm
it
out
to
like
60.
Build
machines,
run
it
in
parallel.
A
So
you
can
get
really
fast
feedback
on
on
that
process,
because
that's
really
for
us
super
important
to
be
able
to
ship
things,
because
otherwise
we
wouldn't
do
those
400
deploys
a
day.
We
would
do
like
10
deploys
a
day
and
that
really
both
makes
you
slower,
but
it
also
increases
your
risk,
because
if
you
were
only
able
to
do
ten
to
five
a
day,
it
means
that
you
start
to
batch
out
bigger
features
and
more
changes
into
the
same
commits.
A
So
it
means
that
you're
actually
exposing
your
risk
and
improving
like
raising
your
risk
because
you're
starting
to
make
bigger
changes
and
one
of
the
biggest
factors
for
how
many
issues
you
have
like
how
big
a
change
is
that
you're
deploying
the
smaller
you
can
make
them
the
better.
It
will
be
and
the
more
safer
it
will
be
to
deploy.
But
this,
of
course,
more
than
CI
there's
not
only
see
I,
which
is
part
of
what
you
should
automate
and
what
you
can
improve
on.
So
this
is
the
exam
example.
I
mean
I
mentioned
earlier.
A
The
chat,
automation.
This
is
an
example
of
like
what
we
automate
like
deploy
should
be
easy.
It
should
be
like
deploying
your
or
updating
your
product
or
releasing
your
product,
ideally
should
be
like
one
line
of
like
one
line
to
do.
That
and
part
of
what
we
do
is
like
it
also
in
chat,
is
to
create,
like
this
collaborative
environment.
So
it's
not
just
like
the
technical
aspect
that
should
be
one
line.
A
A
So
I
was
not
like
I
was
not
involved
in
the
process,
but
when
I
come
actually
back
from
vacation,
I
could
pull
out
these
graph,
like
I,
could
pull
up
these
logs
like
I,
could
see
when
when,
in
this
case,
Daniel
did
this
part
of
the
process
so
I
feel
like
it
makes
it
really
easy
for
me
to
you
know,
talk
to
people
and
be
like
hey.
Oh,
you
know.
If
there
was
anything
any
problems,
you
know
anything
I
can
I
can
help
with
or
anything
I
can
improve.
A
On
for
next
time,
like
did
anybody
hit
any
problems,
because
I
can
just
look
at
what
what's
happening
and
see.
If
you
know
people
were
struggling
with
something
or
anything
like
that,
so
it
really
makes
it
like
a
shirt
like
command
line
environment
that
everybody's
working
in
that
allows
you
to
collaborate
together
and
see
what
everybody's
doing
and
then
a
little
bit
like
like.
How
do
we
do
those
things
so
in
this
case
the
command
you
just
saw.
A
Actually,
2.1
is
out
of
support
now,
so
it's
a
little
bit
older,
but
what
we
do
is
we
go
through
all
those
and
we
check
like
which
so
each
time
we
merge
a
pull
request
and
it
needs
to
be
back
toward
it
for
good
of
enterprise.
We
just
add
a
label
on
this
project
where
it,
which
is
part
of
going
to
enterprise.
So
what
we
do
is
you
just
look
40,
which
are
all
the
merge
full
requests
with
this
label?
A
We
go
through
each
projects.
Each
project
is
part
of
good
of
enterprise,
which
is
like
in
an
contain
another
script
which
this
list,
like
hey,
there's
like
git
up
git
hub,
which
is
like
get
up
to
calm
the
rails
application.
We
have
like
a
service
that
handles
get
traffic
and
we
have
like
a
whole
bunch
of
other
things
that
are
integrated
and
we
just
loop
through
all
these
and
search
for
them
and
generate
a
pull
request
with
the
API
that
does
the
back
part
process.
So
when
originally
we
started
this,
you
know
Enterprise.
A
This
was
kind
of
like
a
manual
process
that
people
had
to
do,
which
was
really
not
very
interesting
work.
It
was
very
error-prone
because
it's
easy
to
make
a
mistake,
so
this
is
something
we
really
are
really
on
start
to
automate,
because
we
don't
want
to
be
busy.
This
is
busy
work.
We
don't
want
to
work.
You
want
to
do
things
about
the
same
for
like
really
singing
good
of
enterprise.
A
It's
like
a
single
command
like
oh
I,
want
to
publish
261,
which
was
last
week,
and
it
just
reports,
and
after
a
while,
it
comes
back
after
a
few
minutes.
Like
hey
I've
done
this
I've
created
all
the
am,
is
in
an
AWS,
I
truncated,
a
bit,
there's
whole
there's
a
few
more
in
my
eyes
and
there's
like
links
to
images
or
like
VMware
and
all
this
other
kind
of
kind
of
supported
platforms.
A
So
this
is
also
something
like
we
don't
want
to
have
somebody
manually
trying
to
run
a
script
locally
on
their
laptop,
which
depends
on
their
local
environment.
Their
artifacts
might
be
slightly
different,
so
we
just
want
to
have
like
a
streamlined
process
and
toolchain
did.
The
dust
is
all
for
you
and
this
way
again,
I
could
see
Oh
Sergio
in
this
case.
Did
you
release
build
the
images
and
you
know
that'll
went
fine,
it
was
all
good.
So
I
was
happy
that
you
know
everyone.
It
was
all
super
smooth
and
nothing.
Nothing
really
problematic
happened.
A
So
the
question
is
like:
how
do
we
like?
How
do
we
automate
this
kind
of
things?
And-
and
so
in
this
case,
like
you
saw
the
example
we
use,
we
use
the
API
like
the
getup
API
ourselves,
internally,
very
heavily
for
all
kinds
of
automation.
So
this
is
just
one
example.
We
do
automation
about
like,
for
example,
we
have
teams
that
have
scripts.
A
Oh,
these
are
all
all
features
that
are
missing
from
github,
which
sometimes
is
something
isn't,
because
not
everything
that
you
saw
there
should
be
a
feature
like
we
have
a
lot
of
internal
processes
that
we
don't
think
are
very
specific
to
us.
You
know
it's
like
not
every
company
does
it
that
way
and
that's
adding
all
these
features
to
the
product
make
it
actually
worse,
because
you
know
there's
a
lot
of
features
that
a
lot
of
people
won't
use
and
will
be
in
the
way
for
their
workflow.
A
So
I
just
want
to
like
encourage
people
to
say
like
if
you
feel
like
hey
hit
up
the
product
is
not
solving
this
part
of
the
problem.
It's
like
yeah
look
at,
like
other
integrations,
look
at
the
ways
you
can
work
and
automate
your
own
process
around
it
because,
like
we
really
want
to
enable
like
our
platform
and
integrations
to
be
able
to
do
all
those
things
for
you
because,
like
we're,
not
we're
not
going
to
solve
everyone's
problem,
always
like
that's
not
our
goal.
A
If
you
look
at
github
com,
the
website,
it's
very
much,
you
write
a
branch,
you
push
it
up,
you
deploy
it
and
you
merge
it
like
there's
no
process
around.
Oh
I
need
to
like
backport
this
to
other
releases.
Oh
I
need
to
like
build
release,
artifacts
and
images,
and
all
those
steps
are
not
not
part
of
that
process.
A
So
it's
very
different
in
some
ways.
Sometimes
it
drives
other
other
changes.
So,
historically,
originally
I
don't
know
if
people
remember
this,
but
before
get
up
usually
only
had
like,
you
only
saw
the
last
status
check,
so
one
of
the
things
like
internally,
like
I,
don't
think
we've
could
have
built
get
of
enterprise
the
product
without
actually
having
this
feature,
because
we
need
like
a
lot
of
different
environments.
We
have
CI
builds
that
say:
oh
I
want
to
test
this
works
on
VMware
on
when
the
test
this
works
on
AWS
and
went
to
test.
A
This
works
on
hyper-v
I
want
to
test.
This
works
with
these
kind
of
settings.
I
want
to
test
this
works
with
these
kind
of
settings,
so
we
have
all
these
different
modes
and
all
these
different
ways
are
like
I
want
to
authentic
test
authentication
with
Sam.
Oh
I
want
to
test
authentication
with
ldap
like
all
these
different
aspects
and
modes
of
the
system
that
you
know.
If
you
want
to
add
that
all
into
one
big
huge
test
suite
will
take
hours.
A
No,
we
want
to
be
able
to
like
have
independent
test
suites,
that
test
those
independent
paths
and
do
those
all
in
parallels.
I,
don't
think
like.
We
couldn't
have
built
the
product
without
a
feature
like
this,
so
like
there
was
a
lot
of
internal
drive
of
like
building
these
kind
of
features,
because
we
were
starting
to
work
and
improve
the
processes
around
good
of
enterprise.
On
the
other.
A
Things
like
loose
protected
branches,
which
is
a
recent
thing
shout
out
to
tma
I-
think
he's
maybe
in
the
room
for
working
on
this,
because
we
as
Enterprise
like
we.
So
this
is
really.
I
don't
know
if
people
know
the
details
about
this
feature,
but
it
means
that,
with
protective
branches
before
you
merge,
you
bks
at
your
branch,
always
had
to
be
up
to
date
with
master,
because
you
know
there
could
be
a
change
in
master.
A
That
would
actually
break
your
bill
if
you
had
an
outdated
base
in
your
own
request,
but
it
turns
out
that
that
is
a
risk.
That's
much
more
of
a
real
risk
in
a
case
in
the
case
of
like
where
the
model
follows
the
way
that
we
deploy
and
build
get
calm
where
we
always
want
to
make
sure
that
we
run
against
master,
and
we
always
want
to
make
sure
the
code
is
up
to
date,
because
we
want
to
push
that
into
the
production
immediately
forget
of
enterprise.
A
It
was
very
much
less
of
a
concern
because
work
very
much
on
independent
features
that
really
don't
touch
each
other,
and
then
it
turned
out
that
it
wasn't
really
a
big
problem
that
you
know
if
I
just
merged
my
pull
requests
and
a
co-worker
wants
to
merge.
His
per
request
did
those
are
independent,
that
we
could
just
merge
them
together
and
we
didn't
have
to
update
one
or
the
other
based
on
which
person
was
first
emergencies
for
request.
A
So
this
is
also
something
like
whenever
there
was
a
question
like
hey
who
wants
to
test
is
internally
before
we
release
it.
I
was
like
yes,
please
like.
This
is
a
reason.
I'm
not
using
this
feature,
can
I
please
get
this
taught
like
feature
flag
on
immediately.
So
we
also
try
to
like
improve
those
things
things
internally.
A
So
the
thing
also
like
that
really
also
like
it
kind
of
shows,
like
it's
really
important
to
experiment
with
the
front.
You
look
through
the
development
process
like
try
new
things.
If
you
have
a
thing
that
always
takes
a
lot
of
time
to
do
like
automated
tests,
if
that
works
test,
if
it
improves-
and
maybe
it
sometimes
like
your
automation-
actually
see
like
encourage
you
to
say,
to
take
new
steps
and
and
see
new
things
that
you
can
actually
improve
your
processes
own
or
maybe
you
try
to
automate
something
in
it's
like
wait.
A
A
Like
one
example
was,
we
did
like
the
weekly
team
meeting
and
we
did
a
bunch
of
like
status
updates
in
that
meeting
and
it
turned
out
it
didn't
really
work
well
for
us
because,
like
it's
not
super
useful
to
listen,
everybody
talk
about
what
they
did
and
what
they're
doing
next
week
like
that
would
like
half
the
meeting
and
it
could
have
been
just
as
done
as
well
in
just
an
issue
and
just
right
up
there.
You
knows
like
this
is
what
I
was
working
on.
These
are
the
things
I
need
help
with.
A
A
So,
to
summarize
or
well
other
get
too
long,
didn't
listen
like
I
hope.
Well,
you
can
read
the
slides,
but
it
was
also
some
listening
involved.
So
really,
you
know
focus
on
your
process,
not
in
your
tools.
Most
you
know,
think
of
what
you
need
in
your
process
and
see
which
tools
kind
of
like
meet
most
of
those
goals.
A
A
If
you
do
something,
you
have
to
wait
for
half
an
hour
for
something
to
happen
like
we're,
not
always
as
good
as
about
those
things
ourselves
as
well
like
we
always
have
those
things,
and
we
really
try
to
make
work
on
them
and
improve
them
where
we
have
them
share
your
process,
automation
so
make
sure
that
other
people
see
the
automation
you're
doing
so
in
this.
In
our
case,
we
use
chat
ups,
a
lot
for
that
aspect
where
it's
like
everybody
can
see
what
everybody
else
is
doing.
A
You
can
teach
people
the
process
and
the
automation,
but
just
showing
them.
So
if
somebody
asks
like
hey
I'll
this,
this
works,
you
can
just
like
you
type
it
in,
and
they
see
the
feedback
and
see
how
it
works
and
keep
iterating
so
always
keep
iterating,
always
be
improving
and
and
make
sure
your
process
gets
better
and
better
over
time.
So
that's
it.