►
Description
An overview of the 4 key DORA metrics and how to leverage GitHub to help move you from low to elite performer. We’ll also look at key trends from the 2021 State of DevOps Report and how GitHub can help you keep up with the best practices outlined.
0:00 - Start and Intro
2:58 - Outline
3:48 - What is DORA?
5:12 - How successful is your company? (In a DevOps context)
6:14 - Four metrics that actually matter
8:20 - Reporting on the state of the industry and finding your place in it
15:56 - How to improve Deployment frequency and reduce lead time for changes
23:30 - Integrations, tools and process
26:44 - Time to restore service and change failure rate
29:09 - Key findings of Accelerate State of DevOps 2021
32:39 - Security is speed
35:41 - Documentation is underrated
41:00 - Q&A
44:39 - GitHub Universe is almost here!
https://githubuniverse.com
A
A
Luckily,
today's
story
is
one
of
progress,
especially
how
progress
is
absolutely
attainable,
no
matter
what
your
workflow
looks
like
today,
if
you
find
this
particular
topic
interesting
and
want
more
insight,
join
us
for
github
universe,
it's
just
under
two
weeks
away
and
you
can
register
for
free
at
githubuniverse.com
to
help
me
with
tell
the
story
today.
I
welcome
cameron,
stewart
enterprise
solutions,
engineer
to
tell
us
more
about
how
paying
attention
to
the
right
things
and
using
github
can
accelerate
the
performance
of
your
organization,
cameron.
B
Thanks:
aj,
hey
everybody:
this
is
cameron.
Stewart
I'm
going
to
switch
over
to
presentation
mode,
just
want
to
confirm
everyone
can
see
my
screen
and
we'll
get
into
it
with
today's
topic
so
again,
cameron
stewart
by
way
of
introduction,
I
am
an
enterprise
solutions
engineer
here
at
get
github.
I
live
in
denver
colorado.
So
that's
why
I
chose
this
background
for.
B
Slide
because
I
am
fortunate
enough
that
this
is
what
colorado
looks
like
this
time
of
year.
The
mountains
are
starting
to
get
their
first
dustings
of
snow
and
the
leaves
are
changing.
So
it's
an
exciting
time
of
year
seasonally.
For
me
at
least,
I
hope
the
weather
in
your
respective
areas
is
similarly
enjoyable
for
at
least
a
little
while
longer
so
I'm
relatively
new
to
github
as
an
employee.
I
joined
about
six
months
ago,
but
I've
been
a
long
time
user
of
the
github
platform.
B
I
have
a
developer
background
and
have
just
been
a
long
time
fangirl
of
github
going
on
you
know,
eight
years
or
so
now,
before
joining
github,
I
was
playing
around
in
kind
of
the
cloud
platform
space,
so
I
have
experience
deploying
to
cloud
platforms
such
as
cloud
foundry
or
kubernetes.
So,
if
you're
interested
in
either
of
those
platforms,
I'm
always
happy
to
chat
offline,
I'm
also
a
big
fan
and
just
overall
advocate
for
agile
software
development
practices.
B
B
B
That's
part
of
the
google
cloud
group
and
that
acronym
breaks
down
to
devops
re
research
and
assessments
group
and
what
dora
fundamentally
was
set
out
to
investigate,
was
what
are
the
highest
performing
software
companies
doing
today
to
be
so
successful,
and
so
you
know
what
dora
does
is.
It
concludes
or
it
concludes
this
research
program,
and
this
research
program
represents
seven
years
of
research
from
interviewing
all
kinds
of
professionals
in
the
software
industry
over
32
professionals
worldwide.
B
It's
the
longest
running
academically,
rigorous
research
of
its
kind
and
again
it
really
dives
into
the
practices
that
drive
high
performance
within
these
technology
organizations
and
what
are
the
characteristics
that
define
those
companies
and
really
try
to
crack
the
code
on?
What
are
those
organizations
doing?
That's,
yielding
such
important
results
for
their
organizations
and
for
their
revenue.
B
Is
it's
a
way
to
measure
yourself,
and
so,
if
you
might
be
a
low
performer
today,
that's
okay,
because
now
you
have
that
data
and
those
statistics,
so
that
you
know
where
you
fall
on
the
spectrum,
and
you
know,
as
with
all
things
kind
of
data
collection
and
monitoring.
Once
you
have
that
data
set,
that's
how
you
can
start
to
track
progress
so
that
you
can
move
from
a
low
performer
to
an
elite
performer
and
that's
really.
B
So,
first,
let's
look
at
those
four
key
metrics
that
dora
talks
about
the
first
one
is
the
deployment
frequency.
This
is
fundamentally
how
fast
you're
able
to
get
software
out
your
doors
and
into
the
hands
of
your
end
users
as
possible,
and
so
this
really
is
all
about
talking
about
that
value
stream.
We
know
that
software
is
not
really
doing
anyone
any
good
until
it's
in
the
hands
of
your
end
users,
because
that's
where
they're
actually
interacting
with
that's,
what's
generating
revenue
for
your
organization
and
that's
also
where
you're
getting
feedback.
B
That's
only
then
will
you
learn.
You
know
how
successful
or
how
valuable
a
given
feature
is
to
an
end
user
to
a
customer,
and
so
you
really
want
to
kind
of
have
that
feedback
loop
be
as
tight
as
possible,
and
so
one
of
the
things
that
you
can
do
to
help
you
know
reduce
that
feedback
cycle.
Time
is
to
deploy
more
frequently.
To
constantly
be,
you
know,
testing
new
features
or
new
capabilities
by
getting
them
into
the
hands
of
your
end
users
as
possible,
and
so
this
is
a
key
metric,
the
door
measures.
B
The
second
one
is
the
mean,
lead
time
for
changes,
so
this
is
basically
the
time
that
it
takes
from
your
code
being
committed,
so
it
being
done
and
ready,
essentially
until
it's
actually
going
into
production.
So
how
long
is
it
just
kind
of
sitting
around
ready
for
prime
time?
Obviously,
that's
a
metric
that
we're
all
trying
to
reduce.
We
just
I
just
mentioned
that
we're
trying
to
you
know,
get
the
our
code
into
the
hands
of
our
end
users
as
fast
as
possible.
B
So
this
is
one
that
we're
definitely
trying
to
reduce
the
third
one
being
mean
time
to
recover.
So
when
there
is
an
incident
or
an
outage,
how
quickly
are
you
able
to
recover
and
restore
service
from
that
incident
and
then
finally,
change
failure
rate
so
as
you're
introducing
new
changes,
new
features
and
capabilities
into
your
software,
how
often
are
those
things
causing
breaking
changes
that
require?
You
know
a
roll
back
or
a
patch
or
a
hotfix,
really
measuring
that
change.
B
Failure
rate
is
a
key
metric
as
well
as
we
see
here
so
now.
You
know
one
of
the
things
that
dora
also
does
is
they
have
an
annual
report,
and
so
this
is
called
the
state
of
devops,
where
really
they
take
those
four
key
metrics
and
they
go
out
and
they,
you
know,
assess
who
are
the
elite
performers
and
they
really
talk.
They
look
at
the
past
years
worth
of
data
and
they
summarize
their
key
findings
into
a
report
to
talk
about
the
trends
that
they're
identifying.
Just
what
are
some
other?
B
You
know
notable
findings
that
they
found
as
part
of
this
as
part
of
their
research
and
results,
so
we're
going
to
go
through
kind
of
the
2021
state
of
devops
report
and
talk
about
those
key
findings.
How
you
know
people
are
improving
across
the
industry
and
then
we'll
also,
as
I
mentioned,
kind
of
talk
about
how
github
can
help
you
as
you're
improving
on
in
some
of
these
areas.
B
So,
first,
let's
talk
about
those
four
buckets
of
performers,
the
elite,
high,
the
medium
and
the
low,
and
you
know
what
the
how
they
score
across
the
four
key
metrics
of
the
dora
identify
that
we
just
talked
through.
So
first
deployment
frequency
frequency.
We
know
that
elite
performers
are
shipping
software
multiple
times
per
day.
You
know,
we
know
successful
organizations
like
amazon
netflix
have
crazy
statistics
that
they're
shipping
code.
You
know
in
the
metrics
of
seconds.
You
know
every
couple
of
seconds,
so
this
is
something
that
we
know
you
know
again.
B
Those
top
performers
are
deploying
at
rates
that
again
are
just
kind
of
mind-boggling
to
think
about.
So
if
you
can't
necessarily
wrap
your
brain
around
deploying
every
few
seconds,
or
so
you
know,
that's
okay,
even
multiple
times
a
day
is
an
indicator
that
you're
doing
really
well
on
the
opposite
side
of
the
spectrum.
These
might
be
companies
that
maybe
historically
their
businesses
weren't
in
software,
but
they're
looking
to
transform.
B
B
You
know
how
it's
such
a
small
short
amount
of
time
for
them
to
have
that
lead,
change
and
really
the
spoiler
alert
is
that
it
relies
so
much
on
automation
and
we'll
dig
into
some
of
those
characteristics
and
some
of
the
things
that
you
can
use
to
help
reduce
your
lead
time.
But
we
know
that,
for
you
know
some
of
the
other
folks
that
are
outside
of
the
elite
performers.
This
can
range
anywhere
from
you
know
a
day
to
a
week,
or
even
you
know,
sometimes
in
the
months
category.
B
But
ultimately,
that's
where
you
know
this
is
an
area
that
I
think
is
really
important
to
focus
on
and
to
have
good
process
to
improve
on
this
time,
because
if
there
is
a
feature,
that's
you
know
ready
to
go,
but
it's
just
sitting
there
again,
not
in
production
not
being
used
by
your
end
users.
That's
just
wasted
opportunity,
for
you
know
that
code
base
and
that
or
that
excuse
me
that
change
to
your
code
and
to
that
new
feature,
so
we
again
are
really
trying
to
reduce
the
time
it
takes
to.
B
B
Restore
service
very,
very
quickly
and
pivot
in
the
event
of
some
kind
of
failure
or
outage,
and
you
know,
obviously
we
know
that
it
can
be
really
really
painful.
But
if
you
are,
you
know,
a
lower
performer,
having
kind
of
any
kind
of
degraded
or
degraded
degradated
service
or
outage
completely,
is
just
such
a
hit
to
your
business
and
to
your
organization,
but
sometimes
these
things
can
take
time.
You
know
we
saw
this
recently,
so
this
is
definitely
an
area
of
focus.
B
That
is
a
very
it's
a
hot
topic
these
days,
I'll
just
leave
it
at
that
and
then
again
change
failure
rate.
So
we
talked
about
how
you
know
we're
seeing
the
elite
performers
that
have
crazy
deployment
frequencies
they're
releasing
you
know
multiple
times
a
day
or
multiple
times
a
minute
and
some
circumstances,
and
you
would
think
that
as
you're
introducing
so
many
new
changes
with
such
frequency
that
you
might
be
introducing
more
failures,
that
more
of
these
changes
would
cause
some
breakage
somewhere.
B
But
what
we've
actually
found
is
that
the
elite
performers
actually
have
a
very
low
change
failure
rate
and
again.
I
really
think
that
that
speaks
to
and
goes
back
to,
introducing
those
small
changes,
because
you
can
have
a
really
high
degree
of
confidence
of
the
impact
that
a
small
change
will
make.
When
you
have.
You
know
multiple
changes
in
you
know
a
release,
for
instance,
that,
maybe
is
the
culmination
of
you
know.
Multiple
works
of
multiple
months.
Excuse
me
of
development
work.
B
It
gets
harder
to
reason
about
the
entire
impact
that
all
of
those
all
of
those
changes
are
going
to
have
across
your
code
base,
and
that's
what
we
see
you
know
with
the
low
performers
is
typically
when
they're,
releasing
less
frequently
they're,
introducing
more
changes,
and
so
their
change
failure
rate
is
actually
much
higher.
So
again,
this
really
speaks
to
kind
of
having
that
rigor
and
that
process
around
your
software
development
and
the
overall
deployment
process
that
you
want
to
be
introducing
small
changes.
B
B
B
This
is
again
it
goes
back
to
your
overall
software
development
process
and
how
you're
able
to
help
automate
as
much
of
the
process
as
possible
to
have
a
continuous
streamlined
delivery
pipeline,
and
so
you
know
we
know
we
see
our
familiar
kind
of
devops
infinity
loop
here
of
the
continuous
flow
of
all
of
kind
of
really
the
software
development
life
cycle,
from
planning
that
you
know
software
release
to
actually
writing
the
code
to
building.
You
know
that
artifact
to
testing
you
know
the
new
changes
to
actually
releasing
it.
B
You
know
we've,
I
think,
come
so
far
from
just
kind
of
traditional
ci
and
cd
of
you
know,
running
automated
tests
more
on
the
ci
side
or
automating
your
builds
of
your
software
to
then
you
know,
having
actual
actual
mechanism
of
you,
know,
promoting
or
deploying
your
built
code
into
an
artifact
repository
so
that
it's
always
there
and
available
ready
to
be
deployed
or
even
to
go
so
far
as
again.
Maybe
some
of
those
elite
performers
are
actually
really
fully
embracing
and
implementing
continuous
deployment
philosophies
and
deploying
all
the
way
to
production.
B
As
soon
as
there
is
a
new
tested
ready
to
go
piece
of
code
available,
I
know
that
that
makes
a
lot
of
people
a
little
nervous.
Not
all
people
are
ready
to
just
say
yep
if
it's
green
go
ahead
and
automatically
deploy
to
production.
That's
okay,
but
the
point
that
I'm
trying
to
make
here
is
that
you
want
to
introduce
automation
in
as
many
places
as
possible
and
so
really
the
best
place
that
github
helps.
You
here
is
with
github
actions.
Github
actions
are
really
just
fundamentally
a
automation
engine.
B
B
If
you
go
to
the
github
actions
marketplace
today,
there
are,
you
know,
lots
of
different
categories
that
you
can
search
through
and
once
you
go
to
the
continuous
integration
category,
for
instance,
you
will
see
you
know
just
so
many
pre-built
actions
that
have
already
been
built,
tested
and
are
in
use.
Those
are
again
really
leveraging
and
leaning
on
the
incredible
open
source
community
that
github,
you
know
holds
so
dear
to
its
heart
and
relies
on
so
frequently.
B
But
there
are
so
many
you
know
already
ready
to
go
actions
for
you
to
take
advantage
of,
and
of
course
you
always
have
the
ability
to
build
your
own
actions,
so
you're
not
limited
by
what's
currently
available,
but
there
are
a
lot
of
places
to
start
that.
Can
you
know
kind
of
get
your
imagination
going
with
how
you
can
utilize
these
actions?
B
But
again
you
know
there
are
so
many
capabilities
across
ci
types
of
tasks
and
activities,
so
you
know
automating
your
builds
or
your
tests
and
then,
of
course,
with
the
cd
capabilities
automating,
some
of
your
deployments
for
you,
but
there's
also
things
that
github
actions
can
help.
You
do
like
that
play
within
the
infrastructure
as
code
space,
so
actually
automating
tasks
that
provision
an
environment
for
you.
That's
one
use
case
that
I
know
not.
Everybody
knows
that
github
actions
can
do
so.
B
How
do
you
use
things
like
terraform
to
build
an
environment
for
you
that
then
you
can
deploy
your
application
to
so
there
are
so
many
again
kind
of
use
cases
that
can
be
that
you
can
leverage
actions
for
really
is
just
kind
of.
I
like
to
say
an
automation
engine
that
then
your
imagination
can
go
so
many
different
places
with
how
you
can
leverage
actions
there
is.
B
I
know
that
the
last
demo
days
was
a
talk
on
action,
so
I
will
put
a
link
or
maybe
I
could
ask
aj
to
put
a
link
to
that
talk
into
the
platform,
because
I
would
you
know
I
don't.
I'm
just
gonna
go
high
a
high
level
overview
of
actions
in
this
talk,
but
there
are
much
more
in-depth
detail
talks
that
you
have
access
to.
B
So
I
would
highly
recommend
that
you
check
those
out,
and
so
the
other
thing
that
I
really
just
kind
of
wanted
to
touch
on,
even
though
it's
not
a
durametric.
When
I
really
think
about
you,
know
deployment
frequency
and
lead
time
for
changes,
it
really
also
speaks
to
or
has
a
similar
vein,
which
is
improving,
developer
productivity
and
efficiency
and
their
overall
velocity.
B
You
really
want
developers
to
be
able
to
iterate
as
quickly
as
possible
and
to
be
able
to
you
know,
do
their
actual
development
do
the
coding
that
they,
you
know,
are
fundamentally
responsible
for
achieving
day
in
and
day
out,
and
so
you
know,
two
of
the
kind
of
capabilities
that
github
brings
to
market
that
really
help
with
that
are
code
spaces
which
give
you
ready
to
go
development
environments.
This
allows
you
to
really
reduce
the
time
as
a
developer
that
it
takes
in
configuring
a
new
environment.
B
So
that's
a
relatively
new
capability
that
github
brings
to
market.
So
again,
I
would
encourage
you
to
check
out
github
code
spaces
and
then
another
one
that
I'm
really
excited
about
is
github
copilot.
So
this
is
an
ai
pair
programmer
that
really
helps
developers
with
some
of
the
you
know,
just
kind
of
stock
boilerplate
code
that
you
might
need
to
be
responsible
for
when
you're
you
know,
beginning
work
on
a
new
project
by
leveraging
copilot,
you
can
be
suggested.
B
You
know
a
whole
block
of
code
to
help
you
really
just
be
more
efficient
in
your
actual
development
when
you're.
Actually,
you
know
coding
and
working
within
the
code
base,
so
those
are
two
other
kind
of
features
that
github
provides
that
again
they're
outside
of
the
dora
metrics,
but
I
think
that
they're
key,
because
the
faster
your
developers
are
able
to
work
on
new
features
and
to
actually
you
know,
get
that
code
to
the
state
that
it's
committed
and
ready
to
go.
The
better.
B
Your
overall
organization
is
only
going
to
benefit
from
giving
developers
those
tools
to
help
them
be,
you
know
faster
and
to
increase
their
velocity
with
actually
developing
and
implementing
those
new
features,
and
so
the
other
thing
that
I
just
wanted
to
talk
about.
I
mean
there
are
so
many
tools
that
already
exist
out
there.
You
know
I
mentioned
that
actions
is
a
great
automation
engine,
but
it's
not
the
only
one
that
exists
out
there,
certainly,
and
what
we've
really
found
is
in
order
to
be
kind
of
a
true
devops
platform.
B
We
really
aim
to
be
extensible
and
to
have
good
integrations
with
other
tools,
tool,
chains
and
technologies
that
exist
out
there
today.
We
know
that
any
given
customer
is
going
to
have
a
whole
mix
of
different
software
and
tools
that
they
are
using
as
part
of
their
development
life
cycle,
and
so
you
know,
I
would
say,
definitely
look
at
the
actions
that
exist
out
there
that
have
integrations
with
other
tools
you
may
be
using.
There
are
so
many
that
exist
within
the
marketplace,
but
then
you
know
outside
of
just
the
tools.
B
This
is
all
about
velocity
again,
of
course,
have
the
tool
chain
that
makes
sense
that
can
help
you
introduce
automation
in
as
many
places
as
possible
to
help
really
automate
and
make
that
a
streamlined
delivery
pipeline
for
your
code
to
you
know,
go
from
committed
to
running
in
production,
but
you
also
have
to
think
about.
You
know
how
do
you
foster
an
environment
for
collaboration,
because
it's
not
just
again
the
developers
who
are
you
know,
working
on
the
actual
features
and
then
handing
it
over
to
be
deployed
and
operated.
B
The
whole
ethos
of
devops
is
collaboration.
It's
bridging
the
gap
between
developers
and
operations,
teams
and
giving
them
shared
tool
sets,
so
they
can
be
jointly
successful
that
they
can.
You
know
again,
share
tools
so
that
they
can
gain
similar
views
and
visibility
into
the
entire
end
to
end
life
cycle,
and
I
would
posit
that
it's,
you
know
out
it's
not
just
developers
and
operations
that
you
want
to
bring
together,
but
it's
everyone,
that's
involved
in
a
software
delivery
life
cycle,
so
this
is
project
managers
and
designers.
B
So
even
you
know
from
the
aspect
of
planning
your
code,
you
really
want
to
again
have
a
shared
tool
set
that
can
make
the
entire
team
more
productive
and
to
really
again
kind
of
foster
and
build
for
collaboration.
So
you
know,
when
you
have
shared
tool,
sets
you
can
streamline
those
processes,
and
so
again
this
is
another
area
that
I
just
think
github
is
really
really
strong
is
because
you
can
do
things
like
code
reviews
so
that,
as
new
features
do
become
available.
B
It's
the
same
platform
that
developers
are
already
working
in
that
project,
managers
or
designers
can
go
in
and
review
the
code
that
developers
are
working
on
and
do
things
like
make
comments
or
you
know,
send
back
with
suggestions,
and
it
really
is
a
common
place
that
everyone
can
come
together
to
collaborate
jointly
to
improve
that
overall
software
development
life
cycle,
it's
as
much.
You
know
automating
kind
of
the
collaboration
as
it
is
the
actual
tool
chain
that
you
use
to
get
code
from.
You
know,
developer
environment
or
github
to
running
in
production.
B
So
now,
as
we
think
about
kind
of
the
other
two
key
door,
metrics
the
time
to
restore
service
and
the
change
failure
rate,
these
are
both
really
about
stability,
and
we,
you
know,
know
that
these
are
both
metrics,
that
we're
trying
to
reduce
so
specifically
with
the
change
failure
rate.
This
is
something
that
elite
performers
have
very
very
low,
and
so
we
talked
about
earlier,
how
part
of
it
is
when
you're,
making
smaller
more
frequent
deployments,
you're
introducing
smaller
changes,
which
is
inherently
less
risky.
B
So
that's
certainly
kind
of
one
side
of
it
is
having
that
just
process
and
deployment
capability
that
you're
able
to
release
smaller
changes.
More
frequently
that
in
general,
as
we
saw
in
the
overall
table
with
the
dora
metrics,
gives
you
the
ability
to
have
a
smaller
change
failure
rate,
but
the
other.
B
You
know
aspect
that
I
want
to
touch
on
and
I'll
bring
this
up
a
little
bit
later
in
the
presentation
when
we're
talking
about
the
key
findings
of
the
report
is
how
do
you
also
just
make
sure
that
the
code
that
you're
introducing
isn't
introducing
any
kind
of
vulnerability
or
could
have
some
kind
of
impact
in
that
regard?
And
so
again,
I'm
going
to
reference
and
I'm
going
to
reference
it
again
in
the
future.
B
But
github
has
a
really
strong
security
platform
story
and
there
was
a
talk.
I
believe,
two
weeks
ago
by
my
colleague,
glenn
wester.
That
was
all
about
how
you
know
github
just
what
the
story
is
with
github's
security
and
the
offerings
that
we
bring
to
market
and
how
it
can
help
you
to
shift
security
left
so
that
it's
much
earlier
in
the
process.
B
It's
part
of
the
development,
the
development
life
cycle
and
so
that
it's
more
integrated,
so
you're
able
to
catch
things
earlier
in
the
process
and
certainly
before
you
know
they
reach
production.
So
I
would
say
if
you
can
have
a
stronger
security
posture
and
really
start
to
think
about
security
in
that
manner
of
bringing
it
earlier
in
the
development
life
cycle.
That
will
also
have
a
huge
impact
on
your
change
failure
rate,
because
you
fundamentally
will
be
shipping
more
secure
software.
B
So
if
we
talk
about
kind
of
the
state
of
the
devops
report-
and
I
just
wanted
to
talk
about
the
key
findings
that
were
surfaced
as
a
part
of
this
year's
report-
and
so
there
were
six
key
findings-
I'm
going
to
talk
about
two
of
them
that
I
think
are
specifically
worth
calling
out.
So
I'm
going
to
hold
off
on
those
two
really
quickly,
but
the
other
ones
that
I
just
think
are
worth
mentioning.
B
That
I
just
think
are
worth
touching
on
is
that
one
of
the
key
findings
is
that
the
highest
performers
are
continuing
to
more
people,
are
edging
towards
that
higher
that
elite
performer
category
and
are
continuing
to
raise
the
bar.
So
I
think
really,
the
point
that
this
is
raising
is
that,
if
you're
measuring
these
things
like
these
practices,
work,
they
are
driving
real
impacts
on
these
businesses
and
these
organizations.
B
So
you
know,
as
we
talked
about
it's,
not
just
the
tools
that
you're
using
it's
also
the
processes
that
you
implement,
but
if
you
can
start
to
measure
where
you
fall
on
the
spectrum
and
which
bucket
or
category
you
currently
reside
in
and
start
to,
incrementally
introduce
some
of
these
processes
and
adopt
some
of
these.
You
know
tool
sets
and
approaches.
B
The
other
thing
that
you
know
I
didn't
really
go
into,
but
I
would
say
that
the
report
does
really
touch
on.
Is
the
developer?
Excuse
me,
the
operational
excellence,
so
I've
really
focused
on
a
lot
of
the
software
delivery
side
of
things,
which
is,
I
would
say,
the
meat
and
potatoes
of
the
dora
reports,
but
they
definitely
call
out
that
it's
not
just
software
delivery
and
improving
that,
but
that
also
really
has
to
do
with
operational
excellence.
So
I
did
also
just
want
to
plug
that.
B
You
know:
sre
practices
go
hands
on
hand
with
the
whole
devops
ethos,
and
so,
if
you're,
you
know
not
as
familiar
with
sre,
I
would
highly
recommend
that
you
check
it
out.
It
will
not
surprise
you
that
you
can
google
it
and
it
comes,
and
you
can
have
you
can
actually
download
the
sre
reliability
engineering
book
from
google.
You
can
you
know,
google,
it
pops
right
up
and
it's
available
for
free
for
you
to
consume
and
read,
and
the
sre
book
is
really.
B
I
found
it
a
great
read
because
it's
essay
format,
and
so
it
just
brings
in
so
many
different
viewpoints
and
perspectives
and
point
of
views
into
how
to
run
from
an
operations
perspective,
how
to
run
production
software
with
just
such
a
high
degree
of
excellence.
I
mean
it
really
talks
about
how
google
you
know,
experimented
and
figured
it
out,
and
you
know,
allows
them
to
be
the
really
top
performer
that
they
are
today.
B
So
I
would
recommend
that
you
check
out
the
sre
book
because
I
think
it's
a
great
resource
and
I
think
it
only
helps
to
reinforce
a
lot
of
these
practices
that
we
think
about
within
the
software
development
life
cycle.
You
can't
be
successful
at
that.
If
you
don't
have
a
strong
operational
process
as
well,
so
they
really
are
tandem
topics
and
something
that
you
want
to
kind
of
be
thinking
about
and
attacking
from
both
sides.
B
So
I
just
wanted
to
also
plug
that
the
operational
side
is
also
very
important,
but
I
mentioned
that
these
two
callouts
are
definitely
something
that
I
wanted
to
drill
into
a
little
bit
more
and
with
the
security
side,
I
mean
in
this
annual
report
the
accelerate
state
of
devops.
From
this
year
there
was
a
specific
call
out
about
security
and
really
shifting
left.
I
know
that
that's
a
buzzword
term.
B
But
I
love
this
little
call
out
and
just
you
know
what
they
say
in
this
paragraph
of
talking
about
security
of
it
really
allows
you
to
just
have
a
higher
security
posture
when
you're
thinking
about
shifting
security
left-
and
you
know
over
here
on
the
right
where
it
says
elite,
performers
that
met
or
exceeded
their
reliability
targets
were
twice
as
likely
to
have
security
integrated
in
their
software
development
process.
So
it
security.
Really,
I
know
it's
you
know
again,
a
buzzword
is
a
hot
topic.
B
It's
something
everyone
is
really
trying
to
improve
upon
and
think
about
more
and
more
in
today's
day
and
age.
But
you
know
it
really
shouldn't
be
treated
as
an
afterthought
or
something
that
happens
right
before
going
to
production.
You
want
to
really
have
the
frame
of
mind
that
you're
thinking
about
it
so
much
earlier
in
the
process
and
again
glenn
wester's
talk
from
two
weeks
ago
just
goes
in
depth
on
this
topic,
so
I
would
encourage
you
to
check
that
out,
but
that's
what
we're
all
about
here
at
github.
You
know
we're.
B
I
mean
in
general
all
about
just
the
developer,
the
software
development
life
cycle
and
we
really
bring
our
approach
and
our
philosophy
to
security
is
all
about
that.
It's
about
implementing
and
integrating
security
into
that
software
development
flow.
So
that's
part
of
and
native
to
the
developer,
so
to
have
security
running
and
to
have
good
policies
that
are
part
of
the
software
development
process,
so
that,
if
there
is
a,
you
know
vulnerable
pattern
that
a
developer
may
be
unknowingly
put
into
their
code
base.
B
You
want
to
catch
that
very
early
on
before
it's
certainly
before
it's
in
production,
but
also
before
the
developer
has
kind
of
forgotten
about
the
context
of
what
they
were
working
on
that
day.
If
you
can
catch
those
things,
you
know
within
kind
of
the
same
time,
frame
that
a
developer
is
actually
working
on
that
code
base
and
say
hey.
Actually,
you
know
that
introduces
a
vulnerability,
here's
some
suggestions
for
how
to
remediate
or
a
different
way
to
implement
that
piece
of
functionality.
B
It
keeps
it
within.
You
know
the
attention
span
of
a
developer,
which
we
all
know
can
be
a
little
short,
sometimes
so
really
trying
to
have
it
as
integrated
and
native
to
the
developer's
workflow
is
something
that
we're
working
on
and
kind
of
our
recommendation
and
what
we
see
as
a
best
practice
here
at
github
and
that's
what
we
try
to
bring
to
our
customers
with
our
security
options.
So
did
just
want
to
call
that
out
the
other
one
that
I
wanted
to
call
out,
which
I
was
kind
of
surprised
by
in
reading.
B
B
I
think
and
oftentimes
overlooked,
or
maybe
not
just
championed
enough
aspect
of
the
software
development
life
cycle,
but
I
think
it
is
so
critical
and
it's
so
key,
and
so
you
know
it
says
here
that
to
have
good
internal
documentation
which
can
take
the
form
of
so
many
different
things,
whether
it's
manuals,
readme
even
code
comments,
can
really
just
overall
improve
your
your
entire
process.
So
it's
some
of
the
ways
that
you
know.
Github
is
all
about
this.
Obviously,
we've
always
been
big
fans
of
just
having
nice
clean
means.
B
It
makes
people
that
are
coming
to
your
project.
Just
have
a
clear
understanding
of
what
that
project's
all
about.
If
they
want
to
contribute.
You
know
what
are
the
contribution
guidelines
having
things
like
that
makes
it
so
much
easier
for
people
to
come
in
and
who
want
to
be
involved,
get
involved.
There's
also,
you
know
some
other
handy
features
that
github
makes
available
and
that
we
certainly
internally
at
github,
use
all
the
time
are
using
things
like
issue
templates.
B
So
you
know
if
someone
wants
to
submit
an
issue,
giving
them
a
template
for
here's,
the
information
that
we
need
from
you
in
order
to
make
this
the
most
valuable
can
just
pay
dividends
in
terms
of
overall
efficiency
and
productivity,
also
the
ability
to
have
a
wiki
page
or
to
have
discussions
so
that
people
can.
You
can
have
a
page
of
frequently
asked
questions.
B
I
would
say
more
and
more:
we're
really
recommending
that
you
embed
the
documentation
with
your
source
code
and
within
your
projects,
because
it
makes
those
who
are
maybe
new
to
your
project
that
again,
maybe
are
trying
to
use
it
and
are
looking
for
how
to
get
started.
Maybe
they
want
to
collaborate
and
contribute
and
it
helps
give
them
guides
for
how
to
make
an
impact
it
just
can
help
the
overall
progress
and
improvement
and
innovation
of
that
project.
B
So
that's
pretty
much
it
that's
the
you
know.
I
hope
that
maybe
this
helped,
because
you
know
I
read
the
reports.
Maybe
now
you
don't
have
to
nice
little
summary
for
you
and
ultimately
you
know
what
we're
here
to
do,
especially
at
github
is
we
want
to
help
you
move
from
being
wherever
you
are
in
the
direction
of
improvement,
so
whether
that
means
you're
moving
you're,
starting
it
low,
you're,
moving
towards
medium
or
whether
you're
already
kind
of
doing
pretty
good
you're
in
that
high
column.
B
But
you
want
to
make
it
to
the
elite
performer.
There
are
so
many
different
capabilities
at
the
github
platform.
I
would
say
makes
available
to
you
that
can
help
you
improve
across
these
four
different
metrics,
and
you
know
I'm
sure
that
there
are
a
lot
of
power
users
out
there
today
that
are
familiar
with
all
the
things
that
I've
discussed
but
they're.
In
my
experience
and
conversations
with
customers,
there
are
a
lot
of
people
out
there
that
still
just
see
github.
B
As
you
know,
a
code
repository
and
that's
really,
certainly
the
genesis
of
github
those
are.
That
is
our
origin
story,
certainly,
but
we
have
come
so
far
and
there
are
so
many
different
capabilities
and
features
and
different
applications
and
use
cases
that
the
platform
in
general
can
help
you
in
the
overall
process
of
your
software
development
life
cycle
that
that's
really.
What
I
wanted
to
kind
of
call
out
today
is
that
it's
an
end-to-end
devops
platform
that
helps
you
as
you're,
trying
to
be
more
successful
with
devops.
B
So
I
will,
you
know,
just
kind
of
call
out
the
elephant
in
the
room
today.
I
did
not
talk
about
how
to
monitor
these
things.
That's
definitely
you
know
kind
of
my
recommendation.
Number
number
one
is
that
in
starting
on
this
journey,
you
should
start
to
monitor
yourself
and
where
you
fall
against
these
metrics.
So
you
know
I
didn't
have
time
within
this
talk
today
to
talk
about.
There
are
so
many
different
monitoring
options
out
there
today.
B
So
again,
that's
all
I
have
for
you
today.
I
hope
that
I
articulated
that
you
know
the
github
platform
loves
devops
and
we
are
here
to
help
you
on
your
journey
and
be
more
successful
with
devops.
So
thank
you.
Everybody
I'm
going
to
take
a
peek
in
the
chat
to
see
if
there's
any
questions,
aj,
I'm
not
sure.
If
you're
there,
let's
see,
I'm
just
orienting
myself.
B
Yeah
so
rothie,
I
do
see
you
know
you're.
I
feel
your
pain.
Certainly,
and
you
know
the
answer
really
is
just
in
introducing
automation.
You
know
it
sounds
like
a
lot
of.
Maybe
the
pain
you're
experiencing
is
in
kind
of
manual
processes,
and
that
is
kind
of
the
first
step
in
being
more
successful
and
towards
becoming
a
more
sophisticated
devops
organization
is
introducing
automation
where
it
makes
sense.
Obviously
you
can
go
just
way
overboard
with
automation,
so
my
recommendation
would
be
to
start
small.
B
I
think,
with
your
specific
example,
I
mean
obviously
automating
your
tests
and
your
bills
is
gonna
help
you.
If
you
have
a
pretty
robust
test
coverage
and
test
suite,
it
allows
you
to
have
a
high
degree
of
confidence
of
the
changes
that
you're
making
within
your
code
that
they're
not
gonna
break
anything
in
production.
B
So
I
would
say:
that's
probably
the
step
number
one
and
then
then
using
automation
to
help
kind
of
build
your
application,
and
you
know,
store
it
in
some
kind
of
artifact
repository
so
that
when
it's
ready
to
go
for
production,
you
are
in
a
state
that
you
can
deploy
it.
You
know
getting
into
more
of
the
cd
side
of
things
continuous
deployment
or
continuous
delivery
that
can
again
be
the
next
level
up.
That
definitely
takes
some
consideration
to
make
sure
that
you
are
able
basically
to
run
at
that
speed.
A
Yeah
cameron,
I
think
you
make
a
great
point
about
like
it's,
not
just
about
ramping
up
the
speed
of
your
deployments
to
ramp
up
the
speed
of
your
deployments,
like
you
actually
have
to
put
in
the
work
to
set
up
the
systems
to
automate
the
little
things
so
that,
when
you
do
speed
up
those
those
production
deployments
that
it
doesn't
break
anything
that
you're
actually
gaining
speed.
Because
of
the
work
that
you've
put
in.
B
B
A
Awesome
all
right.
Well,
thank
you
cameron.
I
really
appreciate
you
talking
us
today
and
giving
us
a
good
a
really,
really
good
overview
of
dora
metrics
and
the
practical
ways
to
use
them.
I'm
gonna
switch
gears
for
a
little
bit
and
talk
about
github
universe
seems
that
word's
gotten
out
that
registration
is
now
open
for
github
universe,
which
is
streaming
live
on
october,
27th
and
28th.
A
Also,
you
might
notice
that
many
of
the
interactive
sessions
are
already
full,
but
don't
be
too
discouraged
if
the
session
that
you
want
to
join
isn't
currently
available.
Just
add
yourself
to
the
waitlist
and
know
the
team
will
release
spots
as
they
become
available
cameron.
Do
you
have
any
particular
sessions
or
things
to
look
forward
to
as
universe
rapidly
approaches.
B
Oh
man,
probably
just
too
many
to
list.
This
is
my
first
universe,
and
so
I
am
just
gonna,
be
like
a
kid
in
a
candy
store,
just
running
from
you
know,
main
stage
to
breakouts
and
just
everywhere
in
between
I'm
just
no.
I
can't
summarize
it
all
in
a
short
sweet
list.
We
would
be
here
for
another
30
minutes
so.
A
It's
two
hours
each
day
and
then
there's
also
optional
live
interactive
sessions
which
I
alluded
to
before
that
you
need
to
be
able
to
to
register
for
it
and
join
in
on
there's
also
a
ton
of
on-demand
sessions.
So
it's
you,
you
don't
have
to
set
aside
two
full
days.
Your
time
to
participate
like
there
will
be
plenty
of
content,
that's
available
on
demand,
as
well
as
some
really
exciting
stuff
that
we
can
watch
live
and
together,
and
I
will
be
there
for
it
all.