►
Description
What are the most common DevOps pitfalls to look out for when building a successful, impact-driven workflow? Join us for an interactive discussion kicked off by our hosts Shira Marks, Senior Product Marketing Manager at GitHub, and Tug Grall, Principal Solutions Engineer at GitHub, who will facilitate the conversation. We’re excited to hear from our attendees as we talk through the DevOps challenges businesses are facing today and learn from each other on shared solutions
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
So
I
am
one
of
your
hosts
today.
My
name
is
shira
marx
and
I'm
a
senior
product
marketing
manager
here
at
github,
and
I
really
focus
on
you
guys
in
this
call
our
enterprise
audience
and
the
culture
and
thought
leadership.
It
takes
to
create
that
real
devops
experience
and
I
am
joined
today
by
tug
one
of
our
principal
solutions,
engineers
tug.
Do
you
want
to
introduce
yourself
really
quick.
A
And
tug
was
being
a
little
bit
honest
or
modest.
I
should
stay
in
addition
to
being
one
of
our
amazing
principal
solutions,
engineers.
He
has
a
background
in
development,
so
he's
been
there
he's
done.
It
he's
had
those
feelings
he's
wanted
to
pull
his
hair
out
the
same
as
you,
so
we
are
really
excited
to
join
so
a
few
sort
of
housekeeping
items
kind
of
about.
What's
going
to
happen
today
and
this
amazing
gold
cast
video
platform
we're
on
there's
a
our
goal.
A
Today
is
for
this
to
be
a
conversation
chuck,
and
I
talk
to
each
other
all
the
time.
We
don't
need
to
talk
to
each
other
anymore.
We're
really
here
to
talk
to
you
and
there's
a
couple
of
ways
that
we
can
do
that.
One
is
through
chat,
so
you
can
go
ahead.
Share
like
comment
chat
with
your
peers
in
the
chat
function
on
the
right
hand,
side
of
your
screen.
A
A
If
you
are
comfortable
throughout
the
session,
we're
going
to
be
starting
we're
going
to
be
participating
in
a
few
different
polls
to
understand
who's
in
the
room
and
where
you're
at
and
what
your
devops
maturity
model
looks
like
and,
of
course,
if
at
any
point
in
this
conversation,
you're
starting
to
say
hey,
it
sounds
like
you
know,
a
true
devops
conversation,
a
devops
culture,
conversation
or
a
github
conversation
could
really
help
on
the
top
of
your
screen
kind
of
on
the
right
side.
There's
a
request,
a
demo
button.
A
You
can
just
click
that
and
it'll
get
you
everything
you
need
for
us
to
be
back
in
touch
with
you.
So
remember
conversation.
We
are
here
to
learn
from
you
to
talk
to
you
you're
here,
to
learn
and
talk
to
each
other,
so
be
sure
to
participate
in
chat.
Raise
your
hands
come
on
video.
I
have
been
challenged.
I
have
a
secret
number
in
my
head
on
the
number
of
people
I'm
trying
to
get
on
video,
so
we're
gonna
all
work
together
to
see
if
I
can
get
that
done.
C
A
A
We
having
fun
yet
amazing,
so
you're,
just
gonna,
hear
from
me
for
a
few
more
minutes
and
then
we'll
start
to
hear
from
tug
and
from
all
of
you,
but
to
set
this
stage
a
little
bit.
Let's
talk
about
devops,
so
sometimes
you
know
when
you're
out
in
the
market
or
you're
sort
of
on
websites,
you
think
devops.
Oh,
it's
just
tools.
It's
technologies,
it's
ci
cd!
It's
this!
It's
that
it's
all
of
these
different
little
pieces,
but
we
here
at
github
believe
so
profoundly.
A
That
devops
is
so
much
more
than
just
tools
and
there
are
three
major
elements
of
devops
that
we
want
to
dig
into
today
and
keep
in
mind.
These
are
not
the
only
elements
of
devops,
but
these
are
ones
that
we
feel
are
so
important
that
github
can
really
help
you
with
the
first
is
creating
a
collaborative
organizational
culture,
because
culture
defines
how
we
work.
It
defines
how
we
work
together.
It
defines
how
we
work
alone.
A
It
defines
the
way
that
our
work
gets
done
and
creating
an
organization,
organizational
culture,
that's
collaborative
that
has
people
working
together
is
going
to
allow
you
and
your
teams
to
bring
the
best
ideas
to
the
forefront
in
that
true,
like
renaissance
public
square
way.
The
second
is
automation
and
technology.
We
really
want
to
focus
on.
How
can
you
take
that
collaborative
culture
and
elevate
it?
So
it's
also
an
efficient
culture.
That's
built
on
the
right
tools
for
your
automation,
so
you're
not
redoing
the
same
work
over
and
over
again
you're,
not
doing
manual
work.
A
We
want
to
say
there
is
no
way
to
get
this
right.
There's
ways
to
get
this
better
and
hopefully,
every
day
I
get
how
we
do
it
a
little
better.
Hopefully,
every
day
your
companies,
we
do
it
a
little
better
but
every
day
we're
going
to
learn
from
the
successes
and
the
failures
of
what
we've
done
in
the
past
and
that
culture
changed
a
collaborative
automated
one
that
is
focused
on
improvements.
A
A
I
love
to
go
around
and
talk
about
how
amazing
and
incredible
a
devops
culture
is
and
how
we
can
make
it
and
what
it
looks
like.
But
let's
be
real.
We
need
to
understand
why
who
cares?
Well,
there
are
so
many
benefits
of
a
strong
devops
platform,
but
there
are
few
I
want
to
focus
on
one
is
this
developer
experience
which,
which
comes
from
increased
developer
productivity,
which
usually
leads
to
developer
happiness
and
a
true
sense
of
belonging
through
that
collaborative
culture,
saying
I
am
part
of
this
team,
this.
A
A
Next,
we
have
high
quality,
secure
code
built
with
automations.
So
what
what's
going
to
happen
when
you
have
happier
developers
with
a
better
developer
experience
you're
going
to
get
better
code?
And
that's
really
what
we're
all
here
for
to
help
you
and
your
teams
get
better
code.
That's
error.
Free
bug,
free
secure,
the
first
time
with
reduced
manual
effort
and
reduced
redundant
work
through
automations,
and
all
of
this
we
got
to
get
to
that
key
business
outcome
here,
because
that's
what
we're
here
for
right!
A
That's
not
just
something
that
us
over
here
at
github
like
like
to
chit
chat
about,
because
it
makes
us
feel
good
inside
it
has
this
real,
profound
business
effect
and
with
that
I'm
gonna
pass
it
over
to
tug
and
we're
gonna
get
into
sort
of
the
conversational
and
sharing
and
best
practices.
Part
of
this
conversation.
B
Thank
you,
so
one
of
the
first
steps,
or
one
of
the
first
thing
when
we
talk
about
devops,
is
really,
as
you
mentioned,
set
up
a
specific
culture.
A
way
people
will
collaborate
together
and
for
this
it's
really.
How
do
you
define
on?
How
do
you
organize
your
enterprise,
your
teams,
to
to
share
the
same
kind
of
goals
regarding
the
better
time
to
market
regarding
the
security
and
so
on
an
example
here?
B
Is
we
have
multiple
teams
in
an
organization
in
a
company
from
a
core
javascript
developers
from
the
security
expert
or
product
management,
product
marketing
team?
We
need
to
be
sure-
and
this
is
one
of
the
key
points
when
you
want
to
start
your
process
on
start
your
devops
journey.
They
have
a
good
communication.
B
A
A
So
we'll
give
you
about
maybe
five
more
seconds
and
then
we'll
go
ahead
and
we'll
tug
it
down
and
get
ready
for
us
to
call
on.
You
know:
ask
for
input
from
you
know
people
all
across
the
the
different
teams
that
we're
seeing
on
it.
You
know
expectedly
a
lot
of
product
development
and
engineers,
couple
security,
experts
and
so
on.
I
think
we
can
close
the
poll
now
angelica.
A
We
would
love
to
say
okay,
so
we
know
that
there's
a
lot
of
you
in
the
room
right
now.
We
want
to
hear
from
you.
When
is
a
time.
Can
you
give
us
an
example
of
times
that
collaboration
has
really
improved
the
devops
process
or
a
lack
of
collaboration
has
really
hindered
you
and
how
you
sort
of
took
advantage
of
the
the
devops
culture
to
help
you
get
a
little
bit
further.
A
A
Security
brings
in
a
whole
new
sort
of
element,
a
whole
new
ballgame
that
we
want
to
take
really
really
seriously
so
we
sometimes
use
devops
and
we
sometimes
you
use
devsecops
depending
on
the
situation
and
what
problems
we're
trying
to
solve.
But
if
but
devsecops
is
absolutely
terminology
we
use,
we
are
focused
so
incredibly
going
forward
on
security,
but
you
know
what
that
is
an
april
28th
problem.
A
So
if
you
join
us
for
our
sessions
we'll
talk
about
tomorrow,
those
are
going
to
be
a
hundred
percent
of
suck
ups,
the
whole
time
so
getting
back
to
it.
While
we're
waiting
for
some
people
to
sort
of
raise
their
hand
or
or
share
in
chat,
and
then
we
can
call
on
you
tug,
why
don't
you
tell
us
a
little
bit
about
some
of
your
experience
as
a
solution
engineer.
B
I
think
it's
it's
one
thing
that
I
would
like
to
share
with
you,
typically
with
a
lack
of
collaboration
or
communication
between
teams.
Not
long
time
ago,
I
was
working
with
a
government
agency
here
in
in
france,
as
you
can
guess,
for
my
accent
I
am
from
france
and
where
they
were
the
development
team.
B
In
the
same
time,
they
didn't
communicate
enough
early
enough
with
the
operation
team
talking
about
what
they
want
to
do
and
nothing
happened,
so
they
were
able
to
develop
faster.
They
were
able
to
package
faster,
but
nothing
happened
to
the
deployment.
So
we
start
to
see
and
discuss
with
the
operation
team.
We
we,
as
a
github
team,
arrived
a
little
bit
after
this
file,
and
we
realized
that
not
sharing
the
same
goal
at
the
beginning
was
a
big
issue,
but
also
a
big
big
part
of
the
problem
was.
B
The
trust
was
the
trust
between
the
team,
so
the
operation
team
didn't
trust
the
development
team
to
deliver
proper
software,
with
good
quality,
having
a
good
understanding
of
what
the
challenge
of
the
operation
team
is
or
are
we
always
have
to
have
a
very
clear
communications
understanding
of
the
challenges
and,
step
after
step,
you
will
have
the
team
solving
that
somebody
asked
about
you.
Just
you
were
just
mentioning
about
devsecops.
It
will
be
very
interesting
to
have
if
somebody
in
in
in
the
room
wants
to
come
online
and
turn
on
the
camera,
to
explain.
B
For
example,
why
do
you
think
devsecops
or
security
was
an
afterthought,
because
this
is
exactly
a
good
point
where
communication
is
key?
Just
sharing
your
experience
is
important
for
us,
it's
important,
for
you
also
to
understand
which
challenges
did
you
get
on?
How
did
have
you
sold
them
when
you
were
starting
to
work
together
as
a
teams?
A
Sorry,
if
I
mispronounced
that
who
said
that
she's
a
front-end
engineer
and
consultant
and
a
government
client
mina,
would
you
like
to
come
on
screen
and
share
a
little
bit
with
us
about
what
that
is
like
and
how
you
communicate
within
the
government,
I'm
from
america
and
we
have
a
everyone
knows:
the
government
is
very
bureaucratic
and
it's
hard
to
collaborate.
So
I
would
love
to
hear
about
your
experience,
maybe
in
different
parts
of
the
world,
if
you're
comfortable.
A
A
Oh,
we
have
a
short
one
sucks.
So
I'll
just
tell
you
a
little
bit
about
my
experience
while
we're
waiting
for
mina
to
talk,
so
I'm
on
more
of
the
product
marketing
product
management
side,
and
it
is
honestly
so
helpful
for
me
to
have
the
collaboration
with
the
engineers
and
understand
what
all
the
different
teams
are.
Frankly,
I
used
to
code,
I'm
not
going
into
the
code
anymore,
but
I
can
come
in
and
I
can
see.
Oh
we've
pushed
this
release.
A
B
A
B
A
Because
I
think
it's
a
really
good
question
gary,
if
you
want
to
come
and
join
us
on
screen,
I
think
we
can
have
a
couple
of
you
on
screen
as
well.
We'll
give
you
just
a
few
seconds.
The
bottom
right
hand
side
of
your
corner.
You
should
be
able
to
see
like
a
video
button
if
you
might
have
to
allow
chris,
for
some
permissions
looks
like
mina
is
trying
to
to
get
in
here
as
well.
C
A
D
A
D
Yeah
and
something
that
we
have
came
across
recently
is
our
team
is
relatively
far
along,
I
would
say
within
our
our
devops
journey
and
we
were
kind
of
thinking.
Whilst
we
were
in
this
meeting
that
this
is
all
well
and
good
us
attending
this
meeting,
but
in
actual
fact
we
need
to
relay
this
information
back
to
other
parts
of
the
business
and
effectively
convince
them
that
devops
is
better
than
idaho.
B
So
not
really
a
question,
but
also
not
directly
to
you
our
comments
and
hoping
that
somebody
else
will
jump
also
to
share
the
experience
is
one
of
one
of
the
key
part.
Is
you
don't
sell
devops
as
a
term
or
something
you
really
sell?
The
goal
of
develops
being
you
want
to
have
faster
time
to
market,
when
I
say
faster
time
to
market
is
just
make
sure
that
you
can
deploy
sooner
faster,
but
also
do
that
in
a
very
secure
way,
secure,
valuable
way.
B
B
B
Where
do
you
define
a
specific
metrics
and
adapt
that
to
the
flow
and
obviously
from
an
engineer,
point
of
view-
and
this
is
something
we
will
see
later-
it
starts
with
the
automation
part
and
by
trusting
the
people
together,
you
should
be
able
to
to
achieve
this.
Anybody
else
would
like
to
share,
because
you
know
shira
and
myself.
We
are
working
at
github.
So,
first
of
all,
we
are
not
working
in
engineering
teams,
so
we
don't
deliver
the
software
directly.
A
I
think
we,
I
saw
some
good
comments
from
dill
and
steven
or
stefan,
who
maybe
want
to
want
to
join
us
and
gary
on
stage
we
can
have
a
little
bit
of
conversation.
It
sounds
like
stefan
or
stephen
is,
is
working
on
a
smaller
team
and
he's
and
he's
having
some
success.
So
if
you
two
want
to
join
us,
I
think
we
could,
you
know,
have
really
share
some
best
practices.
A
B
It's
it's
really,
this
part
for
me.
That
is
obviously
you
always
have
to
start
small.
Don't
it's
not
a
big
bomb
right
if
you
go
and
you
ask
people
that
have
been
working
for
when
I
take
this
example
with
the
government
agency,
one
of
the
biggest
challenge
it's
people
saying
we
have
been
doing
that
this
way
forever.
So
why
changing?
B
And
once
again,
why
changing?
Because
we
can
do
it
better
for
the
customer
for
the
user
for
the
public
at
the
end,
it's
not
about
having.
Obviously,
we
insist
on
the
the
happiness
of
engineering,
engineers
and
happiness
of
I.t
people,
but
at
the
end
is
we
want
to
have
our
users
happy,
so
maybe
mina
you
want
to
to
share
welcome
on
stage
and
if
you
want
to
to
share
some
some
of
your
experience.
E
I
am
part
of
well
we're
about
seven
people
in
total,
we're
we
are
two
people
in
front
and
and
my
experience-
I've
always
dabbled
in
devops
in
my
different
roles
and
companies
that
I've
worked
at,
but
that
this
particular
on
this
particular
project
I
had
to.
I
had
to
really
kind
of
drive
it
and
take
lead,
because
the
other
person
on
my
team
isn't
so
comfortable
doing
devops,
and
my
experience
has
been
that
I
think
it's
easy
to
start
doing
devops,
but
to
get
the
buy-in
from
everybody
is
hard.
E
Comfortable
and
frankly
not
everybody
is
interested
in
doing
it.
You
have
to
you
have
to
like
it
yeah
you
have
to
like
it
on
some
level
or
at
least
think
it's
kind
of
cool.
So
what
happens?
I
kind
of
did
the
groundwork.
I
laid
the
groundwork,
we're
working
within
we're
actually
working
with
a
completely
different
platform,
but
I
thought
that
would
be
like
this
natural
progression,
where
one
person
sets
it
up
and
then
everybody
kind
of
jumps
on
board,
which
has
not
been
my
experience.
E
It's
even
if
you
write
the
best
documentation
in
the
world
with
the
most
detailed
instructions,
the
barrier
to
entry
seems
really
high
with
devops.
So
what's
turned
out
on
our
team.
Is
that
it's
basically
two
people
myself
and
another
senior
guy
who
have
in
a
way
we
we
drive
it
we've
taken
ownership
and
we've
just
accepted
that
other
people,
you
know,
and
I'm
not
saying
I've
given
up.
B
So
this
is
yes
this.
What
you
sent
me
now
is
is
an
important
part.
It's
small
small
step,
baby
step
like
everything
we
do
in
it.
Usually
you
you
won't
say
I'm
moving
to
the
cloud
tomorrow.
I
am
doing
devops
tomorrow.
It's
something
we
have
to
go.
We
have
to
be
honest
about
the
impact
we
can
have
as
a
technical
people,
but
in
the
same
time,
I
am
a
big
believer
of
results.
B
When
you
have
the
result,
when
you
can
show
to
people
the
benefits,
they
will
slowly
step
by
step,
even
the
people
that
were
very
skeptical
at
the
beginning,
so
because
I'm
sure
that
if
I
don't
know
how
many
people
we
are
in
the
room
today,
but
if
we
ask
what
is
devops,
we
probably
have
10
20
50
different
view
of
the
world.
This
is
why
we
started
with
sierra
to
talk
about
really
the
cultural
challenge
at
the
beginning.
It's
something
that
we
have
to
change
and
changing
people
is
the
hardest
changing
of
technology.
B
B
If
not,
you
take
some
time
baby
step
like
you
did
people
two
people
will
start
to
move
the
stones
and
you
will
start
to
show-
and
I
think
it's
important-
for,
for
example,
when
gary
asked
the
question
is
by
showing,
after
one
two
or
three
release,
that
transparently
get
the
release
out
with
no
problem
or
even
if
they
are
a
problem,
they
can
roll
back
quickly.
The
issue
you
show
the
benefits
of
what
they
have
done.
What
you
do
today
compared
with
what
you
have
done
previously.
A
E
A
Technical
changes
that
come
with
it
for
sure
absolutely,
but
it's
a
culture
change,
and
so
this
is
a
time
where
I'm
actually
going
to
encourage
all
of
us
in
the
room
to
learn
from
our
sales
teams
and
say
documentation's
not
going
to
get
it
right,
cool
tools
not
going
to
cut
it.
I
think
you're
really
pinpointing
the
right
thing.
You've
got
good
documentation.
You've
got
the
right
processes.
A
We
have
to
start
to
think
about.
How
are
we
bringing
the
people
along
in
the
journey?
Why
is
this
valuable
to
that
team?
How
is
it
going
to
make
their
life
easy
think
about
it
as
the
big
bad
word
sales
process
of
creating
that
culture
change,
and
I
know
that
feels
icky
and
it
feels
like
not
what
we
do
here,
but
I've
been
on
the
development
side
and
I've
been
on
the
sales
side,
and
let
me
tell
you
they're
both
really
hard
jobs
and
when
you
bring
it
together,
it's
probably
harder
than
anything
else.
A
So
please
don't
tell
the
rest
of
github.
I
said
that
we
should
maybe
think
like
sales,
but
we
really
want
to
be
thinking
about
selling
the
value
of
the
culture
change,
as
well
as
doing
all
of
the
documentation
and
the
process
change
the
tool
change.
It
seems
like
in
the
chat.
I
may
not
get
fired
right
this
minute,
but
happy
to
continue
this
conversation
all
the
time.
This
is
one
of
the
soap
boxes
I
like
to
get
on.
A
B
I
think
I
don't
even
need
to
to
put
the
deck
on.
We
it's
something
because
and
it's
interesting
to
what
you
said
you
know
when
we
talk
about
and
if
you
look
at
other
questions
is
very
often
when
we
talk
about
devops,
we
will
focus
on
cicd
first,
because
we
are
engineers.
So
as
an
engineer,
we
want
the
tools.
We
want
some
technology
to
help
us
to
solve
something
and
at
github
we
usually
when
we
talk
about
ci
cd,
we
step
back,
and
we
say
no,
it's
not
about
ci
cd.
It's
about
automations.
B
We
want
to
automate
everything
as
much
as
possible.
Right
and
like
I
did,
like
I
said
before,
step
by
step,
so
one
part
will
be.
The
ci
is
an
automation,
so
continuous
integration
making
sure
that
all
the
all
the
tests
are
done
automatically
all
the
packaging
is
done
automatically
and
you
have
the
cd,
the
continuous
development
that
potentially
help
you
to
deploy
completely
from
the
commit
to
production
without
any
human
interaction-
and
I
think
here
it's
time
also
as
a
follow-up
to
this
discussion,
to
bring
the
second
poll
about
about
the
automation
and
about
how.
B
B
B
B
Do
you
need
to
go
faster,
because
sometimes
you
don't
need
to
go
faster
than
what
you
have
today
and
for
people?
If
you
some
of
you,
if
you
are,
if
you
are
deploying
multiple
times
a
week,
multiple
time
a
day
or
every
day
you
I
will,
I
will
be
very
interested
to
hear
for
you
on
from
you
on
sharing
with
the
rest
of
the
audience.
A
If
yeah
yeah,
yeah
par
partha,
if
you're
able
we'd
love
to
come,
join
love
to
have
you
come
join
us
if
you're,
not
I'll,
try
to
represent
a
little
bit
of
what.
I
think
that
you're
saying
she's,
saying
that
or
he's
saying
that
it
is
they're
really
starting
to
use
those
dora
metrics
that
you
may
have
seen
in
the
keynote
yesterday.
A
The
space
framework
the
good
day
project,
as
well
as
nicole
forrest
grant's
previous
work
in
the
book,
accelerate
just
begin
to
start
to
measure
their
success
so
that
they
can
get
to
the
level
of
automation
and
collaboration.
That's
going
to
result
in
some
of
those
weekly
daily
or
multiple
times,
a
day
shipments,
and
that
is
so
exciting
and
we
love
to
hear
that
we
really
stand
by
those
metrics
all
the
time
it
looks
like.
A
We
also
have
a
comment
from
dell
once
again
welcome
on
stage
if
you're
able
to
turn
your
camera
on
and
we'd
love
to
hear
you
talk
about
talk
about
what
you're
saying
but
dill
shares.
We
are
interested
in
increasing
developer
productivity
by
allowing
developers
to
ins
to
install
software
tools
or
download
open
source
binaries
securely
get
scanned
and
validated
in
sandbox
before
it
enters
into
our
company
network.
Currently
we
have
no
solution
for
this.
Is
that
something
that
github
or
other
microsoft
solutions
can
resolve?
Now?
A
B
So,
on
on
the
pure
secret,
what
you
are
asking
about
security
is
really
not
inside
the
software
factory
when
you
are
developing.
If
I
understand
correctly
it's
before
when
you
want
to
bring
stuff
inside
your
software
factory,
one
part
that
is
interesting
is
if
it's
dependencies
on
libraries.
So
not
the
tools
you
will.
You
will
have
tools
like
security,
like
that,
we
include,
like
the
pandabot.
You
will
learn
more
tomorrow
about
security,
where
it
gives
you
at
least
not
as
a
scan,
but
always
an
information
that
everything
is
up
to
date
on.
B
If
we
have
a
known
vulnerability
somewhere
that
has
been
discovered,
you
will
be
immediately
alerted
on
the
system.
Github
will
help
you
to
to
quickly
patch
or
remediate
to
this
issue,
so
open
source
library.
Yes,
we
have,
you
have
everything
you
need
as
part
of
the
dependent,
but
for
the
tools
itself.
It's
a
little
bit
challenging.
You
have
so
many
tools,
so
one
thing
that
I
will,
I
will
say
is
it
depends
which
type
of
application
you
are
building,
which
type
of
tools
you
are
talking
about.
B
For
example,
what
we
see
more
and
more,
it's
not
about
the
development
tools
themselves,
because
programming
language
compiler,
this
one
are
kind
of
safe.
You
know
which,
which
version
you
are
using,
and
you
can
even
use
technology
like
codespaces
to
be
sure
that
everything
is
running
on
github
cloud.
Nothing
is
coming
inside
your
system
until
this
unkill
is
it's
built,
it's
more
about
the
libraries
I
just
talked
about,
and
if
you
are
integrating,
for
example,
containers.
So
you
are
building
modern
application.
B
Your
containers,
you
can
also
scan
this
using
tools
inside
guitar
when
you
bring
them
when
you
build
when
you
deploy,
you
can
scan
in
different
parts
the
the
container.
So
it's
this
overall
part
is
bringing
trust
and
automation
inside
your
system
to
be
more
productive
and
increase
the
developer
productivity.
Typically,
it's
a
good
example.
A
Yeah,
okay,
so
I
think
I
need
to
apologize
to
everybody
for
not
giving
the
best
instructions
in
the
world
for
those
of
you
who
are
trying
to
get
on
video,
if
you
just
click
the
raise
hand
button
next
to
the
chat
window
at
the
bottom
of
your
screen,
we
can
bring
you
on
that
was
sort
of
a
mistake
on
my
part,
I
just
have
a
video
button,
so
I
assumed
you
did
too
so
dell.
If
you
want
to
go
ahead
and
see,
this
is
my
fault,
everybody
I
apologize.
A
A
F
So
so,
we've
recently
started
our
github
journey.
We
were,
we
started
devops
journey
a
couple
of
years
ago,
transitioned
some
pipelines
on
azure
devops
and
now
we've
started
to
move
towards
github
enterprise,
so
we're
getting
used
to
all
the
the
new
tools
and
github
actions,
but
we're
really
at
a
point.
How
do
we
enable
this?
Because
we've
kind
of
learned
looked
at
how
we
did
it
before
as
a
central
team
as
such,
essential
devops
services?
How
can
we
really
push
this
because
not
everyone's
interested
in
the
topic?
F
F
We
haven't
really
sold
it
as
well
and-
and
I
think
we
do
certainly
still
have
these
siloed
conflicts
within
the
organization,
and
I
really
like
the
way,
because
I
never
thought
of
itil
and
devops
as
sort
of
going
in
two
different
directions,
but
now
I
think
about
it.
Actually,
a
lot
of
the
bottlenecks
are
coming
from
the
ops
arena
in,
in
effect,
in
these
old
school
processes,
and
that's
really
what's
kind
of
limiting
us.
F
I
mean
the
time
to
market
just
to
get
your
infrastructure
up
and
running
your
tool,
dev
tools,
so
for
development.
The
developer
experience
yeah.
If
I
wanted
to
do
it
in
an
hour,
it's
impossible
currently
within
our
organization,
so
we
were
really
looking
at.
How
do
we
automate
all
this
tool?
Provisioning?
Because
we
we
usually
want
to
give
developers
a
good
experience
as
well,
so
we
want
them
to
be
able
to
bring
on
their
own
tools,
but
we've
got
such
a
bureaucratic
process
in
terms
of
bringing
in
new
software
tools.
F
Disable
that
but
security
is
a
big
topic,
as
we
all
know,
so
I
was
thinking.
Surely
there
must
be
something
out
there
in
the
market
where
people
say
hey,
this
set
of
software
is
secure
in
a
mirror
somewhere.
You
can
download
it
in
a
sandbox
and
then
publish
it
into
your
network.
Something
like
that
right.
I
was
just
like
brainstorming,
because
it's
a
huge
problem
for
us.
It
can
take
weeks
to
get
developers
set
up
so
not
just
a
cacd
problem
or
a
devops.
It's
a
broader
problem
for
us.
B
This
is,
this
is
a
very,
very
interesting
topic
and
not
directly
a
topic
that
is
about
the
devops
part,
but
really
about
the
dev
that
will
be
the
first
part
and
and
github
has
been
working
for
a
long
time
with
microsoft
and
vs
code
all
together
to
bring
to
answer
exactly
exactly
what
you
said
about
the
onboarding
power.
Have
you
heard
about
github
cut
spaces.
F
B
B
So
a
vm
or
a
container
running
in
the
cloud
that
contains
all
the
secure,
a
securely
secure
kind
of
environment
where
you
can
develop
so
the
onboarding
is
a
non-issue
anymore,
and
when
I'm
saying
that
it's
you
have
to
look
at.
For
example,
if
you
look
at
the
keynote
from
yesterday,
alvin
made
a
quick
demonstration
where
he's
modifying
some
code
in
few
minutes
from
a
container
into
into
the
development
environment,
and
then
all
the
security
will
be
how
do
for
the
for
the
libraries
it's
done
automatically
with
github
dependable.
C
G
G
G
So
as
a
culture
thing
like
we've
discussed
before
is
the
first
thing
I'm
trying
to
introduce
is
kanban
board
and
introducing
that,
like
collaboration,
because
this,
like
I
know
in
bigger
organizations,
I'm
writing
give
up
like
you-
have
both
security
teams-
and
you
know
I
don't
know
many
more,
but
for
here
it's
kind
of
like
mechanical
cloud
and
getting
that
communication
for
that.
Cameraboard
has
really
helped
in
terms
of
the
security
yeah.
G
A
G
G
Day,
like
when's
the
new
version
coming
up
actually,
so
that's
really
helpful
now
to
stop
my
software
team,
it's
just
trying
to
get
that
out
wider,
but
it's
like
what
you
guys
were
saying
before
it's
you've
got
to
start
something
small
and
for
the
rest
of
the
technical
continuum.
We
just
started
off
with
a
whiteboard
and
you
know
kanban
and
I'm
hoping
that
will
transition
over
to
fully
to
github
in
terms
of
improvement
communication.
Just
like
I
mean
it's
devops
and
like
is
sort
of
kind
of
going
into
that
agile.
G
Isn't
it
it's
just
having
their
meetings
where
we're
all
together.
I'm
like
listen,
I'm
not
working
on
this
problem
today,
I'm
just
communicating
it
across
the
team
has
helped
a
lot
because
it
might
be
someone
that
could
go.
Oh
hey,
I've.
I've
experienced
this
problem,
you
know
what
I
mean
and
that
shift
has
has
improved.
Definitely.
B
B
People
are
worried
about
the
changes
putting
in
production
is
a
big
event,
so
people
are
worried
about
changing
anything.
What
how
do
you,
how
your
teams
or
your
teammates
are
reacting
when
you
want
to
change?
I'm
not
talking
about
an
urgent
fix
bug,
because
in
this
case
we
need
to
know
we
need
to
go
fast,
but
adding
new
features,
how
you
do
that
with
your
current
organizations
and
on
teams
so.
G
G
B
G
Actual
but
for
the
end,
yeah
physical,
that's
just
the
whole
way
of
complex,
so
we've
got
to
be
really
careful
with
updates.
You
know,
as
you
can
imagine,
because
if
we
change
something
that
could
you
know,
break
the
whole
system,
but
we
don't
what
we
have
is
like.
I
think
every
engineer
loves
it
don't
need
this
ti
cd
pipeline.
G
I
think
everyone
that's
introduced
to
devops
and
me
personally
when
I
was
first
reading,
it
was
like
c
I
c
c
I
c
d,
dot
d.
I
whatever
acronym,
is
I'm
not
really
in
charge
of
the
releases,
but
they
are
if
it's
database
changes
or
something
big,
there's
got
to
be
a
process
for
it
and
that's
slows
it
down
a
bit.
But
that's
I
don't
know
how
else
you
can
manage
that
personally.
B
But
it's
it's!
It's
like
we
said
at
the
beginning,
it's
a
step
by
step
and
you
learn
on
the
more
you
automate.
The
more
will
be.
It
will
be
easier
and
easier,
because
everything
you
have
done
automatically
and
very
well
tested
before
will
be
able
to
reproduce
exactly
the
same
way.
This
is
one
of
the
the
key
part.
When
we
talk
about
automations
and
ci
cd
screen
on
github
workflow,
I.
D
G
G
B
A
G
A
I
want
to
call
on
connor
carr
we're
going
to
do
a
little
bit
of
public
callout.
It
seems
like
you
have
really
been
thinking
about
this
for
a
while
and
reading
this
about
this
for
a
while
we'd
love
to
have
you
join
us
on
screen
he's
not
in
a
position
to
do
that,
so
we're
just
gonna
move
on
with
our
lives,
but
I
did
see
jason
woods
had
had
some
thoughts
that
he
wanted
to
share
so
jason.
A
And
then
definitely
do
go
ahead
and
look
through
the
chat
that
looks
like
oh
jason
is
also
a
really
noisy
place.
Well,
I
hope
you're
having
fun
wherever
you
are
I'd
like
to
think
you're
at
I
don't
know
disney
world
and
that's
why
you
can't
join
us
on
screen.
But
I
think,
if
you
for
those
of
you
who
are
following
the
chat,
they're,
throwing
out
a
bunch
of
really
good
resources
and
other
things
to
look
at,
I
am
going
to
go
ahead
and
read.
A
A
As
dan
mentioned,
we
set
up
new
devs
with
wsl
using
ansible.
This
enables
them
to
get
up
to
speed
relatively
quickly,
but
the
principles
transcend
the
tech
involved.
Think
itil-wise,
I'm
sure,
maybe
jason
chuck.
It
might
be
easier.
If
you
just
read
this
question
since
it's
like
many
sentences
and
then
you
can
help
summarize
it.
B
You
can
use
some
other
tools
like
your
own
containers,
some
right
and
then
on
further
for
the
e-till
parts.
I
just
want
to
mention
something
before
some
take
the
question.
Take
the
comments
is
on
on
the
on
the
fact
that
you
can
also
we
talk
a
lot
about
application
code
on
the
way
you
deploy,
keeping
in
mind
that
more
and
more
infrastructure
today
could
be
infrastructure
as
code
everything
you
do.
B
Ansible
is
a
good
example
could
be
a
code
that
you
put
in
your
repository
and
then
push
that
the
same
way
in
an
automatic
way.
So
you
will
have
the
process
that
the
process
will
be
done
by
a
ci
cd
workflow
instead
of
a
human
with
manual
interactions.
Maybe
some
you
want
to
comment
on
all
the
different
topics
we
have
covered
so
far.
Some
of
them.
C
H
I
was
just
saying
when,
in
a
previous
organization
we
had
a
thing
there,
our
team
was
trying
to
introduce
ci
cd
and
devops,
and
we
had
quite
a
rigid
cab
process
with
itil
very
structured
around
a
big
change
board
every
week.
So
what
really
worked
was
architecting
up
diagram
of
how
it's
going
to
work
talking
to
the
the
changed
leads
and
some
of
the
ops
guys
and
saying:
look
these
smaller
releases.
H
If
you,
if
we
can
map
them,
say
like
a
minor
release
to
what's
in
your
standard
change,
they
agreed
to
put
it
as
a
pre-approved,
so
we
could
actually
say
front-end
changes
for
the
for
this
particular
website.
These
are
fine
to
go
through
if
you
you're
altering
some
layouts
or
colors
or
branding.
We
started
small
with
those
releases
and
got
them
on
board
and
said:
look
the
time
it
takes
for
ops
teams
to
deploy
this.
H
We
can
put
this
through
jenkins
and
out
for
a
github
action
eventually,
which
is
going
to
save
the
time
of
ops,
team.
Okay,
taking
that
over
from
network
share,
deploying
it
onto
the
web
form
and
just
starting
small
and
building
it
up.
Yes,
but
by
bringing
them
all
into
the
conversation
where
I'm
saying
oh
we're
just
going
to
go
off
and
do
it,
you
get
that
sort
of
devops
culture
going
and
people
actually
talking.
And
then
you
also
spark
that
interest,
because
they
might
have
just
heard
it.
H
H
B
A
H
No
definitely
yeah
that
particular
one
that
particular
one
was
brick
bucket
and
jenkins,
but
we
can
sort
of
transcend
to
get
up
actions
because
you
with
github
you're
gonna,
get
it
all
in
one
place,
but
yeah.
Absolutely
it
was
showing,
rather
than
the
traditional
way
of
zip
files
would
ever
go
to
a
network
share
and
ops
guy
push
it
over
jenkins
did
that
for
them,
published
it
out
to
the
net
to
the
windows
web
farm,
so
yeah,
bringing
that
automation
in,
but
also
helping
up
skill.
These
obscures
were
saying:
look.
H
Was
just
going
to
say
one
of
the
best
things
actually
was
a
meeting
where
we
had
like
a
gliffy
diagram
of
exactly
how
it
works
clear,
clear,
layout,
here's,
the
branches,
here's
the
the
cloud.
Here's
jenkins
deploys
it
to
that
and
then
here's
a
link
to
your
change
process,
so
they
can
see
how
it
all
fits
together.
B
And
she
I
love
this
approach,
because
this
is
typically,
you
have
a
team
leading
it,
but
bringing
everybody
and
ownership
will
be
shared
and,
and
typically
you
are
also
the
oppos,
not
the
opposite,
but
me
as
an
apps
developer.
The
way
I've
started
to
look
at
devops,
at
least
at
the
automation
part.
It's
because
when
you
work
as
using
teams
using
tools
like
github,
you
have
access
to
everything,
so
you
can
contribute
or
start
to
understand
what
the
the
pipeline
is
doing.
B
You
try
to
see
you
want
to
improve
something
you
can
ask
and
you
use
a
collaboration
of
your
infrastructure
or
deployment
process.
Even
if
I
am
an
app
developer,
I
can
learn.
I
can
contribute
and
I
can
start
to
ask
the
the
the
devops
or
the
expert,
oh
by
the
way.
Why
have
you
done
that?
Maybe
we
should
improve
this
part.
What
do
you
think
about
this?
So
they
will
see
not
only
we,
everybody
will
try
to
improve
the
process,
but
also
their
role
will
be
closer.
The
people
will
should
be
closer
and
it's
coming.
B
Naturally,
if
you
keep
the
collaboration
as
a
tool.
So
if
you
let
the
people
collaborate,
you
should
not
make
silos
where
nobody
can
see.
It's
if
you,
if
you
automate
everything
and
you
cannot
all
the
automation
stuff
is
private,
I'm
not
saying
it's.
They
could
be
separated
like
a
github's
approach,
different
repositories
and
so
on,
but
make
sure
that
developers
can
see
how
the
deployment
is
done
and
make
some
contribution
or
commands.
H
Exactly
yeah,
because
if
you've
got
everything
in
the
repo
there,
like
your
github
actions,
so
the
devs
I
came
from
the
dev
side
of
devops,
you
can
lean
more
into
the
upside,
because
you're
seeing
how
the
automation
goes
out
that
side,
you
might
have
ops
guys
that
can
lean
into
the
dev
side
of
devops
and
if
it's
all
in
the
one
stream,
you
can
say.
Okay,
this
is
what
the
action
does.
You
might
not
necessarily
write
it
all,
but
then
you
can
understand
it
how
it
works.
C
A
A
That's
what
we're
doing
just
sweep
you
off?
No
one
wants
you
here,
no
we're
just
kidding.
Thank
you
for
joining
us
sam.
We
have
a
few
requests
for
you
number
one
is
for
those
of
you
who
were
interested
in
digging
in
more
into
the
security
side
of
things.
You
have
two
sessions
tomorrow
that
are
going
to
be
a
similar
format.
Conversations
now.
We
all
know
how
to
get
our
camera
on
one
of
them
that
we
really
want
to
point
you
to
is
how
to
help
developers
prioritize
security
and
software
development.
A
So
this
is
really
going
to
be
about
creating
that
culture
of
shifting
left
that
devsec
ops
experience.
You
can
check
out
the
sort
of
in
focus
website
to
register
and
and
find
the
link
there.
And
then
you
know
what
let's
actually
the
key
takeaway
is
really
quick.
Don't
have
time
to
expand
on
all
of
them,
but
remember
it's
culture,
culture,
culture!
It's
process,
changes
that
we
are
going
to
try
to
get
to
by
automating
as
much
as
we
can
and
simplifying
as
much
as
we
can.
A
If
everybody
wants
to
take
out
their
phones
or
qr.
However,
you
want,
we
do
have
a
feedback
survey
we.
Actually.
This
is
a
relatively
new
event
for
us
and
focus
it's
the
only
the
second
time
we've
been
doing
it.
This
is
a
relatively
new
sort
of
format
of
conversation
for
us.
So
when
we
say
we
want
your
feedback,
this
is
not
just
because
like
oh,
this
is
what
you're
supposed
to
say.
We
actually
want
to
know
if
this
works
or
if
we
should
be
trying
something
different.
A
So
I
can
convince
you
we'll
be
reading
every
single
one
of
those
comments.
Let
us
know
if
you
liked
us,
if
you
liked
the
style,
if
you
thought
the
content
was
good,
was
it
too
technical?
Was
it
not
technical
enough?
Was
it
the
kind
of
things
that
you
wanted
to
get
out
of?
This
because
this
is
all
still
an
experiment
for
us
and
then
finally,
once
again
a
reminder
of
what
we
have
in
coming
up
tomorrow.
We
have
one
more
slide.
A
Well,
first,
we
have
our
thank
you
slide,
so
we
have
once
again
tomorrow
we
have
how
to
help
developers
prioritize
security
and
software
development,
and
then
we
have
our
customer
conversation
which
is
going
to
be,
I,
I
believe,
a
little
bit
less
interactive,
but
really
have
some
of
that
customer
yumminess
learn
how
other
people
are
doing
things
with
shipping,
secure
software
within
the
developer
flow,
with
holcomb,
celius
network
and
solidify,
and
with
that
I
really
do
want
to
take
the
time
to.
Thank
you
all
for
being
such
great
participants.
A
In
this
event,
I
apologize
for
not
figuring
out
how
to
get
you
on
screen
earlier.
I
did
meet
my
quota,
though,
so,
if
you
asked
we,
I
had
a
lot
of
fun.
Hopefully
you
were
able
to
learn
from
each
other
and
we
were
able
to
share
some
some
good
ideas
and
thought
topics.
If
you
want
to
continue
the
conversation
with
us,
you
can
go
ahead
and
request
a
demo
to
talk
to
our
sales
and
solutions.
A
Engineering
teams
as
well
as
you
know,
anybody
else
we
need
to
speak
to
and
with
that,
I'm
going
to
say
really
from
the
bottom
of
my
heart.
Thank
you
for
being
with
us
today
and
thank
you
for
being
part
of
the
github
community,
whether
it's
the
enterprise
community,
the
open
source
community.
We
strive
to
be
the
home
of
all
developers
and
we
love
to
see
the
excitement
around
the
stuff
that
we're
doing.