►
From YouTube: DevOps Explained Using a GitLab Case Study
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Thank
you
so
much
for
joining
today
really
excited
to
talk
to
you
about
devops
and
what
it
is
and
then
kind
of
use,
git
lab
itself
to
help
explain
even
deeper
what
it
means
to
do
devops,
and
so
today,
we're
going
to
cover.
A
You
know
what
devops
is
just
a
quick
overview
of
kind
of
what
it
is
and
why
it
is
then
we'll
talk
about
git
lab
and
what
git
lab
is
and
why
it
is
and
how
the
two
relate
and
then
we'll
review
each
of
the
git
lab
stages,
which
correspond
to
devops
stages,
so
that
you
can
understand
how
each
of
those
fit
into
the
devops
life
cycle.
A
First,
by
way
of
introduction,
my
name
is
brendan
o'leary,
I'm
a
staff
developer,
evangelist
at
git
lab,
which
means
that
I
get
to
spend
time
with
other
communities
in
our
community
and
folks
that
are
really
trying
to
get
code
shipped
into
production
and
understanding
the
problems
that
exist
there
and
we'll
talk
about
what
code
shift
and
production
means.
Even
in
this
talk,
but
in
that
time
I
get
to
spend,
I
learn
a
lot
about
how
other
people
are
thinking
about
shipping
code
and
I
think
it's
really
valuable
and
it's
exciting.
For
me.
A
And
then,
before
that,
I
worked
in
healthcare
software
for
about
10
years
and
I
helped
run
a
small
healthcare
business.
Software
business
focused
on
women's
imaging
and
mammography,
and
so
I've
seen
a
lot
of
different
kinds
of
applications
of
software
and
and
how
you
know
applying
software
to
a
problem
and
then
also
the
problem
of
getting
that
software
to
the
people
that
need
it,
how
those
two
things
can
interrelate
and
all
the
problems
that
come
up.
I'm
also
a
board
member
on
the
cncf.
A
A
Me,
of
course,
through
the
class
methods
and
then
also
on
twitter
at
o'leary,
crew.
That's
just
my
last
name
and
then
c-r-e-w
like
crew
and
I'd
be
happy
to
answer
any
questions.
You
have,
of
course
today,
but
then
also
going
forward
as
you're
looking
into
your
career
in
software
engineering,
or
you
know,
related
fields,
I'd
be
happy
to
talk
with
any
of
you
and
and
share
what
experience
I
can
about
that.
A
But
today
what
we're
really
going
to
focus
on
is
you
know
this
concept
of
what
is
devops
right?
This
might
be
a
term
that
you've
heard
before.
Maybe
you
haven't
heard
it
before
it's
entirely
possible.
It's
not
necessarily
something
that
is
easily
or
often
like
taught
in
many
classes
in
computer
science.
A
But
it's
something
you
all.
You
also
hear
a
lot
around
computer
science
and
software
engineering,
and
you
know
this
concept
of
of
devops.
So
so
what
is
that?
Well,
I
think,
even
before
you
get
to
that,
you
have
to
talk
about.
You
know
this,
these
two
words
that
we've
munched
together
right,
dev
and
what's
dev
and
what's
ops
right.
A
What
are
these
things
and,
and
why
do
they
matter,
and
then
why
did
we
make
this
new
word
well,
dev
refers
to
development
and
the
development
of
software
and
ops
refers
to
operations
and
operation,
operationalizing
that
software,
making
it
available
and
stable
in
an
environment
where
people
can
use
it,
but
then,
okay,
why
did
we
need
this
kind
of
new
word?
Well,
first,
here's
this
thing
like
it's
very
clear
that
software
is,
you
know
our
present
and
and
really
our
future.
A
So
over
10
years
ago,
there's
a
famous
venture
capitalist
named
mark
andreessen,
and
he
said
that
software
is
eating
the
world
and
I
would
say
at
this
point:
software
has
eaten
the
world
right.
Companies
all
around
want
to
do
their
best
and
organizations
want
to
do
the
best
for
their
stakeholders,
but
it's
not
just
being
the
best
in
your
industry
that
counts
anymore,
but
also
being
the
best
in
deploying
and
leveraging
software
in
your
industry.
A
Those
things
are
kind
of
one
in
the
same
now
and
that's
why
it's
such
a
great
career
path
for
folks,
because
you
know
every
company
has
or
is
becoming
a
software
company
and
we've
seen
that
only
accelerate
in
the
past
a
few
years
as
we've
had
to
find
new
ways
to
connect
with
each
other.
During
the
pandemic.
A
A
It's
not
just
companies,
it's
really
any
organization
these
days,
and
so
let's
talk
about
kind
of
how
that
came
to
be
right
and-
and
you
say,
that's
great,
like
I'm
already
on
the
path
there
brendan
I'm
on
my
way,
but
today
I
want
to
look
at
what
you
know
what
it
looks
like
once
you've
you
know
learned
how
to
code,
and
you
know
what
the
industry
looks
like,
and
you
know
what
what
are
these
buzzwords
are
about
right
and
so
to
start.
I
think
it's
easiest
to
start
from
what
we
know
you
may.
A
Some
of
you
may
have
experience
you
know
just
playing
around
and
with
their
own
your
own
code
right,
almost
everyone
who's.
A
professional
software
engineer,
has
a
story
about
you
know
kind
of
messing
around
with
a
computer
when
they
were
young
or
some
code
and
when
you're
doing
that,
that's
that's
a
workflow
that
makes
sense
right.
I've
got
code
on
my
computer,
I
can
compile
it
and
I
can
run
it
locally.
A
I
can
debug
it
and
see
what
changes
like
just
when
I'm
you
know
interacting
with
me
and
my
computer,
it's
great
and
and
that's
again
an
experience
that
a
lot
of
folks
have
had
and
maybe
you've
had
or
you
will
have,
as
you
continue
your
education
and
a
great
story
here
that
I
think
really
pinpoints
this.
A
You
know
difference
between
the
developer
workflow
when
it's
just
me
and
then
getting
something
into
the
world
is
a
story
that
kelsey
hightower
tells
he
he's
a
product
person
used
to
be
a
developer
advocate
at
google,
probably
one
of
the
best
known
folks
in
in
our
industry,
and
you
know
he's
definitely
who
I
want
to
be
when
I
grow
up,
but
he
was
giving
a
talk
and
he
talked
about
how
he
was
teaching
his
young
daughter,
like
html
and
css,
to
like
make
a
web
page
and
design
it
and
put
what
she
wanted
onto
it
and
she
made
it
and
she
had
it
running
and
she
said
oh,
I
want
to
show
it
to
my
friends,
so
I
could
just
send
them.
A
Http
calling
localhost
colin3000
right,
dad
and
he's
like
head
took
a
breath,
and
so
you
know
local
host
is
just
her
computer
local
host
and
it's
not
on
the
internet.
So
he
realizes.
Oh
I've
got
to
teach
her
all
this
other
stuff
now
just
to
be
able
to
share
that
website
that
she
made
with
her
friends,
because
of
course
they
can't
get
to
just
her
computer.
A
If
she's
got
to
put
it
somewhere,
that's
accessible
from
the
internet
and
that's
that's
a
big
challenge,
and
so
there's
these
kind
of
two
major
challenges
when
we
go
from
this
kind
of
you
know,
academic
or
playing
around
version
of
you
know
coding
on
our
own.
To
wanting
to
then
share
what
we're
building
with
the
world
right
and
so
first
is
we're
going
to
want
to
have
probably
more
than
us
involved
right,
we're
going
to
want
to
collaborate
on
that
code
with
friends
or
colleagues
at
work.
A
If
we're
you
know,
employed
professionally
or
anyone
if
we're
creating
an
open
source
project,
maybe
and
then
two
you
want
to
run
the
code
where
someone
you
know
somewhere,
where
everyone
can
see
it.
Right,
probably
I
mean
maybe
not
everyone.
Maybe
it's
only
an
internal
tool,
but
certainly
more
than
just
your
computer
right
and
probably
to
the
internet
and
to
you
know,
app
stores
and
where
you
really
want
those
folks
to
be.
A
Let's
talk
real
quick
about
these
two
challenges.
First,
is
that
collaborate
on
code
and
there's
really
kind
of
two
ways
that
can
happen
right,
so
you
need
source
control.
You
need
this
area
where
you
can
save
the
files
that
everyone
can
access
it.
So,
of
course
you
could
do
that
in
like
sharing
folders
back
and
forth,
and
let
me
send
you
my
new
code
and
you
send
me
yours,
but
that's
really
tough.
A
You
know
think
of
it
as
like:
hey
we
want
to
work
together
on
a
group
project
and
we've
got
to
create
a
document
at
the
end,
and
you
know
what
would
that
be
like
on
in
microsoft?
Word
typically
well,
it's
like
I'm
gonna
have
multiple
copies.
One
person's
editing,
I'm
gonna
send
it
back
right.
This
is
the
old
school
days
of
just
having
a
word
on
your
computer,
but
with
google
docs,
and
then,
of
course,
you
know
word
on
the
web.
A
Now
you
have
this
ability
to
multiple
people
to
edit
at
the
same
time,
there's
only
one
copy
of
it.
You
don't
have
a
conflict
where
you
know,
I'm
changing
the
same
thing
as
you
and
and
we
don't
see
those
changes
together.
I
can
give
feedback
in
real
time,
and
this
is
the
kind
of
the
basic
tenant
of
source
control
or
what
is
the
get
in
get
in
our
name,
gitlab's
name
or
github's
name
git.
Is
this
open
source
tool
that
allows
collaboration
and
merging
of
folders
full
of
source
code
between
developers?
A
And
so
then,
once
you
have
this
concept
of
source
control
management,
something
to
manage
all
those
files.
Now
you
can
move
things
much
more
easily,
so
this
is
like,
then,
a
super
complex
version
of
like
what
a
perfect
flow
looks
like,
but
the
basic
idea
of
git
is:
I
can
create
my
own
branch
and
work
on
it
into
what
I
was
working
on.
A
Where
you
know
that's
the
point
where
the
code
is
merged
and
everything
before
that
on.
My
own
branch
is
safe
from
from
other
folks
and
doesn't
impact
their
workflow
and
but
then
that
send
it
to
a
customer
bit
right.
That's
the
other
challenge
right
in
some
companies.
You
know
back
in
the
day,
that's
literally
sending
someone
something
a
cd
in
the
mail
right
that
used
to
be
how
we
would
send
software
to
customers,
but
that's
not
how
it
works.
Most
of
the
time
these
days
right,
most
companies
run.
A
What's
called
software
as
a
service
or
sas.
That
is,
you
know,
a
website
or
an
app
that
runs
on
computers
that
are
on
the
internet
in
the
cloud
that
can
be
accessed
from
anywhere
and
then
back
in
the
day,
which
again
wasn't
that
long
ago.
These
were
also
two
separate
jobs.
A
Developers
were
writing
the
new
code
and
writing
new
features,
and
then
operators
teams
were
shipping
that,
as
a
cd
or
you
know,
more
likely,
shipping
that
into
their
their
websites
and
apps,
and
a
lot
of
what
you
had
here
is
this
wall
between
them
is
where
you
you'd
hear
about
developers
throwing
code
over
the
wall
right,
they
would
be
done
with
their
side
and
give
it
to
the
operations
and
say
good
luck
and
that
caused
lots
of
problems
because
they
have
conflicting
kind
of
motivations
right.
A
A
developer's
motivation
in
this
case
is
to
you
know,
get
new
features
out
as
fast
as
possible.
Change
it
as
soon
often
as
possible,
and
the
operator
says.
Well.
I
want
the
system
to
be
secure
and
stable
and
reliable
for
our
customers,
so
I
don't
want
to
change
anything
quickly,
and
so
it's
kind
of
that
dichotomy
that
led
us
to
this
concept
of
devops,
because
it's
not
workable.
A
You
know
in
today's
world,
to
you,
know
kind
of
have
this
this
line
between
things
and
have
these
misaligned
incentives
and
be
able
to
be
slowed
down
by
the
fact
that
people
aren't
aligned
right.
That's
like
trying
to
rent
to
dvd
out
of
a
storefront
just
a
little
bit
better
while
netflix
is
doing
this
streaming
thing.
That's
completely
eating
your
lunch
right,
that's
that's!
How
industries
get
changed
by
software
and
so
kind
of
as
a
software
industry,
we
invented
this
term
devops.
A
It
was
about
10
or
12
years
ago,
and
it's
to
me
you
know
it's
all
one
job
right,
getting
the
code
changed
and
live
and
getting
feedback
from
customers
and
then
approving
the
code
again,
isn't
like
a
waterfall
that
steps
down
between
people.
It's
more
like
this
cycle
right
that
is
constantly
moving
right.
Software
is
this
moving
target?
That's
basically
never
complete!
A
Now,
of
course,
that's
a
concept.
That's
much
easier
to
talk
about,
and
I
think
it
makes
maybe
sense
to
you
if
I've
done
a
good
job
of
explaining
the
challenges
before
devops,
but
it's
much
tougher
to
implement
in
reality,
and
so
that's
where
you
know,
of
course,
being
software
developers
we
solve.
That
was
with
software
and
that's
where
git
lab
kind
of
kind
of
fits
in.
A
So
here
you
know,
gitlab
is
this
idea
of
if
you're
going
to
have
a
single
way
of
thinking
and
a
single,
you
know
almost
single
team
of
folks
aligned
to
the
same
thing.
Then
you
want
to
have
one
place
where
they
can
do
that,
and
there
are
many
kind
of
iterations
of
this
before
something
like
git
lab
and
the
modern
day
devops
platforms
existed.
A
So
the
idea
of
a
devops
platform
like
get
lab
is
to
give
you
one
tool
where
you
can
do
each
of
those
stages
of
the
devops
life
cycle,
one
by
one
and
do
them
all
in
you
know
a
tool
continuously
without
having
to
to
kind
of
go
back
and
and
rework
things
or
wait
on
someone
else
to
be
done
with
something
to
continue
the
next
step
in
the
in
the
chain
and
we're
going
to
talk
about
each
of
these.
A
These
life
cycle
stages
right
below
in
just
a
little
bit,
but
just
to
kind
of
give
an
overview
right.
You
have
this
managed
stage
that
you
can
put
at
the
front
of
the
back.
I
actually
put
it
at
the
back
of
the
slides
later,
because
it's
something
that
kind
of
overstates
all
of
those
stages.
We
just
want
to
be
able
to
manage
your
developers
and
your
users
and
folks
that
are
involved
in
the
system.
A
But
you
know
a
lot
of
the
software
development
life
cycle
starts
with
planning
like
what
do
we
want
to
build?
What
does
the
customer
want?
What
are
the
requirements
that
the
customer
has?
What
are
the
requirements?
Our
business
has,
you
know,
what's
the
most
important
thing
to
work
on
next,
that
planning
has
to
happen
and
then,
of
course
you
have
the
creation
of
the
software.
A
The
actual
you
know
writing
of
the
code
and
then,
as
we
mentioned,
you're
going
to
want
to
collaborate
with
people
as
you
do
that
so
you're
going
to
have
to
have
a
way
to
merge
those
changes
back
together
and
approve
them
and
all
kinds
of
other
things
as
you're
creating
the
software.
A
And
then
you
want
to
verify
it
works
you're,
going
to
want
to
do
testing
and
continuous
integration
to
make
sure
that
you
know
the
software
runs
and
works.
As
you
expected
and
then
you're
going
to
package
it
up
somehow
right,
there's
lots
of
different
ways
to
package
up
software.
You
know
I'm
not
talking
about
a
cd
package,
but
there's
lots
of
different
different
software
packages
that
you
might
put
into.
You
might
put
it
into
a
docker
container.
A
You
might
put
it
into
a
package
that
gets
consumed
by
an
operating
specific
kind
of
operating
system,
and
then
next
you
want
to
make
sure
the
software
is
secure.
That
you're
writing
right.
You
want
to
make
sure
that
you're
not
introducing
security
flaws
or
there
aren't
any
known
security
issues
with
the
software
you're
producing
and
then
once
you
know
that
you
can
and
you
have
it
packaged
up.
A
You
can
then
release
it
right
and
say:
okay,
this
is
the
release,
and-
and
this
point
in
time
this
is
the
version
of
software
we're
releasing,
and
we
know
that
that's
in
our
production,
environment
or
our
stage
environment,
we
want
to
know
where
that
is
and
then
we're
going
to
want
to
configure
those
environments
and
say
hey.
How
does
this
work
like?
Do
we
just
ship
it
all
to
production
at
once
and
call
it
a
day
or
do
we?
A
You
know,
do
some
sort
of
smarter
roll
out
of
changes
and
then,
regardless
of
how
we
get
there,
we
want
to
then
monitor
those
changes
and
say:
wait
like
how
are
things
working
and
and
are
they
working
together
and
they're
working
as
expected
and
are
they
up
and
running
and
efficient
and
then
at
the
end,
is
you
know,
protecting
the
environment
as
well?
So
it's
not
just
writing
secure
code
that
goes
into
security.
A
B
Today's
users
expect
applications
that
are
always
on
and
accessible
everywhere
to
keep
up,
centralized
apps
are
shifting
to
distributed
cloud
services
built
and
run
by
teams
all
around
the
world.
With
all
of
this
complexity,
software
teams
need
a
devops
solution
that
enables
them
to
become
faster
and
more
efficient,
while
staying,
secure
and
reliable.
B
Gitlab
makes
you
efficient,
helping
you
improve
productivity,
reduce,
rework
and
work
from
anywhere
all
while
helping
you
build
and
maintain
trust
as
you
reduce
vulnerabilities,
streamline
auditing
and
stay
compliant.
What's
more,
everyone
can
contribute
to
this
open
source
application,
so
gitlab
is
continuously
improving.
B
A
Okay,
great,
so
that
that
kind
of
gives
the
business
case
for
why
someone
might
you
know,
look
at
git
lab,
but
I
want
to
dive
like
a
layer
deeper
than
that
and
talk
about
each
of
these
stages,
and
evidently
I
forgot
I
had
this
because
I
you
know
this
is
where
we
would
do
that
overview.
So,
let's
do
a
quick
recap
right,
planning
plan.
What
we
want
to
do
create
actually
writing
the
software
verify
make
sure
it
works
package.
A
Put
it
in
a
you
know,
a
bow
on
it
and
tie
it
up
secure,
make
sure
that
the
code
we're
going
to
be
shipping
out
as
written
securely
release.
You
know
mark
it
at
a
point
in
time
as
this
is
the
release
configure
make
sure
the
environment
is
the
way
we
want.
It
monitor,
make
sure
it's
actually
working
the
way
we
expected
in
production
and
protect,
protect
the
environment
that
it's
running
in
so
again
we're
going
to
go
into
each.
A
So,
let's
talk
first
about
planning,
so
the
planning
stage,
as
I
mentioned,
is
like
hey.
What
are
we
going
to
work
on
and
when
are
we
going
to
work
on
in
what
order
right
so
organizing
with
a
team?
What
you're
going
to
work
on
how
it's
going
to
work?
What
are
the
requirements?
What
are
the
designs
going
to
look
like
and
then
portfolio
manager
means
like
okay,
if
that's
a
one
project?
What
about
the
you
know
totality
of
all
the
projects
we're
organizing?
How
do
those
things
fit
together?
A
But
then,
once
we've
got
our
issue
right,
our
thing
we're
going
to
work
on
one
of
the
issues,
maybe
here
from
this
issue
board
that
we're
looking
at
then
it's
time
to
start
writing
the
code
right
and
we
might
do
that
on
our
own
computer.
We
might
do
that
on
the
web.
Ide
in
gitlab
you'll
get
to
learn
about
that.
A
In
a
later
course,
but
then,
once
we've
written
our
code
too,
we
got
to
submit
it
for
code
review
so
that
the
folks
that
you
know,
maybe
the
engineering
manager
or
our
peers
are
going
to
review
that
code
and
make
sure
it
kind
of
conforms
to
our
standards
and
does
what
we
want
it
to
do
and
doesn't
have
any
obvious
glaring
issues
with
it
and
then
gitlab's
going
to
track
all
of
those
changes.
Here
we
see
this
massive
graph
of
changes
coming
and
going
from
the
mainline
branch.
A
Now,
once
they're
merged
together
we're
going
to
want
to
run
integration
tests,
and
so
continuous
integration
or
ci
you'll
often
hear
referred
to
as
ci
means
hey
we
want
to
now.
We
have
the
code,
we
want
to
run
the
tests
and
the
build
to
make
sure
the
code
runs
right.
We
might
also
want
to
test
for
coverage
of
that
code.
Like
do
we
have
enough
unit
tests
to
cover
all
of
the
code
that
we've
written,
we
might
want
to
write
or
do
some
usability
testing
to
say,
hey.
A
Does
this
meet
our
usability
standards,
performance
testing
to
say
you
know
under
load?
Does
this
still
perform
really
well
and
then
accessibility
testing
to
make
sure
that
it's
accessible
and
we
haven't
caught
introduced
a
problem
that
might
be
might
cause
a
problem
for
someone
who
uses
a
computer
differently
than
you,
and
I
do
and
lots
of
other
kinds
of
testing
that
can
happen.
But
all
that
happens
in
the
verify
stage,
and
here
we
can
see
a
pipeline
of
the
build
to
the
test
to
the
deploy
right.
That's
that's
something.
A
You'll
hear
a
lot
talked
about
in
continuous
integration
or
ci
and,
like
I
said
once,
you've
got
it
the
pipeline
run.
You
want
to
package
it
up.
Maybe
right.
You
want
to
put
it
onto
a
package
registry,
so
folks
can
download
it
to
their
computer
or
maybe
you're,
going
to
put
it
into
a
docker
container
that
you
could
then
deploy
into
your
environment,
and
you
may
also
want
to
proxy
dependencies
that
you're
using
in
your
software
so
lenders
our
registry,
allow
you
to
put
your
packages
into
the
registry.
A
It
also
can
allow
you
to
as
kind
of
a
proxy
between
all
of
the
world
of
open
source
pri
packages
and
then
the
the
ones
that
you're
specifically
using
in
your
environment,
so
that
you
can
understand
what
those
are
and
be
really
careful
about
bringing
in
packages
from
outside.
A
And
one
of
the
reasons
that's
important
is
for
security
right.
So
you
want
to
make
sure
that
you're
writing
secure
code
and
things
that
help
you
do
that
are
things
like
static
application,
security
testing
or
sas
or
dynamic
application,
security
or
dast.
Those
things
look
at
the
code,
either
statically
or
while
it's
running
static
and
dynamic,
to
try
and
find
issues
that
might
exist.
Based
on
how
the
code's
written.
We
also
want
to
make
sure
you
don't
commit
any
secrets
to
get
right.
A
We
don't
also
want
to
make
sure
you're
writing
quality
code
right
that
can
impact
security
as
well
and
then
any
dependencies
that
you
are
bringing
in
from
open
source
projects.
So
you
know
in
java,
think
of
maven
packages
or
in
node,
think
of
the
node,
the
package.json
and
the
known
modules
folder,
or
you
know,
lots
of
other
package.
You
know
name
your
your
programming.
Language
is
probably
a
package
manager
involved
in
bringing
in
open
source
dependencies.
We
want
to
make
sure
none
of
those
have
known
security
issues
with
them.
There's.
A
Here
that
go
into
security,
which
is
just
suffice
it
to
say
that
security
is
a
very
wide
discipline
and
involves
a
lot
of
things,
but
once
you
are
fairly
confident,
that's
secure,
you're,
gonna
wanna
then
release
and
deploy
that
code.
So
you
might
do
that
through.
What's
called
continuous
delivery
or
cd
right
so
a
lot
of
times
you
hear
ci
cd,
and
that
means
continuous
integration.
Continuous
delivery.
A
You
might
want
to
have
flags
that
turn
features
on
and
off
to
test
things
in
your
production
system.
As
you,
after
you've
deployed
it,
you
might
want
to
orchestrate
the
releases
into
different
places
right.
A
You
might
have
a
staging
environment
where
you
put
the
release
first
and
then
a
production
environment
when
you're
happy
that
it's
generally
working,
and
so
all
that
kind
of
environment
management
happens
in
the
release
stage
and
then
the
configure
stage
is
related
to
that,
but
basically
kind
of
manages
those
environments
right
like
let's
say
we
have
infrastructure
as
code
that
might
we
might
have
our
infrastructure.
That
is
the
places
where
we're
going
to
deploy
like.
I
want
these
many
servers
or
this
kind
of
container
images.
A
That
might
be
stored
in
code,
and
so
we
might
orchestrate
that
through
configure
or
we
might
use
something
called
autodevops
to
automatically
deploy
our
code
into
kubernetes
and
kubernetes
is
just
a
way
of
deploying
and
managing
container
images
that
are
running,
and
so
that's
what
our
configuration
configure
stage
helps
run
and
then,
once
it's
in
that
system
in
that
production
or
the
staging
system,
we
want
to
understand.
You
know
how
is
it
running?
Are
there
errors
that
are
being
noted?
A
Are
there
incidents
that
we
need
to
take
care
of
because
something
went
wrong,
and
so
that
is
the
monitor
stage
where
we
can
monitor,
what's
happening
in
real
time
and
understand
how
those
changes
may
have
impacted
either
positively
or
negatively
the
performance
or
the
availability
of
our
of
our
system
overall
and
then.
Finally,
as
we
mentioned,
it's
not
just
enough
to
kind
of
write
the
secure
code,
you
also
have
to
secure
the
environment
that
that
code
is
then
deployed
into.
A
So
that's
the
protect
stage
which
includes
container
scanning
security,
orchestration
host
security
and
network
security
for
containers
and
then,
finally,
again
we
saw
this
at
the
beginning
of
the
stages.
I
put
it
at
the
end
here
because
all
of
those
things
kind
of
are
impacted
by
the
manage
stage
which
is
hey.
What
is
the
organization
and
structure
of
how
we
deploy
this
code,
and
you
know
how
to
what
are
the
groups
and
the
users
involved?
A
How
do
we
ensure
compliance
right?
So
a
lot
of
times
you'll
hear
about
highly
regulated
environments
like
finance
or
health
care,
where
there's
a
lot
of
compliance
requirements
placed
on
organizations
when
it
comes
to
deploying
software
and
then
how
do
we
report
on
all
this?
Like
great
we've
got
all
these
stages.
We
know
the
code
moves
through
those
stages.
A
So
that's
a
real
brief
overview
of
devops
and
gitlab
in
general.
We're
gonna
have
courses
that
go
forward
and
talk
about
each
of
these
stages
in
more
detail.
But
thank
you
very
much
for
your
time.
I
look
forward
to
meeting
with
you
bye.