►
Description
GitHub customers benefit from having a single platform to ideate, build, and ship new user experiences, fast and at high quality. Join Virginia Bryant, Director of Customer Marketing at GitHub, as she facilitates a discussion between Bob Bell, Software Engineer at Dell, and Gabriel Kohen, Senior Principal Engineer at Blue Yonder, to learn about how they improved their time to market with GitHub Enterprise.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Today
I
am
thrilled
to
be
joined
by
two
incredible
devops
leaders
for
our
outside
chat.
We
have
gabrielle
cohen
senior
principal
engineer
and
fellow
at
blue
yonder
and
bob
bell
distinguished
member
of
technical
staff
at
dell.
So
before
we
start
a
few
housekeeping
activities,
we
will
have
chat
available
throughout
this
session,
so
feel
free
to
use
that
to
share
any
thoughts
or
insights
you
have.
However,
you
know
this
is
really
intended
to
be
interactive
and
I'd
love
to
welcome
you
to
share
any
questions.
A
You
have
directly
in
our
q,
a
they'll
get
buried
in
the
public
chat,
so
let's
get
them
to
that
q
a
channel
and
you
can
find
that
on
that
right
hand
side
across
the
top.
Where
says
q
a
and
then.
Finally,
if
you
want
a
follow-up
from
github,
you
can
click
to
request.
The
demo
button
that
you're
going
to
see
in
the
upper
right
that
blue
button
and
if
you
have
any
questions,
feel
free
to
you
know
drop
them
in
the
chat
about
the
demo
process
and
okay,
let's
get
started
so.
A
B
It's
a
combination
of
the
three
devops
is
the
amalgamation
of
building
and
deploying
and
operating
solutions,
mainly
around
software,
and
it
can
be
extended
to
others
what
devops
is
not
because
there
is
a
lot
of
confusion
out
there.
Devops
is
not
a
team.
Devops
is
not
a
tool.
Devops
is
not
dev
in
ops.
These
are
not
two
different
things.
B
It's
like
saying
that
a
carpet
is
a
car,
and
a
pit
is
one
with
the
other
is
a
culture
is
a
culture
that
was
described
in
literature
in
the
industry
and
it's
being
practiced.
It's
a
live
culture,
no
pun
intended
that
takes
the
three
ways
so
jazz,
humble
and
gene
kim
we're
talking
about
it
quite
a
bit.
The
three
ways
are
a
state
of
flow,
so
think
about
all
the
ci
cds
that
you
did
in
all
the
build
all
the
way
from
your
development
environment.
B
Right,
your
ide
to
constant
state
of
feedback
from
your
observability
team,
from
your
alerting
team
again
from
your
ci
cd
and
then
something
that
usually
people
neglect
is
organizational
wild
knowledge
right.
Everything
that
you
learn
in
your
process,
good
things
and
bad
things.
You
need
to
bring
it
to
all
your
organizations
not
to
silos,
not
to
part
of
it
not
to
dev
ops
team.
A
C
You
know
people
who
are
focused
on
that
devops
aspect
and
bringing
uniting
them
into
one
so
that
we
can
be
focused
on
a
consistent,
a
best
devops
approach
across
the
organization
and
part
of
that
is
bringing
together
again
it's.
I
very
much
agree
with
gabriel
that
it's
about
it's
about
culture.
The
tools
help
us
get
to
that
and
support
it.
Github
is
one
of
those.
C
I
I
many
ways
view
it
as
perhaps
the
most
central,
because,
particularly
in
the
way
that
we're
doing
things
really
all
comes
back
to
source
code,
so
we're
in
particular,
we
really
have
doubled
and
maybe
triple
down
on
the
pull
request
really
to
bring
that
together.
As
the
focus
of
you
know,
that's
how
we
take
those
different
aspects
that
lead
to
that
acceleration
of
and
and
that
verification
the
code
review,
the
static
code
analysis,
our
building
our
testing
discussion
right
gabriel.
C
You
mentioned
that
too,
and
you
know
communication
and
that
sort
of
thing
bring
it
all
and
focus
on
the
pull
request,
and
so
that's
that's
key
to
us,
but
we're
you
know
especially
right
now,
we're
doing
it
as
part
of
our
journey
is
bringing
all
these
different
groups.
Methodologies.
I
think
silo
is
the
word
that
you
use
gabriel
all
these
different
silos
that
existed
and
trying
to
bring
them
together
and
say:
hey
we're
one
team
we
should
be
sharing.
We
should
be
using
best
of
breed.
B
So
something
to
add
to
what
just
bob
said,
because
to
me
this
is
a
good
indication
that
a
lot
of
industry
players
out
there,
such
as
dale
louis,
under
on
converging
on
the
same
kind
of
lessons
learned
for
us
devops.
You
know.
Initially
it
started
as
a
buzzword,
like
many
other
buzzwords,
that
people
just
like
to
drop
all
the
time.
B
It's
like
have,
let's
recruit
devops
there
and
have
a
devops
team,
and
what
we
found
is
that
the
biggest
success
really
started
from
from
grassroots
and
that
then
we
got
buying
of
leadership
right
into
it,
and
then
leadership
was
excited
because
we
started
some
pilot
programs
in
blue
yonder.
That
involved
really
all
the
way
from
the
ground.
B
Up
of
you
know
revamping
the
way
that
we
do
our
engineering
all
the
way
from
like
restating
clean
code
and
all
those
good
principles
right
and
then
have
a
coaching
program
in
which
coaches
are
not
just
like
sitting
somewhere
on
an
ivory
tower
and
saying:
do
this
do
this
or
do
that
right
or
some
devops,
you
know
lecturer
come
and
say
you
should
do
all
this
and
then
we're
gonna
say.
Oh,
you
know
what
it
only
happens
in
unicorns.
It
doesn't
happen
in
the
real
world.
A
Yeah,
you
know,
and
it's
interesting
because
I
think
a
lot
of
folks
probably
do
view
devops.
As
you
know,
the
series
of
tools
and
workflows
that
enable
your
developers
to
you
know
ship
code
faster,
and
so
you
know
you're
both
really
focusing
on
it
as
this
cultural
movement.
That's
enabling
things
you
know
enabling
those
outcomes
within
your
organization,
but
I'd
love
to
understand.
You
know,
from
the
benefit
side,
from
how
you're
making
the
decision
to
actually
make
this
investment
in
culture
and
tools
and
processes.
A
C
Sure
so
one
of
the
main
benefits,
I
think,
maybe
perhaps
it's
a
little
bit
low
level
because
it
or
first
order
and
it
cascades.
The
second
order
benefits
is
really
is
the
rate
of
feedback
to
me.
That's
that
that's
key
with
the
devops
approach
is:
how
do
you
get
feedback
to
a
developer
as
quickly
as
possible
and
so
letting
them
know?
You
know
to
me.
That's
part
of
what
the
you
know.
Cicd
is
about.
You
know
the
you
know
continuous
right.
C
That
implies
constant
and
ongoing,
but
being
able
to
say
hey,
you
know,
shift
the
you
know,
you'll
hear
the
phrase
shift
left
and
I
know
I'm
just
grabbing
the
buzzwords
left
and
right
right,
but
that's
about,
but
that's
about
giving
them
the
feedback
as
soon
as
possible
and
being
able
to
and
have
them
respond
particularly
gabriel
mentioned
flow.
I
believe,
while
they're
in
the
state
of
flow
not
saying
hey,
you
know
that
thing
you
did
yesterday,
yeah
it
didn't
work
out
so
well
right
or
or
yeah.
C
You
know
we
took
your
change
and
we
took
it
up
to
a
main
line
and
we
had
a
problem
there.
Oh
you're
gone
for
the
weekend.
Oh
you
know
you
know,
devops
is
about
being.
I
would
give
that
to
them
right
then,
while
they're
in
context,
while
they
need
it
before
it
causes
more
problems
right
and
that
enables
you
know
increased
velocity
for
the
team.
It
makes
for
happier
developers
right.
It
makes
more
efficient
developers
and
there
are
a
number
of
benefits
to
me.
C
B
Yeah
yeah,
absolutely
so,
like
everything
else,
you
know
people
talk
about,
oh
agile,
how
does
agile
touch
on
devops
etc?
Very
much
like
agile.
If
you
just
do
the
processes
for
the
sake
of
processes,
that
is
fear
right.
You
might
be
making
somebody
happy
because
you
tick
the
boxes,
but
you
don't
see
results.
What
we
want
to
see
at
the
end
of
the
day
are
more.
You
know,
increase
the
value
stream
of
the
company,
the
ability
to
put
our
competitors
on
their
heel.
B
By
saying
you
know
what
I
have
a
constant
state
of
flow.
I
have
constant
feedback.
I
can
learn
very
fast.
My
developers
are
seeing
this
process
of
cicd
as
a
delightful
process
and
they're
engaged
all
the
time
they
build
it.
They
own
it.
So
they
operate
the
services,
the
microservices
or
otherwise
that
they
build
at
the
end
of
the
day.
That
means
that
the
product
manager
can
iterate
faster.
So
we
can
bring
the
the
lead
time
right.
B
B
If
you're
working
on
something
for
two
months,
it
took
you
two
months
until
you
deliver
it,
as
opposed
to
being
to
to
work
on
small
pieces
iterate
fast
with
the
cicd,
bring
it
to
an
experiment,
maybe
experiments
or
otherwise
to
our
customers
and
our
customers
say.
Oh
I
like
this.
I
didn't
like
this
and
then
the
developer
already.
Has
that
contextual
thing
going
on
right?
The
mental
thing
going
on
they're,
not
gonna,
forget
something
that
they
did
this
week.
B
They're
gonna
forget
maybe
something
that
they
did
six
months
ago,
so
that
ability
to
iterate
fast
that
devops
bring
to
the
whole
organization
is
pretty
it's
pretty
substantial
and
you
already
started
to
see
that
in
the
last
few
years
in
our
teams
at
blue
yonder,
something
to
note
about
cicd
because
many
times
people
so
for
ci.
What
ci
means?
That's
easy!
That's
continuous
integration!
B
That's
when
you
bring
code
together
by
the
way
we
can
talk
about
short-lived
branches
and
trunk
based
development
and
all
those
good
things
that
can
be
in
its
own
talk,
that
is
fun.
Cd
is
usually
tricky
because
people
think
it's
continuous
deployment
and
it's
not
just
continuous
deployment.
It's
continuous
delivery
too.
So
deployment
and
delivery
are
not
the
same
thing
you
can
continuously
deploy
and
then
use
techniques
such
as
feature
flags
and
similar
things.
B
C
Yeah
and
one
of
the
things
just
gabriel,
following
up
on
what
you
said,
I
heard
a
lot
of
when
your
response.
You
were
you're,
you
you're
talking
about
devops
you're,
also
getting
really
close
to
agile
and
perhaps
covering
it
there
too,
and
and
virginia
you
let
off
with
you,
know,
devops
and
distinguishing
from
agile
and
right
and
while
they
are
distinct,
they're,
very
complimentary
right
and-
and
that's
where
I
think
you
start
to
talk
about
one.
It
often
will
lead
into
the
other.
But
you
know
particularly
you
know.
A
That
makes
a
ton
of
sense,
and
thank
you
for
for
sharing
that
I'm
curious.
You
know
I
heard
mention
of
the
dora
metrics
as
well
as
the
more
ephemeral
you
know,
developer
happiness
and
things
that
are
so
critical
to
a
team
and
so
critical
to
the
business
outcome.
Ultimately,
because
you
know
your
people
are
your
product.
B
So
bob,
if
you
don't
mind
I'll
I'll,
go
next,
we
have
both
ways
of
looking
at
devops
and
measuring
it.
So
we
are
doing
on
an
ongoing
basis,
a
review
of
our
teams
of
their
maturity
in
in
devops.
I
call
it
the
crawl
walk
run,
you
know
kind
of
phases
of
a
team
and
we
have
a
very
specific
criteria.
What
does
it
mean
or-
or
you
can
say-
bronze
gold
platinum
right
to
go
from
one
to
the
other?
B
B
B
In
addition,
we're
getting
a
lot
of
metrics
from
github
itself
as
well
as
we
used
jira
for
our
you
know,
tracking
a
feature
and
bugs-
and
you
know
bob
was
talking
about
agile,
so
we
take
the
csd
all
the
way
from
the
product
manager
in
the
ux
team
deciding
and
doing
ideation
of
a
feature
to
that
becoming
an
acceptance
criteria
in
your
stories,
of
course,
stories
epics
right
and
then
you
know
having
clear
definition
of
ready
ready
for
development,
clear
definition
of
done.
What
does
it
mean
done
right?
B
Do
you
have
all
the
unit
tests
code
coverage,
functional
testing,
all
the
other
things,
so
all
those
things
are
being
measured.
How
long
the
story
takes
that
lead
time
right
all
the
way
to
production
that
is
being
measured.
How
many
bugs
resulted
from
a
story
from
a
feature
or
from
a
recent
deployment
that
is
being
measured?
So
all
those
things
are
a
combination
of
measured,
metrics
coming
from
jira
from
github
or
for
other
systems
as
well
as
more
soft
one.
That
humans
would
do
that.
B
One
interesting
metrics
that
we
love
to
do
and
by
the
way
one
of
we
we
put
on
our
flag
the
words
empathy,
so
empathy,
empathy,
empathy,
empathy
from
the
developer
to
the
product
manager,
from
the
product
manager
to
the
to
the
to
the
end
user,
from
the
developer,
to
the
end
user
and
from
one
developer
to
the
other
in
across
the
company.
What
does
it
mean?
B
There
is
a
big,
empowering
and
good
feeling
kind
of
for
for
a
person
for
an
individual
to
be
able
to
contribute
and
not
just
like,
go
ahead
and
read
the
manuals
for
weeks
or
months
at
end,
so
being
part
of
that
process.
We
we
make
a
note
and
we
make
a
big
celebration
when
somebody
does
their
first
pull
request
and
we
measure
it
so
did
we
beat
the
record?
Did
you
not
be
doing
it.
C
That's
awesome
and,
and
so
many
things
of
I'll,
be
able
to
nod
my
head
at
a
lot
of
what
you're
saying
gabriel,
and
so
many
things
are
the
same.
We're
also
really
just
focusing
on
on
the
metrics
aspect
there
in
particular
we're
also
pulling
you
know.
Basically,
you
know
stream
of
data,
basically
every
github
event,
right
logging
and
using
that
that
we
can
use
for
data
mining.
C
You
know,
particularly
though
those
time
to
deliver-
and
you
know,
and
and
what's
what's
the
rate
of
delivery
and
things
like
that
and
we're
and
we're
trying
to
take
our
organizations,
our
product
groups
and
be
able
to
show
them
where
they
are
with
respect
to
some
of
those
dora
categories
and
be
able
to
say,
hey,
here's
where
you
are
and
can
we
can
we
track
your
progress
of
visually
maturing
along
those
categories
and
are
is
what
we're
doing
helping
you
you
know.
Can
we
see
that
progress
and
if
not,
why?
C
Because
you
know,
there's
certain
things
we
can
do
here,
gathering
data
and
processing
data
that
helps
tell
a
story,
but
it
only
tells
part
of
the
story
right
and
there's
very
much
a
human
aspect.
Here
of
going
and
saying
hey,
I
see
you're
here
and
in
the
last
six
months
we
put
out
some
extra
tools
and
you're
still
there.
Why?
So
it's
talking
it's
doing
some
developer
surveys
to
get
feedback
on.
You
know:
hey,
we
did
x,
y
and
z.
C
Is
that
helping
do
you
like
it
or
are
we
giving
you
things
that
you
don't
need,
in
which
case
we
better
pivot,
because
it's
very
about
being
developer,
focused
organization
focused,
you
know
we
talked
about
reducing
the
developer
toil
and
that
key
part
of
that
is
quite
simply
just
listening,
that's
more
qualitative
than
quantitative,
but
find
that
at
least
within
dull
our
developers
you're
not
shy
about
complaining
as
long
as
you're
willing
to
listen
so
hearing.
Where
are
what
are
their
pain
points,
I'm
trying
to
say,
okay?
A
Yeah,
I
mean
so
what
I'm
hearing
is
it
it's
it's
as
much
about
measuring
the
impact
towards
you
know
your
your
time
to
shift
to
production,
as
it
is
understanding
if
it's
really
reducing
the
friction
and
the
you
know,
frustration
and
maybe
like
that
layer
of
bureaucracy
or
whatnot
from
the
developer
experience.
So
they
can
truly
focus
on
writing
developing
code,
which
is
what
they
love
and
what
they
want
to
do
versus
the
some
of
the
other
challenges
that
that
could
of
just
like
tooling
or
process
that
could
exist.
B
Yes,
absolutely
so
again,
it's
it's
soft
and
it's
hard
measurement
and
I
wanna
emphasize
again
that
it's
not
only
about
developing
and
deploying
one
of
the
jokes,
not
really
joke
that
I
tell
my
team:
is
that
developing
something
or
creating
something
is
easy.
Maintaining
is
hard
and
operating
is
hard,
so
devops,
really
what
it
means
is
that
the
development
team
also
helps
or
is
part
of
the
operations
of
this
service
in
production.
B
There
is
nothing
more
encouraging
or
motivating
for
you
to
write
good
code
from
not
we
being
woke
up
at
3am.
It
helps
a
lot.
So
you
write
best.
You
write
unit
tests,
the
functional
testing
degree.
You
write
all
those
things
and
every
time
that
you
find
a
bug.
The
first
thing
that
you
do
is
you
write
a
test:
tdd
style,
you
write
a
test
and
then
you
solve
the
bug
and
then
you
move
on
yeah.
A
Fair
enough,
it
looks
like
we
had
a
question
come
in
from
the
audience.
So
let
me
take
a
look
at
this.
How
do
your
guests
companies
comply
with
the
sox
control,
stipulating
separation
of
duties
and,
while
also
in
empowering
teams,
to
adopt
the
devops
ideal
of
implementing
and
deploying
software
to
production,
essentially
violating
the
separation
of
duty's
requirement.
B
B
You
can
say
the
person
that
develops
is
not
the
person
that
delivers
right.
You
can
deploy,
you
can
continuously
deploy,
but
using
feature
flags
etc
in
gates
along
the
way.
A
product
manager
and
operations
can
give
a
thumbs
up.
The
only
warning
there
is
when
you
have
gates
along
the
way
and
don't
have
more
gates.
B
When
I
say
gates,
I
mean
somebody
that
needs
to
give
a
thumbs
up
or
a
couple
of
people
that
needs
to
give
a
thumbs
up,
make
sure
that
you
don't
create
too
much
drift,
so
raise
alerts
when
you
see
too
much
drift
going
on
between,
let's
say,
dead,
environment,
test,
environment,
your
production
environment,
if
the
drift
is
starting
to
be
too
big,
I
learned
that
that
is.
That
is
a
risk,
so
you
can
still
create
some
separation.
B
For
instance,
a
developer
directly
or
by
default
will
not
have
access
to
databases
in
production
right
because
there's
personal
information
there,
potentially
and
many
a
lot
of
sensitive
information
that
the
developer
might
not
be
even
equipped
to
to
handle.
So
it
could
be
that
they
might
get
along
with
an
operations
team
member
access
if
there
is
an
absolutely
need
to
access
a
production
environment.
But
we
try
to
keep
to
give
the
development
team
monitoring
into
what's
going
on
in
there,
while
not
violating
that
kind
of
separations
of
duties.
B
Yes,
so
the
the
problem,
so,
if
you
think
about
the
three
ways
of
devops
drift
means
that
you
have,
let's
say
version
one
sorry
version
10
on
dev
version,
3
on
on
test
and
version
2
on
the
production
environments,
the
more
you
create
a
you
know,
a
bigger
delta
between
each
and
every
one,
and
you
should
always
take
and
promote
from
one
to
the
other.
It's
the
same
artifact
that
is
being
promoted
from
one
to
the
other
per
continuous
delivery.
B
The
there
is
a
more
disassociation
of
both
the
product
manager,
the
development
team
of
saying,
oh
now
we
have
a
problem
in
production.
Let
me
remember
what
I
did
six
months
ago
when,
when
you
have
these
kind
of
things
effectively,
you
don't
have
a
state
of
flow.
So
you
broke
the
first
way
of
devops
of
maintaining
that
continued
state
of
flow
to
make
sure
that
there
is
minimal
drift,
minimal
difference
between
your
different
environments.
C
I
don't
know
when
to
strike
out
the
word
automatic,
but
but
unfettered
and
ungated
right
the
deployment
and
delivery,
and
I
think,
for
perhaps
there
are
some
scenarios
where
that's
okay,
I
think
I
think
in
in
many
products
and
in
many
situations
and
I'm
not
a
socks
expert.
So
I
don't
want
to
particularly
comment
on
that,
but
I
think
in
many
environments
you
know
again
it's
not
about
hey.
A
developer
can
just
make
code
right
and
put
in
whatever
they
want
and
they
just
get
to
go.
You
certainly.
C
We
have
requirements
here
for
reviews,
and
some
of
that
can
be
also.
Then
a
review
process
and
approval
process
for
going
from
a
as,
as
gabriel
was
mentioning
from
a
tester
staged
environment
to
a
production
environment.
Where
right,
you
might
be
wanting
some
final
validation
or
verification
or
you
might
want.
It
may
be
that,
because
your
process,
someone
else,
has
to
do
the
eyes
on
you.
Maybe
maybe
some
developers
available
for
the
code
review,
but
you
do
need
someone
else
that
says
yes,
this
can
be
be
customer.
C
Seen
now
and
I
I
don't
discount
those
things
from
the
phrase
continuous.
The
key
part
of
there
is
that
it's
happening
regularly.
It's
happening
with
automation
and
the
fact
you
know,
and
it's
not
requiring
notable
human
effort
in
there.
You
know
it's
not
all
that
effort
to
go
in
and
say
thumbs
up
right.
You
know
I
approve
and
I
I
would
still
count
those
things
as
part
of
a
continuous
acts
process.
A
Absolutely
you
know
thinking
about
folks
on
this
call
who
may
not
be
as
advanced
in
their
devops
maturity,
as
as
you
are
at
your
companies,
do
you
have
any
advice
for,
for
you
know,
individuals
or
teams
who
are
looking
to
get
started
and
maybe
are
struggling
with
that
initial
phase?
You
know
where
do
you
begin?
B
So
one
of
the
things
I
would
the
approaches
that
I
would
like
to
warn
against.
Let's
start
with
that
is
reading
the
books
that
I
I
truly
like
and
inspired
me
like
the
phoenix
project
and
unicorn
projects
and
others
and
say:
let's
do
that
now
in
a
company
of
7000
or
70
000
that
is
doomed
to
failure,
because
usually
when
you
go
things
from
the
top
bottom
and
you're,
forcing
people
you're
going
to
get
a
lot
of
resistance.
B
What
works
for
us
in
many
cases
is
start
small
start
one
or
two
teams
are
starting
an
initiative
that
is
a
little
bit
green
fields
a
little
bit
new
to
the
company
and
they
can
go
and
establish
new
patterns.
New
new
cultures
with
those
teams
go
devops
for
the
to
the
nth
degree
and
by
the
way,
many
times
it
required
people
that
have
been
in
the
industry
for
decades
to
kind
of
retrain
and
reset
self-included
right
in
and
understand.
B
B
I
would
say,
even
if
the
people
in
that
team
can
be
a
little
bit
more
starry-eyed,
that
helps
a
lot,
because
once
they
show
that
early
success
and
by
the
way
invite
people
to
your
sprint
reviews
due
to
your
agile
spring
reviews,
etc.
So
they
can
see
the
methodology,
so
you
are
totally
transparent
for
the
good
things
that
work
for
you
for
the
not
so
good
things
that
work
for
you
and
pretty
soon
you're
going
to
have
developers
from
the
other
teams
asking
their
managers
and
the
managers
too
asking.
B
Why
are
we
not
doing
this
right
like
it
works
for
them
we're
moving
fast
wow?
Our
product
manager
is
going
to
talk
to
another
to
our
product
manager
and
said.
Why
do
I
have
to
wait
six
months
until
I
get
a
feature
out
the
door?
These
kind
of
thing
end
in
presenting
throughout
the
company
sharing
the
third
way
of
devops
right,
we're
gonna,
sell
white
learning
goes
a
very
long
way.
C
C
You
know
we're
very
fortunate
here
at
dell
that
we
had
from
some
of
the
the
very
top
of
the
company,
this
effort
to
say
again
what
we're
working
on
now
is
really
that
consolidation
of
various
efforts
and
to
say
hey,
we
we
need
to
bring
this
together.
We
need
to
break
down
the
silos
we
can.
We
can
do
things
better
for
us
all,
and
so
that
that
was
great.
C
But
I
know
it's
not
all
about
metrics,
but
very
often
that
speaks
to
some
of
the
management
of
the
company.
If
you're
able
to
show
hey,
look
we're
we're
able
to
go
faster,
we're
able
to
reduce
how
we're
finding
bugs
at
the
end
of
the
process,
hopefully
that
that
can
really
help
get
things
going,
because
again,
we're
really
looking
for
and
very
much
agree
with
gabriel
said
about
starting
small.
Were
you
trying
to
build
up
that
culture
right?
That's
what
we
said
at
kind
of
the
top
here
is
that
it's
really
it's
not
about.
C
On
the
other
hand,
sometimes
maybe,
if
you
do
have
it
you're
having
developers
go.
Oh,
I
don't
know
if
I
want
to
do
that.
Well,
this
is
really.
The
whole
point
is
to
provide
this
benefit
to
these
developers
right
so
look
around
find.
Where
are
they
having
the
most
pain
and,
if
you're
going
to
work
incrementally
on
it
perhaps
say:
okay?
Well,
what
can
I
help?
Where
can
I
start
in
this
process?
That's
going
to
address
their
needs
the
most
and,
as
those
developers
start
to
see
some
of
their
toil,
some
of
their
trouble
go.
C
Oh,
I
I
got
a
report
on
this
early
where
I
you
know
you
saved
me
from
breaking
a
build
right
or
something
like
that.
You
know
I,
hopefully
you
you
start
to
get
these
people
to
buy
in
and
that's
what
you're
in
my
mind,
what
you're
really
looking
for
is
to
have
some
people
see
the
benefit,
and
I
think,
if
you
do,
you
can
get
that
that's
kind
of
snowball
effect,
working
and
hopefully
growing
and
growing
and
becoming
you
know
that
culture
across
your
organization.
A
C
Yeah,
well,
I
I
I
know
gabriel's
got
some
of
things
on
this
one
too,
but
I
think
I
think
we're
aligned
in
our
opinion
so
sure
I
don't
think
it's
a
movement
to
and
from
right
and
at
dell-
and
I
know
that
this
may
be
distinguished
from
gabriel.
We
are
looking
actually
forming
some
devsecops
group,
but
it's
not
separate
it's
not
to
from
it's
part
of
our
devops
team.
C
It's
it's
a
focus
that
we
have,
in
fact
we're
already
doing
some
dev
setups
and
we're
just
looking
to
have
a
person
and
perhaps
a
team
that
can
take
that
security
as
part
of
their
focus
as
part
of
a
larger
organization.
But
it's
not
about
saying,
okay,
you
guys
do
devops
and
you
guys
do
devsecops
right
or
anything
like
that.
C
It's
saying,
no
security
is
a
part
of
devops
right
and
we
want
to,
and
it's
about
bringing
so
much
security
focus
and
in
fact,
one
of
the
things
we're
working
with
other
parts
of
the
organization
on
right
now
is
it's
not
something
we
do
at
the
end?
We
don't
have
a
product
we
developed
it
tested
it.
It's
got
great
features.
A
number
of
our
products
are
things
that
aren't
continuously
delivered.
We
do
have
some
services
like
that.
C
We
have
other,
as
many
people
probably
know,
servers
and
products
that
we
ship,
so
they
occur
at
a
more
separated
cadence.
You
know
months
apart
and
we
don't
say:
okay,
this
is
ready
to
go
out
the
door,
oh
by
the
way,
let's
check
it
and
make
sure
it's
secure
right.
No,
we
bring
that
way
earlier
in
the
process
and
and
so
and
so
yes,
def
secops
might
be
related
to.
B
Take
it
away,
so
there
is
the
movement
of
dev,
I
call
the
dev
asterix,
ops
and,
and
it's
all
part
of
devops
or
if
you
don't
want
to
focus
on
dev.
It's
just
you
know
software
ops
right.
So
it's
devops
and
githubs,
and
I
heard
ux
ops
and
I
heard
mlaps
right.
So
there
are
a
lot
of
them
and
they're
all
very,
very
valid
they're.
All
part
of
the
movement
that
devops
the
you
know
we
bob
you
mentioned
before
shift,
left
and
shift
right.
B
So
if
people
don't
know
what
it
means,
shift
left
and
shift
right,
usually,
when
you
look
at
the
at
a
chart
right
or
a
diagram
of
delivery,
it
goes
from
ideation
on
the
left,
all
the
way
to
delivery
right
and
when
people
are
talking
about
shift
left.
It
means
that
something
that
was
later
on
in
the
process,
you're
moving
it
a
little
bit
more
to
the
beginning
of
the
process
and
shift
right
is
exactly
the
opposite
in
which
something
that
was
at
the
beginning.
Let's
say
development.
B
B
It
means
that
the
developers
need
to
be
aware
as
quickly
as
possible,
even
in
their
ide
or
when
they
did
a
push
to
a
pull
request,
the
pr
that
they
have
something
wrong
going
on
as
far
as
security
right.
So
that
means
maybe
they're
exposing
an
injection
vulnerability.
Maybe
they
introduced
a
third-party
vulnerability.
Maybe
they
committed
a
token
in
there
that
they
shouldn't
be
committed,
and
you
should
know
it
as
quickly
as
possible.
B
We
don't
want
to
wait
until
we
get
further
down
the
line
to
find
that
out
and
then
it's
kind
of
like
we
need
to
go
like
upstream,
which
is
really
really
expensive.
As
far
as
process
is
concerned,
our
security
team,
which
I
would
consider
a
devsec
ops
in
blue
yonder,
is
not
a
huge
team.
You
know
it's
it's
reasonable
size
for
a
company
our
size,
but
they
can't
scale
to
be
in
every
single
team
in
every
meeting.
B
So
we
have
the
concept
of
security
champions
that
are
meeting
on
a
regular
basis
that
are
led
by
our
security
teams.
These
security
champions
are
part
just
part
of
the
development
teams
and
the
delivery
teams
and
ops
teams
and
blue
under
the
exchange
idea.
All
the
time.
Their
role
is
not
to
write
security
in
the
team.
Their
role
is
to
make
sure
that
security,
cross-cutting
concerns
are
being
addressed
on
a
regular
basis.
B
They're
they're,
like
the
cheerleader
of
security
out
there
them,
along
with
the
security
team
in
our
development
support
team,
can
talk
about
later
they're
all
we're
in
charge,
in
collaboration
with
with
the
dev
team,
to
bring
all
these
tools,
including
github,
advanced
security
that
allows
us
to
spot
really
early.
You
know
potential
vulnerabilities
in
our
code,
so
they
have
cells
right,
so
static
analysis,
and
it
allows
us
to
see
whether
we
have
a
token
that
we
committed.
B
These
are
a
lot
of
very
new
capabilities
that
we
have
with
devsicops
that
we
didn't
have
in
the
past
so
effectively.
What
happened
is
that
security
shift
to
the
left
right
and
we
have
early
also
early
reviews
of
development,
so
you're
not
going
to
get
to
the
end
and
said:
oh,
your
whole
architecture
was
totally
insecure.
So
we
have
all
these
things
going
on
and
again,
third
way
of
devops,
we
constantly
share
development
or
or
organizational
wide
learning,
constant
feedback.
Second
wave
devops
and
third
wave
devops,
the
ci
cd.
A
So
security
becomes
the
responsibility
of
every
developer
from
the
impetus
of
the
project,
instead
of
something
that
you
know,
the
historic
old,
maybe
approach
of
developers
throwing
work
over
the
fence,
security
researchers,
throwing
it
back
six
months
later
and
everybody
resenting
one
another.
Yes,.
A
Oh
there
you
go,
I
think,
there's
a
great
question.
I
think
that
dovetails
nicely
with
this,
which
is
you
know
when
you
start
introducing
the
organization
to
ci
cd
and
start
hooking
static
code,
analysis
and
unit
test
coverage
into
that
you'll
hit
a
mountain
of
issues
and
then
you're
stuck
with
the
question:
can
we
ship
or
not?
How
do
you
handle
this
situation.
C
C
A
A
C
C
How
do
I
make
sure
I
never
slip
for
that
baseline
and
you
work
that
down
now
as
far
as
the
other
latent
issues
that
you're
testing
things
for
the
first
time,
I
don't
know
that
that
might
be
the
equivalent
of
I
don't
know
shining
a
black
light
in
your
hotel
room
or
something
and
saying
you
know.
Maybe
I
didn't
want
to
know
what
was
here,
but
but
now
that
I
know
what
do
I
do
about
it?
C
I
I
think
that
that's
got
to
be
a
little
bit
more
of
a
personal
decision
for
those
teams.
Obviously
I
would
I
would
work
on
prioritization
right
of
saying,
hey
what
are
critical
and
if
and
if
I
turned
on,
you
know,
get
up
advanced
security
for
the
first
time
and
found
out
wow
look
at
these
massive
vulnerabilities
we
have.
C
I
would
probably
tackle
that
as
my
number
one
thing
across
the
organization,
and
I
should
be
glad
that
I
know,
but
there
are
probably
other
things
that
you
might
be
able
to
say:
hey
you
know,
we've
lived
with
that
number
doesn't
necessarily
need
to
be
zero,
but
again
no
regressions
and
working
and
saying,
if
I
never
regress
and
I'm
working
then
hopefully
I'm
taking
that
down
over
time.
Okay,
we're
gonna
have
an
experience
with
that.
B
B
All
these
things
you
have
to
make
sure
from
the
get
go
as
the
leaders
that
are
doing
helping
do
this
transformation
that
you
make
it
attainable.
The
worst
thing
that
will
happen
is
that
the
teams
are
just
going
to
say.
You
know
what
the
heck
with
us
we
just
give
up.
We
give
up.
You
know
it
was
better
to
be
in
ignorance,
we're
not
just
not
going
to
do
it.
So
what
we
did
it
before.
B
It's
really
important
to
engage
to
acknowledge.
We
have
a
problem,
but
you
know
what
no
big
deal.
Let's
start
categorizing.
The
problems,
the
one
that
you
know
now
that
are
you
know
if
you
don't
address
them
the
the
way
I
say
it
in
in
louis
under
is
they're
gonna
cause
you
to
be
on
the
wall
street
journal
headline
for
one
of
two
reasons:
either
you
are
hacked
that
is
a
big
no-no
and
b
you're
taking
for
a
ride
to
to
mine
bitcoins
right
make
sure
that
these
two
at
least
don't
happen.
B
The
these
are
the
top
ones.
You
you
don't.
You
know
the
the
company.
You
know
kind
of
image
in
the
company.
You
know
kind
of
like
the
the
the
report
that
he
has
out
there
in
the
market
is
critical.
You
can
allow
yourself
to
do
that,
so
you
have
all
those
things
you
set
up,
and
you
say
you
know
what
first
have
a
ci
cd
many
times
teams
like
developers
deploy
from
their
machine.
B
Make
sure
that
you
do
pipelines
as
code.
Everything
is
code
pipeline
is
code,
configuration
is
called.
Infrastructure
is
called
all
those
things
why?
Why
do
we
do
things
as
code?
Because
when
you
do
things
the
git
ops
way
as
code,
it's
all
auditable,
it's
all
reviewable!
You
can
do
pr,
so
everything
should
be
there.
So
you
set
up
the
criteria
different
level
of
criteria.
You
have
ci
next
step.
10
code
coverage.
B
You
reach
10
percent
in
one
month
ratchet
like
to
quote
one
of
my
colleagues
ratchet
it
up
a
little
bit
now,
let's
see
how
you
can
do
with
20
30,
if
you're
gonna
try
to
go
from
nothing
to
a
hundred
percent
code
coverage
or
to
zero
vulnerabilities,
high
medium
or
low
you're,
just
going
to
lose
the
whole
organization
engagement
on
this.
On
this
move.
A
Yeah
that
I
mean
that
makes
a
ton
of
sense
you
have
to
it
is
that
crawl
walk,
run
philosophy
that
makes
this
manageable
and
understood
and
attainable
it's
better
to
build
on
a
strong
foundation
than
to
try
to
you
know,
put
the
roof
on
first
right.
You
know,
thinking
from
the
the
audience
again,
a
question
around
you
know
can
devops
be
successful
in
an
environment
where
systems
are
monolithic
and
tightly
coupled.
C
C
We
certainly
deal
with
a
number
of
products
that
are
large
monoliths
and
those
are
those
are
where
I
think
we
we
see
return
on
investment,
but
we
it's
difficult
to
hit
that
ideal
state.
You
know
and
of
course
we
never
hit
the
quote
ideal
state,
that's
for
books,
but
but
it's
difficult
to
to
see
as
big
of
a
reward
as
we
can
when
we're
dealing
with
products
with
you
know,.
A
C
C
They
may
not
be
full
delivery
there
unless
you
talk
about
delivery
to
test
and
so
and
working
in
those
environments
to
say,
okay,
because
we,
by
the
way
we're
talking
about
products
that
have
right
existed
for
15
years,
maybe
right
and
that
sort
of
thing
in
these
cases
and
and
to
say,
okay,
we
we're
in
the
door
we're
measuring
we've
got
build
times.
We've
got
cycle
time,
we've
got
delivery
times,
we're
we're
on
some
common
infrastructure
on
how
we
can
do
this
now,
let's
see,
how
can
we?
How
can
we
iterate?
C
Can
we
take
that
chunk
and
and
and
break
it
out,
so
that
when
we
change
that
chunk,
we
can
focus
on
just
building
that
just
testing
that
right
without
having
to
say?
Oh,
we've
got
a
big
monolith
here
that
we
can't
view
any
better,
and
you
know
basically
we
get
our
foot
in
the
door.
I
think
we
can
get
some
benefit
from
that
monolith
and
then
it
enables
us
to
be
able
to
work
and
to
be
able
to
say
hey.
B
So
to
me
I
I
like
to
compare
many
times
companies
to
people
and
in
this
case
it's
transformation
to
devops
or
transformation
and
just
wellness
right
or
exercise
right.
So
you
know,
let's
say
today
you're,
let's
say
you're
a
couch
potato
right,
you're
you're,
not
doing
anything
and
you're,
saying
oh
for
me
to
be
successful
in
you
know,
devops
is
like
for
a
person
to
be
running
a
marathon
or
an
ultra
marathon.
No,
it's
a
spectrum.
B
There
are
a
lot
of
things
along
the
way
that
you
can
still
do
you
saying
I'm
not
going
to
do
anything
because
I
have
monolith.
You
you're
actually
not
looking
really
at
the
details
that
you
have
in
there.
So
you
can
start
by.
You
know
just
go
out.
You
know
you
not
doing
anything,
start
walking
or
start
doing
a
warranty
or
you
know.
B
I
know
I
know
that
people
there
are
some
people
out
there
that
went
from
like
I
don't
know
what
one
or
two
days
to
all
of
a
sudden
running,
seven
or
eight
miles
every
day,
and
they
just
keep
going
it's
a
constant
journey
of
improvement
in
the
case
of
monoliths
or
it's
cousin,
also
known
as
the
distributed
monolith,
which
is
microservices
that
have
to
be
deployed
together.
I
see
it
as
a
monolith.
B
There
are
many
times
a
lot
of
gotchas
that
can
work
much
better,
a
lot
of
manual
processes
that
can
be
improved.
Example,
people
that
build
on
their
local
machines
or
people
that
insist
on
running
their
own
cactus,
because
they
can
think
that
they're
they're
in
whatever
domain
they
they're
doing
right
there.
In
our
case
it's
supply
chain
management
and
they
decide.
B
You
know
what
we
can
write:
ci
cd,
better
than
git
ops
or
any
of
the
other
sas
providers
out
there
not
likely
that's,
not
your
focus
in
life,
so
focus
on
these
kind
of
things,
delegate,
something
that
is
not
your
core
expertise
to
people
that
can
do
it
better.
Yes,
it's
not
like
github
is
zero
downtime
like
we're
working
through
it,
but
I
can
tell
you
that
whether
we
knew
it
or
not
internally,
our
ci
cds
are
jenkins,
has
probably
had
much
more
and
now
we
don't
have
to
worry
about
that.
B
Now
the
developer
can
say:
I'm
going
to
take
my
monolith
write
a
cacd,
that's
the
acd's
code
can
be
reviewed
with
others,
and
now
my
my
build
every
time
that
somebody
does
a
pr
that
can
be
built
on
github
right
things
like
that.
The
other
one
is
don't
store
things
like
binaries
in
git
you're,
not
supposed
to
do
that
right.
You
have
artifact
management
out
there.
They
know
that
github
has
a
github
artifact
right,
use
that
and
then
we
use
immutable,
artifacts
and
then
reuse
them
and
version
them,
etc.
B
A
You
know:
we've
spoken
a
lot
about
devops
from
a
cultural
side,
and
you
know
some
of
the
the
principles
of
bringing
security
left
and
whatnot.
But
you
know
there
is
a
tooling
component
to
a
successful
devops
culture.
So
can
you
tell
me
a
little
bit
about
how
you
manage
the
tech
stack
for
your
devops
practices
and
you
know
any
just
tips
or
best
practices
that
you
would
want
to
share
with
our
viewers?
C
Sure
so
one
of
the
things
that
we
have
again
one
of
our
focuses
on
on
consolidating
bring
things
together,
because
we
didn't
start
that
way
right,
and
so
we
focus
on
definition
of
what
we
call
our
north
star
tools,
which
is
to
say,
hey.
We
we
want
to
bring
the
organization
around
expertise
and
focus
on.
You
know
consistent
use
of
these
tools,
actually
just
consistent
yeah,
you
know
apple
use
of
the
tools
and
then
we
are
have
now
followed
back
through
with
okay.
C
C
As
we
develop
these
tools
and
to
see
hey,
you
kind
of
see
why
we're
doing
it
and
then
on
a
more
technical
aspect.
There's
also
right
coupling
of
these
various
tools
and
actually
or
connection
of
these
various
tools
actually
trying
to
avoid
coupling.
We
personally
have
built
up
an
infrastructure,
that's
focused
on
being
event,
driven
use
kafka,
basically
to
pass
things
around
between
microservices
and
connect
tools
to
tools,
and
that
kind
of
helps
us
bring
up
these
various
tools,
as
well
as
saying
hey.
C
If
we
need
to,
could
we
swap
one
out
basically
and
replace
it
with
another
and
just
kind
of
have
that
glue
without
having
a
super
strong
connection
where
these
tools
are
created,
because
one
of
the
things
that
I
think
we've
talked
about
hit
on
this
today
is
being
able
to
reiterate
and
improve,
and
it's
not
static.
Eventually,
one
of
these
tools,
something
better
is
going
to
come
along
and
we
don't
want
to
be
so
wedded
to
it
that
we
can't
extract
it
from
our
tool
chain.
B
Usually
what
we
do
is
when
we
want
to
use
a
new
tool.
We
do
an
evaluation,
so
a
team
might
start
evaluating
a
tool
and
say:
okay,
let's
take
a
look
at
that
and
let's
bring
it
to
the
bigger
forum
in
a
sense,
we're
doing
a
little
bit
what
I
think
thoughtworks
does
with
the
radar.
So
we
said
like
okay:
these
are
the
ones
that
adopt.
B
These
are
the
ones
that
are
evaluating,
but
the
ones
that
are
evaluated
are
not
only
the
the
development
support
team
or
the
tooling
team,
but
the
teams
in
the
company
as
a
whole,
and
then
they
bring
it
over
once.
We
want
to
encourage
to
use
a
certain
tool
that
we
have
at
our
tool
chain.
We
try
to
ask
the
team
to
write
an
adr,
because
we
want
to
be
able
to
defend
our
decision
to
everybody
and
say:
oh,
why
don't
you
use
this
thing
tomorrow
and
that's
in
tomorrow?
B
There
is
a
lot
to
be
said
about
the
tension
between
governance
and
autonomy.
Right
total
autonomy
is,
is
really
anarchy
in
effect,
so
you
let
everybody
do
so
you're,
not
reaping
the
benefits
of
standardization
and
being
able
to
move
faster
and
not
to
have
to
relearn
and
to
reinvent
the
wheel.
However,
if
you
go
too
heavy
on
governance,
then
you
are
really
not
agile
you're,
not
focusing
on
trends
in
the
market.
So
we
constantly
encourage
teams
to
teach
us
in
the
architecture
group
and
in
the
development
support
group
about
these.
B
So
I
said
there
is
no
devops
team.
What
I
actually
meant
is
that
there
is
actually
a
devops
enablement
team
which
includes
the
tooling
and
encouraging
people
to,
for
instance,
contribute
open
source,
inner
source,
reusable
github
actions
and
code,
ql
queries
and
all
those
things
that
we
get
fed
from
the
rest
of
the
organization,
so
that
that
has
to
be
critical
to
everything
else
that
we
do,
because
otherwise,
you
are
going
to
be
designing
for
a
bottleneck.
Pretty
much.
A
Yeah,
that's
a
great
point
and
you
know
I
I
do
want
to
thank
you
both
for
this
amazing
conversation.
We
covered
a
lot
of
ground
and
answered
a
lot
of
great
questions
from
the
community
as
well.
I
did
want
to
let
folks
know
that
you
know
if
you
have
additional
questions,
that
you
want
to
speak
directly
with
someone
at
github
help
you
answer.
Those
do
feel
free
to
hit
that
request
a
demo
button.
A
We
can
get
in
touch
with
you
and
you
can
just
sort
of
pose
those
directly
to
some
of
our
experts,
otherwise
gabriel
or
bob.
Do
you
have
any
other
closing
remarks
that
you
wanted
to
to
make
before
we
head
off
and-
and
there
is
a
survey
up
for
the
folks
on
the
audience,
I'd
love
to
have
you
just
take
this
little
quick
questionnaire?
Let
us
know
how
we
did.
B
B
You
always
feel
like
you're,
like
a
snowflake
you're
different
than
others,
so
you
shouldn't
change
you're,
not
that
different
to
quote
fight
club
right,
make
sure
that
you
see
what
you
can
always
change,
bring
it
to
others,
work
with
with
other
people
and
don't
create
bottlenecks
in
your
company.
Eventually,
that
change
will
happen
because
just
people
are
going
to
see
the
benefit
over.
C
Time
and
I
think,
as
we
said
before,
work
incrementally
right,
don't
don't
feel
like
you
need
to
your
failure.
If
you
don't,
you
know,
run
that
marathon
right
away
as
as
gabriel
put
it
work
incrementally
you
know,
get
some
benefits.
Let
that
snowball
build,
and
I
think
that
you
know
you'll
find
yourself
in
a
in
a
you
know
before
too
long
might
take
some
time
for
too
long
in
that
culture
as
people
are
are
seeing
and
reaping
the
benefits
will
want
to
continue
right
and
they'll
want
to
develop
more.