►
Description
Presented by Simina Pasat, Director of Product Management, and Jamie Cool, Director of Program Management, Microsoft
As builders, we love taking a step back, learning from our users and understanding how they use the tools we build. We looked at some of the most popular open source projects on GitHub, and we talked with enterprises using GitHub for their code, collaboration and automation. In this presentation, we 'll share five lessons learned when it comes to continuous integration and deployments.
About GitHub Satellite 2019
A community connected by code
Explore our interconnected community—and how collaboration turns ideas into innovations.
Join us in November at San Francisco's Palace of Fine Arts for GitHub Universe - https://githubuniverse.com/
A
A
My
name
is
semina
passat
and
I'm
a
product
manager
here
at
github,
and
I
used
to
work
in
the
developer
space
for
the
last
years.
I
worked
on
services
for
gaming
in
xbox.
I
worked
on
mobile
developer
tools
and
now
I'm
so
excited
to
join
github
the
home
for
you
developers
and,
as
I
was
walking
here
today
to
the
venue,
I
was
so
happy
to
see
many
developers
who
made
github
what
it
is
today
and
also
many
of
our
partners.
A
B
Thanks
amita,
so
samina
told
me
about
10
minutes
ago
backstage
he
was
going
to
introduce
me
with
a
cool
joke.
I
just
kind
of
smiled
and
nodded
politely
yeah.
I've
heard
that
one
a
few
times
so
I've
been
at
microsoft
now
for
about
20
years
and
yeah.
I
know
that's
a
long
time.
Most
of
the
time
I've
spent
in
the
developer
space
in
one
form
or
another
whether
it
was
the
first
version
of
the.net
framework
visual
studio,
but
more
recently
I've
been
building
services
for
developers.
B
B
Our
customers
are
all
types,
whether
they're
external
customers,
or
whether
they're
internal
customers
like
azure
or
office,
whether
they're
small
customers
or
whether
they're
large
customers
like
windows,
who
has
somehow
a
400
gigabyte,
git
repository
for
their
source
code
and
in
the
process
of
this.
You
know
I've
seen
kind
of
more
change
in
the
cicd
space
in
our
engineering
systems
than
really
any
other
place,
and
I've
seen
the
degree
of
impact
that
makes
I've
also
seen
an
experience
in
many
cases.
B
A
A
A
It's
good
to,
firstly,
deploy
them
to
a
staging
environment,
to
a
testing
environment
where
people
in
our
teams
can
try
things
out,
see
how
it
goes.
Maybe
we
have
a
qa
department
and
when
things
are
really
good,
we
are
ready
to
try
them
and
test
them
to
we're
ready
to
put
them
to
production
when
we're
in
the
production
we're
not
done
yet.
A
We
have
to
validate
and
learn
and
to
make
sure
that
what
we
shipped
is
working
properly,
that
we
have
the
right
monitoring
in
place
that
we
listen
to
our
users
feedback
we
catch
bugs
early.
We
listen
to
our
support
channel
and,
as
you
know,
the
list
goes
on
and
on
and
on
also
the
fun
doesn't
stop
there,
because,
as
we
learn
from
our
customers,
we
are
back
to
the
coding
stage
and
it
all
goes
in
a
loop.
A
So
I
want
to
take
a
moment
and
think
about
what
build
and
deploy
means
at
github
at
github.
We
always
believed
in
the
power
of
the
ecosystem
and
the
partners
around
us
and
even
back
in
the
early
days
we
we
opened
up
api,
endpoints
and
webhooks
and
from
day
one.
We
were
amazed
to
see
all
the
great
integration
and
experiences
that
were
that
were
enabled
for
our
joint
customers,
but
no
matter
how
great
these
experiences
were,
there
was
a
big
problem.
A
People
couldn't
discover
them,
so
we
have
done
what
everybody
was
doing
introduced
the
github
marketplace
in
the
github
marketplace.
It
works
like
any
other
marketplace:
publishers
publish
their
apps.
Consumers
come
to
the
marketplace
browse:
what's
there,
they
decide
for
the
best
tool
for
them
and
they
start
using
it.
That
was
great,
but
the
journey
continued.
A
So
we
introduced
rich
integrations
things
like
the
checks,
api
and
the
check
status,
so
developers
could
use
github
to
start
to
re-run,
builds
to
see
the
code
annotations
and
all
the
details
within
github
without
leaving
the
interface
the
journey
continued
and
just
last
year
at
github
universe,
which
is
our
fall
conference
in
san
francisco.
So
at
github
universe
we
announced
github
actions.
A
Github
actions
was
more
than
ci
and
cd,
it
was
repository
automation
and
over
the
last
six
or
seven
months.
We
were
absolutely
amazed
and
humbled
to
see
all
the
ways
you
developers
to
github
actions
in
your
own
workflows
and
to
see
how
our
partners
and
integrators
to
github
actions
and
put
them
back
on
the
marketplace
in
new
workflows
for
our
joint
customers.
A
B
B
Okay,
so
the
first
lesson
is
an
amazingly
deep
and
insightful
one.
So
it
starts
with
doing
ci
is
a
good
idea.
Okay,
now
I'm
willing
to
bet
that
most
of
you
in
some
form
are
already
doing
ci,
but
ci
comes
in
a
lot
of
different
forms
right
so
from
the
simplest
and
let's
call
it
bob
ci,
and
that
basically
means
every
once
in
a
while.
Bob
will
do
a
build
using
the
machine
under
his
desk
and
then
you
deploy
that
to
every
night.
B
You
know
you'll
have
an
automated
build
that
will
run
to
every
time
a
change
goes
into
the
trunk.
You
have
a
ci,
build
that
good.
That
runs
that's
getting
better
to
every
single
change
that
before
it
gets
into
the
trunk,
has
ci
and
automation,
run
and
you're
getting
a
lot
better
now,
but
then
you're
getting
to
the
point
of.
Are
you
running
all
of
the
right
automation
as
early
as
you
can
in
all
of
the
right
places,
and
really
the
core
of
the
lesson?
B
Is
you
want
to
be
running
as
much
automation
as
early
as
you
can
in
the
process,
because
the
earlier
you
run
the
automation,
the
higher
return
you're
going
to
get
because
you're
going
to
find
these
checks
simpler,
and
you
know
github
really
has
fundamentally
changed
how
this
works
so
the
first
time
I
saw
pull
requests
10
years
ago.
At
this
point,
I
thought
yeah
it's
another
tool
to
do
code
review.
That's
nice.
We
already
have
kind
of
code
reviews,
but
this
is
a
nice
version
like
I
was
wrong.
I
didn't
get
it
then
right.
B
What
pull
requests
really
are?
Is
the
workflow
for
your
developer
right
and
that
workflow
lets
you
seamlessly
integrate
things
like
ci
and
cd
into
the
daily
life
cycle
of
the
developer.
So
before
we
had
pull
requests
at
microsoft,
we
had
literally
dozens
of
internally
built
systems
that
were
all
different
versions
of
what
we
called
gauntlet
systems
because
you
had
to
run
the
gauntlets
before
you
could
get
your
change
into
the
trunk
branch
and
all
of
them
were
taxes
right.
They
were
these
separate
tools.
B
You
had
to
go
and
do
and
that's
that's
kind
of
the
name
running
the
gauntlet,
but
with
pull
requests.
It
is
essentially
this
valuable
thing
and
the
thing
about
it
is
the
more
automation
the
more
you
tie
to
pull
request
the
more
valuable
becomes,
not
just
for
the
organization,
but
for
the
developer
himself.
We
see
people
all
the
time
at
microsoft,
they
will
go
in
and
create
a
pull
request
just
to
have
the
automation
that
is
tied
to
that
run
before
they
even
submit
it
to
get
changes
reviewed
for
it.
B
B
B
Looking
at
the
checks
ui
and
this
checks,
ui
has
a
whole
bunch
of
different
services
from
codecovs
travis
ci
sonar,
azure
pipelines
all
pushing
data
back
that
get
integrated
into
the
actual
pull
request,
and
then
here
in
this
visual
you
can
see
in
the
actual
conversational
flow
github
is
giving
you
information
about
not
just
the
people
that
are
reviewing
your
code,
but
essentially
the
systems
that
are
reviewing
your
code
and
making
that
a
seamless
part
of
the
workflow-
and
you
know
really.
This
makes
it
something
that
there's
no
reason
not
to
take
advantage
of
it.
B
The
other
thing
that
this
does
is
it
really
enables
shared
contribution
across
both
open
source
and
enterprises.
I
can't
tell
you
how
many
times
I've
been
in
situations
where
team
a
needs,
something
from
team
b
and
team
b
is
too
busy
to
do
that
thing.
For
team.
A
and
thus
conflict
arises
in
negotiation,
and
all
this
kind
of
thing
team
a
would
be
happy
to
go.
Do
the
work
for
team
b
in
their
code,
but
they
can't
because
there's
too
many
obstacles
in
the
way
the
biggest
thing
I've
seen.
B
Is
that
once
you
start
to
have
you
know,
automation,
cicd
in
place
for
this?
It
unlocks
that,
because,
as
soon
as
you
have
automation
that
allows
you
to
know
that
the
change
you're
submitting
is
actually
going
to
work
and
not
regress
you
and
not
take
you
backwards.
It
makes
you
as
the
team
trying
to
contribute
it
more
comfortable
doing
it
and
it
makes
the
receiving
team
more
likely
to
be
willing
to
take
it
and
unlock
it.
And
I
see
this
across
the
enterprise.
I
see
this
across
open
source,
even
at
microsoft.
A
I
do
so,
as
I
was
saying,
there's
tons
of
repositories
on
github.
So
as
a
repository
owner
or
a
maintainer,
you
want
to
find
ways
to
quickly
communicate
to
the
repository
viewers.
What
the
repository
is
about
and
as
a
developer,
we
want
to
be
able
to
quickly
go
to
a
repository
and
understand
what
is
that
repository
about?
A
If
I
want
to
use
the
library,
I
want
to
make
sure
that
the
library
is
something
that
is
actively
maintained,
that
it
has
a
lot
of
downloads,
that
there
there's
a
secure
library,
because
I
will
take
this
dependency
for
the
many
years
to
come
in
my
project
and
readme.
Badges
are
a
great
way
to
achieve
that,
because
they
provide
the
first
timers
to
first
viewers
and
to
old,
timers
quick
details
about
the
repository.
A
A
Some
of
the
notable
ones
is
that
they
welcome
prs,
that's
great,
even
better
they're
under
mit
license
and
if
I'm
interested
to
learn
more
about
them,
I
can
also
follow
them
on
twitter,
but
even
more.
I
can
also
see
that
the
builds
are
passing
and
there.
This
is
a
package.
This
is
a
live
open
source
project
that
is
actually
getting
maintained.
A
Another
example
is
pandas.
This
is
a
data
analysis,
library
for
python,
and
here
we
have
the
same
details,
but
even
more,
we
can
see
that
there's
over
4
million
downloads
that
happen
for
this
library.
So
if
I
decide
to
take
a
dependency
on
it,
I
have
pretty
good
trust
that
people
are
going
to
maintain
because
there
are
so
many
other
repositories
and
people
depending
on
this
library.
A
So
now
a
quick
story
about
badges,
I
used
to
be
a
scout
for
many
years
in
my
life
and
I
used
to
collect
badges.
I
had
like
15
badges
on
my
shirt.
I
can
still
remember
it.
There
were
16
in
total
and
I
was
missing
one,
but
the
bottom
line
was
that
I
was
so
proud
to
wear
that
shirt
because
everybody
who
was
meeting
me
could
see
what
are
my
achievements
at
what
what
I
can
do
and
it's
the
same
thing
when
you
put
up
badges
on
your
github
repository
on
the
readme.
A
B
So
one
of
the
big
kind
of
changes
that
has
happened
inside
of
microsoft
over
the
last
10
years
has
been
going
from
a
server
company
where
we
ship
servers
to
customers
every
two
years.
Hopefully
every
two
years
didn't
always
work
out
that
way,
actually
to
shipping
a
service
to
becoming
a
cloud
company
and
that's
driven
a
whole
bunch
of
change
in
terms
of
our
energy
engineering
system
and
a
whole
bunch
of
learnings.
One
of
the
things
that
we
are
always
trying
to
identify
is
like
what
are
the
things
that
we
can
do.
B
But
if
you're
not
sure
it's
not
taking
you
backwards,
then
it's
going
to
slow
you
down
and
in
order
to
be
able
to
achieve
that,
you've
got
to
invest
in
your
automation.
It's
got
to
be
fast,
it's
got
to
be
reliable
and
if
it's
not,
it
actually
becomes
counterproductive.
So
let
me
tell
you
a
story
of
testing.
B
So
when
I
first
joined
microsoft,
the
way
testing
worked
is
we
had
a
test
team
test
team
was
a
bunch
of
manual
testers.
So
we
would
author
this
big
test
plan
when
we
were
doing
a
feature
and
then
the
feature
would
get
done
and
then
the
test
team
would
go
through
and
run
through
this
all
to
this
test
plan,
they'd
file,
a
bunch
of
bugs
we'd,
fix
the
bugs
they
would
introduce
new,
bugs
we'd
repeat
the
cycle
and
we'd
go
back
and
forth
as
part
of
this,
and
we
realized
this
probably
didn't
work
very
well.
B
So
then
the
next
phase
of
testing
is
we
brought
in
a
whole
set
of
automated
testers.
So
this
was
again
still
a
separate
test
team,
but
they
would
write
a
bunch
of
automated
tests
and
the
automated
tests
that
the
test
team
write,
you
know
were
very
large,
very
complete
test
systems.
They
typically
were
functional
tests,
which
means
they
were
top
of
the
stack
after
you
deployed
it.
B
So
if
we
take
those
set
of
tests
that
we
have-
and
you
try
to
put
those
then
in
the
way
of
the
engineer
being
able
to
get
their
code
into
the
into
the
trunk
branch
turns
out,
you
generate
a
lot
of
conflict,
because
if
those
tests
aren't
fast
and
they
weren't
necessarily
fast,
because
ui
tests
aren't
always
fast
functional
tests,
where
you
have
to
deploy
things,
aren't
necessarily
fast.
They
also
tended
to
be
flaky
because
of
all
those
same
sets
of
things.
B
B
You
know
and
a
bunch
of
products
have
gone
through
journeys
like
you
know,
mine
have
gone
through
where
we
took
those
test
suites
and
then
we
intentionally
went
through
and
you
you
refactor
it
and
you
pull
it
down
to
the
set
of
things
like
you
know.
We
call
them
l0s,
but
basically
unit
tests
that
are
very
fast,
very
reliable
and
we
have
tens
of
thousands
of
these.
They
take
about
four
or
five
minutes
to
run.
B
Typically,
those
get
run
on
every
single
change
as
part
of
our
our
prs,
then
we
have
a
set
of
other
automation
that
you
do
want
to
run.
There
are
functional
tests
that
you
want
to
run
once
the
change
is
a
little
further
in
the
progression,
and
you
decide
where
you're
going
to
put
each
of
these
sets
of
things.
B
So
you
decide
where
you're
going
to
pay
the
price
in
terms
of
speed,
so
investing
in
your
automation,
deciding
where
you're
running
what
set
of
of
operations
and
make
the
earlier
it
is
in
the
life
cycle,
make
the
fat
make
it
fast.
The
other
thing
you
can
go
and
do
is
you
can
throw
compute
at
it?
So
compute
is
cheap,
compute
is
getting
cheaper.
B
B
So
whether
you
know
you
use
my
product
or
whether
you
use
another
product
travis
or
circle,
or
you
know
aws
even
or
google
like
you,
should
pay
them
money,
you
should
you
should,
you
know,
buy
the
compute,
you
know,
anytime,
you
do
the
math
and
you're
there
looking
like
yeah.
Do
I
want
to
spend
an
extra
thousand
dollars
on
compute?
Then
you
do
the
math
of
like
increased
productivity
for
your
developers
that
you're
paying
how
much
more
times,
how
many
developers
that
you've
got.
The
return
is
almost
always
there.
So
here's
an
example.
B
This
is
the
vs
code,
build
the
vs
code,
build
you
know
they
need
to
build
in
windows.
Linux
and
mac,
you
know
you
could
go
and
serialize
that
or
you
could
just
throw
three
machines
at
it.
Do
it
at
the
same
time,
here's
another
one.
Libgit2
libgit2
also
needs
to
build
on
multiple
operating
systems,
but
has
a
bunch
of
different
flavors
go
through
machines
at
it?
B
Go
do
them
all
at
the
same
time,
if
you've
got
40
000
unit
tests
and
all
of
those
can
be
run,
you
know
at
the
same
time
go
through
machines
at
it
and
paralyze
it.
It
makes
a
big
difference
like
we
have
us
at
microsoft.
We
typically,
you
know
we'll
have
builds
like
the
office
build,
take
four
or
five
hours.
Unless
we
put
25
machines
on
it,
then
it
takes
a
lot
less
time
to
go
paralyze
it.
B
It
makes
a
huge
difference
and
I
can
tell
you
the
difference
in
the
morale
of
the
team
once
they've
gone
through.
That
process
makes
a
huge
difference.
Another
lesson
is
automate
everything.
So
we
talk
about
cicd,
so
this
is
bill.
We
typically
talk
about
build
talking
about
test,
but
it
doesn't
have
to
stop
there
so
the
first
time
the
product
that
I
work
on,
moved
from
being
a
server
product
to
a
cloud
product.
B
Essentially
the
deployment
mechanism
for
doing
that
was
to
go,
have
vlad
run
a
25
step.
You
know
document
to
do
the
deployment
and
vlad
was
exactly
the
right
guy
to
be
doing
that
deployment,
but
it
didn't
always
work
reliably
for
obvious
reasons
as
part
of
it
and
then
once
we
started
to
deploy
to
multiple
data
centers
and
you
had
to
re-repeat
it
in
different
forms.
B
That
became
much
more
of
a
problem,
and
so
we
went
through
a
process
of
investing
a
ton
to
get
not
just
test
automated
deployment
automated
and
we
didn't
go
from
25
to
fully
automated
overnight.
It
was
25
steps
and
10
steps.
Then
five
steps,
then
two
steps.
Then
one
step.
I
think
that's
a
really
good
approach
to
help
you
get
there
with
all
these
things
is,
if
you
try
to
go
from
where
you
are
now
to
the
final
state.
B
You'd
want
to
be
at
in
one
huge
step,
like
odds,
are
you're
not
going
to
have
the
organizational
willpower
to
go?
Do
it,
but
you
need
to
find
a
way
to
get
there.
The
other
thing
this
lets
you
do,
though,
is
once
you
have
deployment
automated
it
lets.
You
continue
to
pool
automation
earlier
into
the
life
cycle,
so
here's
an
example.
So
this
is
just
a
dashboard
I
pulled
off
of
you
know
what
the
engineering
system
that
we,
the
engineering
system,
that
we
use
and
what
happens
here,
is
anytime.
B
A
change
hits
master,
we
will
go
and
we
will
deploy
all
of
the
micro
services
that
are
part
of
that's
that
particular
service,
and
then
we
will
run
the
functional
test
on
it.
So
these
tests
take
a
little
longer.
These
tests
will
usually
take
20
to
25
minutes
to
fully
go,
do
this
as
part
of
it
and
there's
a
whole
suite
of
them.
So
each
of
these
rows
are
a
microservice
and
each
of
the
columns
are
a
build.
So
if
you
get
a
column
that
is
all
green,
then
you
know
this.
B
One
has
had
like
that
full
set
of
functional
tests
running
as
part
of
it.
So
what
this
means
is
that
you
know
the
developer
once
they
get
a
change
in
the
master.
We
know
about
half
an
hour
later
whether
this
change
across
all
of
our
services
is
in
a
state
that
we
could
deploy
now,
if
we
want
it
as
part
of
it,
and
this
used
to
take
days
before
for
us
to
really
go
and
do,
but
because
we
got
all
this
automated,
you
can
pool
all
of
this
earlier
and
early
in
the
life
cycle.
B
The
other
thing
that
you
can
do
with
this
is
that
the
developer
is
now
empowered.
So
if
the
developer
wants
to
do
a
full
set
of
tests
here,
even
though
it
takes
you
know
half
an
hour,
they
can
go
and
opt
in
and
do
it
and
a
lot
of
times
they'll
do
that,
because
this
is
a
bigger,
more
disruptive
change
as
part
of
this.
B
It
will
deploy
the
same
way,
which
is
good,
because
if
I
look
at
the
actual
matrix
that
we
have
for
my
service,
we
deploy
to
about
20
different
data
centers
all
over
the
world,
and
each
of
these
go
to
different
rings,
so
we'll
deploy
to
ourselves.
First
then
we'll
deploy
to
a
bunch
of
other
internal
customers
we'll
deploy
to
early
adopters,
we'll
deploy
to
the
us
we'll
deploy
to
europe.
B
Whether
we
want
it
to
roll
out
in
an
hour
because
it's
a
change,
we
have
to
get
out
because
it's
critical
and
we
want
it
to
go
fast
or
whether
this
is
a
big
disruptive
change
and
we
want
it
to
roll
out
and
let
it
bake
for
half
a
day
before
we
roll
it
out
to
the
next
room
and
next
spring
and
next
string.
You
have
that
control.
A
A
Pr
all
right,
the
video
is
working
great
okay.
So
this
is
the
action.
Now.
Let
us
make
a
small
change
in
the
package
json,
so
we
can
see
how
this
action
is
working
so
I'll
make
a
small
change
in
the
description.
I
use
an
example
of
a
library.
It's
called
pkg
cloud.
It
does
a
bunch
of
abstractions
for
different
cloud
providers.
So
I
will
say
this
is
an
awesome
library.
A
I
will
change
the
version.
The
main
version
in
this
case-
and
I
will
create
a
new
branch
and
to
open
this-
will
open
a
pull
request.
So
I'm
proposing
the
change,
I'm
creating
a
pull
request
and
now
in
real
life,
as
jamie
told
us,
we're
gonna
have
some
ci
some
unit
tests.
We're
gonna
have
a
bunch
of
our
teammates,
giving
us
great
suggestions
about
how
we
can
make
our
changes
even
better
and
finally,
we're
gonna
merge.
We're
gonna
merge
the
pull
request.
A
So
the
github
action
detected
that
there
is
a
new
publish,
a
new
event
to
merge
the
pr
to
master
and
it
will
start
different
builds.
It
will
package
the
library
and
it
will
get
it
ready
to
be
published
to
github
package
registry
when
the
package
is
published.
Anybody
with
access
to
the
repository
can
go
to
the
package
details
and
start
installing
the
package.
A
So
this
is
an
example
for
an
npm
package,
but
github
package
registry
also
works
for
docker,
nougat,
maven
and
ruby
so
and
there's
more
coming.
So
we
encourage
you
to
try
it
out
so,
okay
in
the
meanwhile,
the
action
is
finished
it
completed.
So
if
I
go
back
to
the
pull
request,
the
action
has
posted
back
to
the
pull
request
so
that
every
contributors
can
see
where
the
package
is
located
and
here
on
the
package
detail
page,
they
can
see
how
to
install
the
package.
What
are
the
details?
A
Number
of
downloads
and
also
those
readme
badges
that
we
talked
about
before
so
the
bottom
line
here?
Is
that
no
matter
what
what
service
or
package
or
type
of
library
you're
working
on
and
no
matter
what
type
of
tools
you're
using
to
publish
it,
the
important
part
is
to
customize
your
workflows
based
on
your
own
needs.
A
A
B
I
mean
we
had
half
an
hour
to
talk
about
cicd,
that's
kind
of
not
enough
time
to
go
deep
on
much
of
anything.
So
I
guess
I
would
just
leave
you
with
one
thought.
You
know
if
you're,
if
you're,
not
to
a
place
where
you
know
you
have
the
cicd
system
that
you
want
like
to
the
maturity
level
that
that
you
wanted
to
be
at
you
just
haven't,
found
the
time
to
go,
invest
in
it,
and
I
I
see
this
all
the
time.
B
People
don't
find
the
time
to
go
and
do
this
because
it's
you
know
not
feature
development,
it's
kind
of
ancillary
work
as
part
of
it.
I
see
them
not
do
it
and
I
see
them
get
burned.
I
see
them
get
burned
in
terms
of
quality.
I
see
them
get
burned
in
terms
of
not
being
able
to
move
fast
to
the
degree
they
want.
B
In
my
experience,
nothing
else
makes
as
high
a
return
on
investment
as
making
sure
that
you
have
the
automation
in
place
for
the
product
that
you're
working
on
so
with
that,
I
think
we're
ready
to
break
samina.
Thank
you
very
much
for
having
me
here
and
if
you
have
any
questions
or
comments
or
concerns
me,
and
I
would
be
happy
to
answer
them.