►
From YouTube: GitOps: Infrastructure Automation
Description
Poor audio - keep unlisted. Updated version with better audio here: https://www.youtube.com/watch?v=JtZfnrwOOAw
A
Hello,
my
name
is
william.
I
am
part
of
the
product
marketing
team
at
gitlab
and
in
this
video
I
would
like
to
speak
with
you
about
git
ops.
This
is
how
to
do
infrastructure
automation
using
get
ops
if
you
are
interested
in
learning
more
about
get
ops
and
how
can
benefit
your
organization,
how
you
can
adopt
it.
This
is
the
right
video
for
you
by
way
of
brief
introduction,
we'll
just
talk
about
the
landscape
of
software
development
and,
as
always,
the
landscape
of
software
development
is
ever
in
a
state
of
change.
A
So
if
we
take
a
a
brief
look
at
where
it's
been
and
where
it's
at
now,
we
can
see
that
once
upon
a
time,
waterfall
was
a
standard
practice
for
developing
software
and
for
many
organizations
today,
they're
still
using
waterfall
software
development
practices,
delivering
software,
essentially
like
its
hardware,
sequentially
with
long
cycles,
and
it
can
take
a
long
time
before
you
get
feedback.
You
can
end
up
developing
a
product
that
your
users
don't
even
want
because
it
takes
you
so
long
before
you
get
that
feedback.
A
So,
in
order
to
remedy
these
challenges,
we
started
implementing
agile
software
development
where
we
started
making
smaller
and
smaller
changes
with
faster
iteration
cycles.
This
was
a
great
step
forward,
but
of
course,
it
led
to
another
challenge,
which
was
development
teams
were
moving
very
quickly,
with
small
changes
and
operations,
teams
that
were
still
doing
manual,
infrastructure,
racking
and
stacking
and
provisioning
were
not
able
to
keep
up.
A
So
we
ended
up
also
adopting
devops,
together
with
agile
software
development,
so
that
with
our
automation,
our
development
teams
and
operations
teams,
collaborate
together
and
in
the
early
days
of
infrastructure
as
code
and
devops.
This
was
a
great
step
forward
where
we
started
an
entire
world
of
automation.
We
had
much
more
stability,
much
more
speed
and
acceleration
better
outcomes
for
our
teams
and
a
lot
more
sanity.
A
But,
of
course,
now
we're
shifting
into
a
world
of
containerization
micro
services
kubernetes
and
in
this
new
cloud
native
world,
the
level
of
complexity
exponentially
increases.
We
now
have
dynamic
environments
that
are
always
shifting
and
changing.
They
need
to
scale
up
to
cloud
world
level
scale
under
load
and
scale
down
with
feature
flagging.
A
You
have
a
great
level
of
complexity
with
environments
needing
to
keep
up
and
operations
teams
need
to
keep
up
with
all
of
this
cloud
native
complexity.
So
this
brings
us
to
the
need
for
git
ops,
so
in
this
video
today
I'll
share
with
you.
What
git
ops
is
why
git
ops
is
important,
we'll
look
at
some
of
the
challenges
with
managing
infrastructure
in
a
modern
environment
and
some
of
the
benefits
that
git
ops
can
bring.
A
You
and
I'll
share
with
you
how
to
do
git,
ops
in
your
environment,
so
we'll
look
at
how
best
practices
for
how
git
ops
teams
are
structured
and
we'll
look
at
maybe
even
some
of
the
the
blockers
to
adoption,
along
with
some
of
the
technologies
that
you'll
need
to
adopt
in
order
to
do
git.
Ops
in
your
in
your
context,
so
to
kick
things
off.
Let's
look
at
what
is
git
ops,
just
like
many
technology
terms,
just
like
devops
or
cloud
native,
or
any
of
these
terms
that
we
use
within
the
technology
space.
A
So
what
I'd
like
to
share
with
you
is:
is
our
perspective
at
gitlab
on
how
we're
thinking
about
doing
operations
via
git
or
git,
ops,
and
so
the
way
we're
thinking
about
this
is
get
ops,
is
an
operational
framework
and
what
it
does
is
it
takes
the
devops
best
practices
that
you
use
for
application
development.
These
are
things
like
version
control,
collaboration,
compliance
and
ci,
cd
automation
and
we're
applying
those
to
infrastructure
automation.
A
So
I
like
to
think
of
git
ops
as
devops
for
infrastructure
as
a
shortcut,
but
we'll
dig
into
it
more.
A
formula
for
thinking
about
devops
thinking
about
git
ops
is
that
it
encompasses
these
three
components.
Get
ops
is
going
to
equal
infrastructure
as
code
storing
your
infrastructure
in
declarative,
declarative
code
stored
in
a
git
repository.
A
We
are
going
to
be
using
merge
requests
as
our
agent
of
change
and
we're
going
to
be
using
ci
cd
automation
in
order
to
do
a
reconciliation
loop
so
that
our
our
infrastructure
is
is
always
up
to
date
with
the
correct
state.
So
these
are
the
three
components
and
we'll
break
them
down
one
at
a
time.
Infrastructure
is
code,
merge
request,
is
a
change
agent
and
our
automation,
reconciliation
loop.
A
So
to
look
at
infrastructure
as
code
for
most
of
this
talk
most
of
this
video
I'll
just
be
using
the
term
iac
or
infrastructure
as
code,
but
really
this
goes
far
beyond
infrastructure.
Sometimes
we
use
the
term
x's
code,
because
this
could
be
infrastructure.
This
could
be
configuration.
This
could
be
policy.
A
But
ideally
what
we
want
to
use
are
our
tools
and
technologies
that
allow
us
to
have
a
declarative
set
of
code
states,
so
we're
declaring
the
desired
state
that
we
want
for
our
infrastructure
and
our
automation
tools
are
going
to
move
it
towards
that
state
with
us.
Have
it
without
us
having
to
to
procedurally
generate
what
it
the
exact
steps
need
to
happen,
we're
declaring
a
desired
state
and
our
our
infrastructure
is
going
to
converge
on
that
desired
state.
A
Of
course
we
want
to
store
this
and
get
version
control,
so
there's
a
lot
of
power
in
using
version
control
in
the
same
way
that
storing
application
code
and
version
control
is
a
big
step
forward.
So
to
storing
our
in
our
infrastructure
code
and
operations
code
inside
of
git
gives
us
all
these
power
and
advantages
of
doing
version,
control
and,
of
course,
what
we,
what
we
get
for
free
when
we
do.
This
is
our
all
of
our
git
tooling,
as
the
the
user
interface,
so
all
of
our
command
line,
tooling.
A
A
A
Next,
we
are
going
to
be
using
merge
requests
as
our
agent
of
change
and
so
within
git
lab.
We
call
the
concept
of
requesting
to
merge
one
branch
into
another,
a
merge
request
in
other
tools.
It's
called
a
pull
request,
but
whether
you
use
mr
or
pr
the
power
of
git
ops
is
that
you
are
structuring
your
branching
strategy
in
such
a
way
that
your
main
branch
becomes
your
production
branch.
Some
folks
call
this
default
or
trunk
or
historically
known
as
the
master
branch,
but
the
idea
is
you
have
one
branches?
A
Is
your
your
main
production
branch
or
your
main
environment
branch,
for
example?
Could
be
the
branch
for
staging
and
whatever
is
in?
That
branches
is
what
is
going
to
be
represented
in
that
environment?
So
that
way
you
can
propose
a
set
of
changes
and
when
those
changes
get
merged
into
that
branch,
that
is
the
source
of
truth
and
so
that
merge
request
or
pull
request
becomes
a
gate.
A
This
gives
you
all
kinds
of
powerful
benefits
when
you
adopt
this
type
of
get
ops,
for
example,
you
get
all
types
of
code
review
that
way
before
the
before
that
change
goes
live.
You
can
have
a
set
of
peer
collaboration
and
peer
review
on
that
code.
You
have
a
commenting
mechanism
and
very
powerfully.
A
You
have
a
mechanism
by
which
to
do
approvals
in
the
mr,
before
new
changes
go
live
and
you
can
gate
who
actually
can
enact
those
changes
so
by
using
the
mr
as
the
gate,
many
many
people
or
anybody
can
propose
a
change,
but
you
for
compliance
purposes.
You
can
lock
down
the
set
of
people
who
can
actually
enact
that
change
to
a
few
set
of
people,
and
those
are
the
people
who
have
permission
to
merge
to
that
main
branch.
This
is
a
powerful
mechanism
of
git.
A
A
You
could
use
an
agent
that
lives
within
your
infrastructure
or,
let's
say
within
your
kubernetes
cluster,
something
like
a
kubernetes
operator
and
that
could
do
a
pull
back,
pull
based
reconciliation
where
it's
reaching
out
to
your
git
repository
and
pulling
that
configuration
into
your
cluster,
or
this
could
be
an
agentless
push
based
reconciler.
You
can
have
in
addition
to
your
ci
cd
loop,
your
csd
running
anytime.
A
You
merge
new
code
into
the
main
branch
you
can
also
just
have
a
timer
or
a
cron
job
or
or
a
ci
cd,
job
or
pipeline
that
just
runs
on
a
regular
schedule
and
that
that
loop,
that's
just
running,
is
just
checking
your
environment.
Seeing
has
anything
changed
in
the
environment.
Has
anything
changed
with
the
code?
Let
me
let
me
go
ahead
and
reconcile
the
environment
to
the
defined
state.
A
We're
gonna
we're
gonna
set
when
anything
is
out
of
sync
we're
gonna,
sync,
the
the
infrastructure
to
match
the
defined
state
and,
of
course,
within
this
model,
changes
are
implemented
completely
in
an
automated
fashion,
so
we're
no
longer
doing
any
type
of
manual
updates
to
our
infrastructure.
We
completely
automated
the
process.
A
A
From
that
we
create
a
new
merge
request.
This
creates
a
new
what
we
would
call
a
feature
branch
in
application
development.
You
may
or
may
not
think
of
that
as
adding
a
new
feature
to
your
environment
or
fixing
a
bug
in
your
environment.
But
this
branch
is
where
you
can
collaborate
and
you
would
commit
your
changes
to
that
branch.
A
The
same
way
that
you
would
commit
changes
to
application
code,
but
in
this
case
it
is
the
definition
of
our
infrastructure.
It's
our
infrastructure's
code.
Our
ci
pipeline
is
going
to
run
on
that
code.
It's
going
to
do
any
type
of
automated
testing
linting
any
type
of
checks
there
and
then
you
may
choose
to
have
do
something
called
a
review
and
a
review
environment,
a
review,
app
or
view
environment
is
a
production
like
environment.
Think
of
this
as
a
staging
environment
for
every
single
branch.
A
This
is
something
you
can
do
within
git
lab
and
potentially
you
can
configure
in
other
tools,
but
with
git
lab
as
a
feature
when
you
want
to
see
what
will
this
environment
look
like,
I
want
to
test
an
actual
running
environment.
Before
I
go
ahead
and
change
my
production
environment,
then
I
can
use
a
review
app
to
essentially
get
a
staging
environment
for
every
single
branch.
I
create
this
way
on
this
merge
request
on
this
new
branch.
A
A
This
automatically
closes
the
issue
and
our
continuous
delivery
pipeline
is
going
to
run
to
then
enact
those
changes
and
to
update
our
infrastructure
with
whatever
that
new
code
change
or
that
changes.
And
then,
of
course,
we
want
to
monitor
that
application
to
see
it
running
in
production.
This
is
what
we
would
call
the
the
get
get
ops
flow.
Git
flow,
git
lab
flow
looks
like
this,
so
some
of
you
may
be
hearing
in
the
video
so
far
and
you're
thinking
yourselves,
gee
get
ups.
A
It
kind
of
just
sounds
the
same
as
infrastructure's
code
we've
been
talking
about
infrastructure
as
code
for
a
long
time.
What's
really
all
that
different
well
in
some
ways.
Yes,
these
principles
and
these
technologies
have
been
around
for
a
while
and
they're
just
now,
starting
to
come
to
fruition,
broadly
they're
just
now,
starting
to
become
experimented
with
new
technologies
and
to
be
codified
into
a
set
of
best
practices.
A
So,
looking
at
some
of
the
difference
between
doing
git,
ops
and
infrastructure,
as
code
is
with
infrastructure
as
code,
your
your
code
may
or
may
not
be
version
controlled,
there's
no
requirement
for
infrastructures
code
code
to
be
version
controlled.
It
could
be
a
text
file
on
your
laptop,
and
you
know.
Maybe
you
just
fdp
that
to
your
provisioning
server
to
your
configuration
server.
A
There's
there's
not
necessarily
a
mandate
that
it's
stored
within
a
version
control,
but
with
git
ops,
that's
a
core
element
of
the
of
the
process.
The
same
thing
is
where
your
changes
in
git
ops
are
enacted
via
merge,
requests
and
merge,
requests
that
gate
with
infrastructure.
As
code
code
changes
may
or
may
not
go
through
a
repo
approval
process,
they
can
but
that's
not
necessarily
mandated
and
then,
of
course,
with
git
ops.
Those
infrastructure
changes
are
automated,
whereas,
as
I
mentioned
in
infrastructure's
code,
maybe
you
have
some
type
of
automation
running.
A
That
certainly
is
a
best
practice,
but
it's
not
necessarily
dictated
so
when
you
say
I'm
doing
infrastructures
code,
it
doesn't
necessarily
mean
you're
doing
all
these
best
practices,
but
when
you
say
you're
doing
git
ops,
it
does
mean
these
are
these
best
practices
that
we've
we've
developed.
So
one
way
to
think
about
it
is
that
git
ops
is
infrastructure.
Is
code
done
right
so
with
that
now
that
we
kind
of
have
a
base
understanding
of
what
git
ops
is
and
and
how
it
works?
Let's
take
a
look
at
why.
Why
is
get
ops
important?
A
A
So
one
of
those
benefits
versus
doing
everything
in
a
gui
based
configuration
for
your
infrastructure
or
any
kind
of
tooling
that's
not
defined
as
code
is
all
of
a
sudden.
Now
you
get
some
self
documentation
for
free.
So
when,
when
you
want
to
understand,
what's
going
on
in
your
environment,
a
big
challenge
there
is
is:
if
the
person
who
went
and
configured
it
in
a
gui
didn't
go
and
write
down
what
they
did
it's.
It
can
sometimes
be
very,
very
hard
to
go
and
understand
what
what
is
going
on.
How
do
I
change
this?
A
A
But
when
everything
lives
as
code
now,
it's
very
accessible.
You
can
see
exactly
what
is
going
on
and
you
get
some
self-documentation
for
free.
This
doesn't
preclude
the
need
to
do
some
additional
documentation,
but
this
can
live,
for
example,
in
a
in
a
wiki
or
a
readme
right
right,
alongside
your
your
code
repository,
so
that
can
also
be
collaborated
on
and
shared
broadly
as
one
of
those
ways.
A
A
A
Let's
say
you
have
an
application
or
you
have
a
service
running
and
that
that
service
has
a
really
large
memory
leak.
It's
just
consuming
massive
amounts
of
memory,
and
so
this
sprint,
your
engineers,
have
gone
in
and
they've
really
worked
hard
to
to
close
the
memory
leak
and
to
just
make
the
app
run
more
efficiently.
So
it
needs
a
lot
less
memory.
A
A
Well,
what
happens
if
there's
actually
a
bug
in
that
latest
set
of
code
that
you've
discovered
a
user
facing
bug
that
changes
the
the
behavior
for
the
user?
Well,
now
you
want
to
roll
back,
but
the
problem
is,
if
you
just
roll
back
to
the
old
code
or
the
previous
version
of
the
code,
that
has
a
very
heavy
memory
requirement,
all
of
a
sudden
you're
going
to
crush
your
infrastructure,
which
has
been
adapted
to
the
latest
memory
requirements.
A
So
by
having
this
type
of
version
control.
This
is
just
one
scenario
where
your
application
version
can
be
tied
to
your
infrastructure
configuration
version
and
those
can
move
along
in
lop
step.
If,
if
you're
rolling
forward
or
rolling
backward
with
any
changes,
you
can
keep
those
in
sync
so
that
you
can
eliminate
a
whole
category
of
problems
that
arise
when
they're
out
of
sync.
A
This
is
a
wonderful,
powerful
benefit
of
anybody
who
has
ever
started
using
infrastructure's
code
stored
in
version
control
and,
of
course
this
lowers
your
mean
time
to
recovery.
So
when
your
platform
is
down
when
you're,
you
know,
you've,
you've
rolled
out
some
type
of
change
or
something
has
happened,
and
you
are
now
not
servicing
customers
and
users
to
be
able
to
roll
back
to
that
last.
Knowing
good
configuration
to
then
be
able
to
troubleshoot
in
other
ways.
A
A
A
So
again,
if,
if
there's
some
type
of
manual
configuration
or
manual
provisioning,
I
think
many
of
us
have
been
in
an
environment
where
you
have
some
new
application
code
and
before
that
application
code
can
go
live.
You
need
to
go
and
request
your
resources
and
those
resources
need
to
go
through
some
type
of
process
before
you
can
even
get
that
server
provision
or
that
vm
provision
for
you,
this
can
be
very,
very
painful.
It
makes
it
hard
to
do
experimentation.
A
A
A
The
the
notion
here
is
maybe
there's
some
type
of
failure
within
your
environment
and
another
piece
of
it
needs
to
be
brought
back
up
again
there,
maybe
there's
a
misconfiguration
or
maybe,
even
though
it's
not
allowed.
Maybe
somebody
has
gone
in
and
done
some
type
of
manual
tweaking
for
some
reason,
but
that's
bad
because
it's
not
documented,
you
don't
know.
What's
going
on,
you
can't
share
the
knowledge
and
all
of
these
problems.
A
A
Now
you
have
one
service
account
or
one
one
mechanism
that
you
need
to
grant
permissions
for
and
now
you
can
manage
all
of
your
permissions
within
your
git,
tooling,
and
so
git
tooling.
Automat
already
has
a
robust
permission
set,
and
so
you
can
assign
who
has
permissions
to
make
proposals
for
which
code
branches?
Who
has
the
ability
to
merge
to
which
branch
many
people
can
contribute.
But
but
few
people
can
be
given
access
to
actually
make
the
change.
So
for
compliance
purposes.
A
A
This
can
be
very,
very
frustrating,
but
when
every
change
to
your
environment
is
made
via
git
commit
and
get
merge
request
now
you
have
a
very,
very
nice
historical
log
of
what
changed
at
what
time
and
who
made
that
change,
and
this
this
is
very,
very
powerful.
It
makes
auditing
very,
very
simple,
relatively
simple
to
having
to
to
deal
with
the
broader
mess
and,
of
course,
this.
This
change
process,
compliance
which,
which
I
I
talk.
I've
talked
about
a
lot
with
this
idea
of
having
the
merge
request
as
the
gate.
A
You
know,
rather
than
having
to
have
a
change
meeting
and
a
manual
change
process
when
you
grant,
you
know
a
set
of
approvers.
These
are
the
folks
who
are
able
to
approve
and
who
need
to
approve
and
the
set
of
groups
that
are
able
to
approve
a
merge
request,
and
these
are
the
people
that
are
are
able
to
merge
to
these
branches.
A
Now
your
change
process
is
is
compliant
per
your
policy.
It's
set
for
your
policy
via
the
technology
and
not
not
needing
a
manual
process.
So
there
are
many
many
benefits,
there's
more
than
I
could
ever
even
cover
in
this
video
and
as
the
space
evolved
and
as
the
technology
is
evolving
and
as
best
practices
are
evolving,
we're
seeing
even
more
challenges
and
more
benefits
emerge.
A
A
This
is
assuming
a
few
things,
perhaps
that
you
are
in
a
larger
enterprise
or
mid-market
company.
That
has
many
many
development
teams
and
you
have
a
lot
of
complexity
to
manage.
So,
if
you
are,
let's
say
a
new
software
startup
and
there's
three
of
you
and
all
three
of
you
are
engineers
and
you
all
have
access
to
the
code
and
you
all
have
access
to
the
environment.
You
can
do
all
of
that.
A
Get
ops,
automation
and
maybe
that's
your
team-
is
three
people,
but
if
you're
in
a
large
enterprise
and
with
many
many
microservices
this
is
this
is
the
best
practice
we're
seeing
emerge
and
that's
actually
been.
That's
been
emerging,
that's
been
around
for
a
while.
This
is
this
is
the
best
practice
that
we're
seeing
larger
companies
enact,
and
this
is
the
the
rise
of
the
operations
platform
team.
A
But
rather
these
modern
development
teams
they
own
their
service,
they
they
own
the
pager.
So
when
that
service
goes
down
they're
the
ones
that
are
responsible
and
they
understand
they
can
look
at
the
monitoring,
they
can
look
at
the
operation
of
that
service
they're,
not
only
developing,
they
develop
the
service.
They
operate
it
too,
and
this
is
a
this
is
a
modern
best
practice
for
microservices
teams
but,
of
course,
embedded
within
that
service.
You
have
one
or
several
infrastructure
and
operations
experts,
some
site,
reliability,
engineers.
A
We
call
them
the
embedded,
sre
site,
reliability,
engineer
and
they
might
be
again
they're
not
completely
focused
they're,
not
the
one
person
who
owns
the
pager
they're,
not
the
one
person
who
understands
where
the
app
is
deployed,
how
it's
deployed
or
what
the?
What
the
monitoring
of
that
application
that
you
know
application
code
is
but
they're
more
heavily
focused
on
that
and
they
might
be
20
focused
on
future
development.
A
So
they
understand
what's
going
on
in
the
application,
and
so
this
delineation
of
roles
within
a
cross-functional
team
is
the
best
practice
we've
seen,
and
what
we've
noticed
is
that,
especially
with
modern
platforms
like
kubernetes,
the
way
we
think
about
git
lab
kubernetes
isn't
necessarily
a
requirement
the
way
we
think
about
git
ops
at
gitlab.
You
can
do
get
ops
even
without
kubernetes.
You
can.
You
know
you
can
store
your
infrastructure's
code.
A
A
They
don't
need
to
understand
all
the
bits
and
bytes
of
kubernetes
all
the
ins
and
outs
and
the
details
of
kubernetes,
and
they
certainly
shouldn't
be
carrying
how
many
vms
I
need
to
spin
up
in
ec2
and
what
size
instance
that
that
shouldn't
be
a
concern
for
them.
They
should
be
concerned
with
developing
their
application.
Their
deployment
pipeline
and
that
deployment
pipeline
should
be
should
be
mostly
automated
and
owned
by
a
platform
team
and
what's
really
powerful.
Here,
is
when
this
operations
team
can
start
to
templatize
this.
A
They
can
spread
best
practices
across
the
entire
org.
When
spinning
up
a
new
service,
they
can
give
you
a
service
template
so
that
you
can
have
a
code
repository
and
a
pipeline.
That's
all
set
to
deploy
into
your
kubernetes
cluster,
and
so
it
makes
it
very,
very
easy
to
spin
up
new
services
and
and
proliferate
out
your
changes,
so
the
operations
platform
team
they
tend
to
own
the
kubernetes
cluster
and
sometimes
they
also
own
infrastructure.
A
Although
in
some
organizations
you
may
then
also
have
a
separate
infrastructure
team,
because
no
matter
how
many
layers
of
abstraction
it
always
has
to
run
on
a
server
somewhere,
and
so
these
days
it
could
be
an
on-premises
server.
You
may
own
the
bare
metal-
and
maybe
your
infrastructure
team
is
literally
still
racking
and
stacking,
but
in
this
model
your
developers
are
never
waiting
on
that
rack
and
stack
right.
A
You
know
they
may
be
doing
it
on
premises
more
common
than
not
they're
going
to
be
doing
this
in
one
or
many
cloud
services
doing
multi-cloud
and
hybrid,
with
on-prem
and
cloud
services,
and
so
the
the
platform
team
may
be
running
the
infrastructure
or
you
may
have
a
separate
infrastructure
team,
that's
providing
and
managing
those
nodes
to
the
cluster
and
then
that
operations
platform
team
is
as
responsible
for
for
serving
that
platform
as
a
service
to
the
development
teams.
Templatizing
things
there's
a
lot
of
different
ways
to
structure
your
git.
A
A
A
A
So
this
is
not
an
exhaustive
set,
but
to
enact
this,
these
core
set
of
capabilities,
these
these
three
components
of
gitlab
infrastructures,
code,
merge,
requests
and
ci
cd.
This
is
the
type
of
tooling
that
you're
going
to
want
to
implement.
So,
of
course,
first
and
foremost,
you
need
a
git
repository
and
then
additionally
you're
going
to
need
a
git
management
tool.
So
this
is
one
sense
in
which
we're
a
bit
opinionated
on
how
to
do
git.
Ops,
we've
definitely
heard
some
folks
may
talk
about
well.
A
A
Then,
in
addition
to
those,
you
usually
want
some
type
of
configuration
manager.
So
these
are
things
like
ansible
chef
and
puppet
with
git
lab
a
lot.
We
see
a
lot
of
adoption
of
ansible
these
days
and
even
in
a
world
where
you
are
all
all
cloud
native
or
almost
all
cloud
native,
although
I
haven't
seen
that
in
every
organization
they.
How
did
I
hear?
I
heard
one
cio
describe
it
as
they
have
a
smithsonian
of
technology,
so
they
have
a
museum.
A
They
never
ever
update
everything,
there's
always
some
kind
of
a
mix.
So
because
there's
always
some
kind
of
a
mix.
You
are
still
going
to
want
some
type
of
configuration
management
that
determines
the
configuration
for
servers
or
even
if
you
have
some
type
of
cluster,
unless
you
are
using
a
managed
kubernetes
service
that
manages
your
kubernetes
nodes
for
you,
you're
going
to
want
to
be
somebody
managing
that
infrastructure
and
need
some
kind
of
configuration
manager.
A
This
is
where
a
lot
of
this
automation
comes
in,
and
this
is
not
just
talking
about
the
servers,
whereas,
if
you're
containerizing
your
workloads,
then
a
lot
of
your
configuration
is
stored
in
your
docker
file.
You
don't
necessarily
need
a
configuration
manager,
but
you
do
need
some
type
of
provisioning,
because
that
provisioning
tool
is
not
just
it's
providing
your
entire
infrastructure.
A
So
not
just
let's
say
your
servers,
but
maybe
your
network
configuration
your
firewalls
as
well
any
type
of
software-defined
networking
your
provisioning
tool
can
go
out
and
provisioning
the
the
many
different
components
of
your
infrastructure,
so
it
becomes
very,
very
powerful
when
you're
doing
git,
ops
and
then,
of
course,
container
orchestration
of
which
kubernetes
rules
the
roost.
We've
talked
a
lot
about
kubernetes
here.
A
So
with
that,
let's
just
take
one
last,
a
final
look
before
we
wrap
things
up
at
what
are
some
of
the
challenges
that
you
may
encounter
as
you've.
You've
looked
at
this,
maybe
you're
already
doing
some
get
ups
and
you
want
to
take
it
to
the
next
level.
Maybe
you
have
gotten
excited
and
you
want
to
start
enacting
git
ops.
A
What
are
some
of
the
challenges
you
might
face?
Well,
the
the
biggest
of
all
challenges,
of
course,
with
any
technology
change
is
always
changing
the
culture.
We
know
that
that
new
technologies
can
always
make
things
easier,
but
for
whatever
reason,
people
don't
change
as
fast
as
technology,
and
so
what's
what's
really
important.
To
keep
in
mind
is
with
any
new
fun.
A
Exciting
practices
like
get
ops
is
to
have
empathy
and
remain
human
about
what
you're
doing
and
realize
that
you're
working
as
a
team
with
other
people,
and
you
need
to
bring
those
people
along.
You
need
to
adapt
your
culture,
and
so,
especially
in
many
large
organizations,
operation,
engineers,
sysadmins
folks,
that
are
running
your
infrastructure
today
they
may
not
be
used
to
a
developer-centric
workflow
and
so
in
order
to
use
git
ops.
This
is
a
very
developer-centric
view
of
the
world,
so
operations,
engineers
that
are
also
software
developers.
A
They
love
this
model
of
get
ops,
but
for
some
folks
this
this
may
be
an
adapting
of
skills.
This
may
require
some
changing
a
change
in
mindset,
they're
doing
things
in
a
different
way,
and
so
that
cultural
change
is
something
to
keep
in
mind.
As
you
move
forward
and
may
differ
per
your
environment,
you
may
need
to
look
at
training
programs.
You
may
need
to
look
at,
for
example,
doing
get
ops
in
a
small
part
of
your
org
and
proving
its
success.
A
A
Another
challenge
you
may
face
is
you
may
not
be
at
the
level
of
deployment
automation,
that's
required
to
do
git,
ops
and
that's
okay.
This
is
in
many
ways
very,
very
bleeding
edge.
This
is
some
technology.
That's
that's
been
around
for
a
long
time,
depending
on
your
view
of
technology.
A
long
time
is
very,
very
relevant
relative,
but
the
idea
here
is
that
for
many
organizations
this
is
very,
very
new
on
the
cutting
edge
technology
and
you
may,
before
you
go
and
adopt
get
ops
for
your
infrastructure
automation.
A
You
may
just
need
to
first
look
at
your
ci
cd
pipelines
and
your
your
base
deployment
operation,
maybe
you're
doing
a
lot
of
automated
testing.
Maybe
you
do
like
a
ci,
but
you're
not
really
doing
cd
yet
and
that's
a
place
to
dig
in
is
to
get
your
cd
pipelines
set
up
to
explore
that
technology
to
understand
it,
and
then
you
can.
A
A
Finally,
even
though
we
love
git,
even
though
operations
via
git
is,
it
makes
a
lot
of
sense.
It's
a
very
powerful
mechanism.
It's
a
world
where
a
lot
of
us
that
have
a
software
development
background
are
just
comfortable
in
so
that
we
can
get
started
very
very
quickly
with
a
powerful
set
of
tooling.
A
A
Let's
say
you
know:
observability
tools
are
monitoring,
not
all
you
know
it
might
be
very,
very
powerful
if
I
could
do
some
of
my
monitoring
configuration
also
in
code,
but
there
are
a
lot
of
components
to
application
infrastructure,
cluster
monitoring,
observability
logging,
error
tracking.
All
of
these
components
don't
necessarily
belong
in
git.
A
That
can
that
can
be
pretty
cumbersome
to
manage
all
within
a
git
structure
and
having
a
separate
gui
based
tool
to
do.
That
is
maybe
another,
a
good
place
where
maybe
it
doesn't
belong
and
get
and,
of
course,
something
like
incident
management
when
things
do
go
down,
and
we
we
want
to
gather
investigate,
do
our
forensics
remediate
that
problem
and
discover
how
we
can
change
things
so
that
it
doesn't
happen
again.
A
That
type
of
incident
management
flow
is
needs
a
whole
set
of
tooling
and
a
whole
set
of
of
practices
that
are
probably
outside
of
just
having
a
git
repository,
although
certainly
having
a
lot
of
things
in
code
and
using
using
code
and
git
practices
within
your
incident.
Management
flow
can
be
very
powerful,
but
these
are
just
a
few
examples
that
come
to
mind
of
how
not
everything
belongs
in
git,
and
so,
even
though
I
personally
love
git
ops
and
I'm
very
excited
about
it.