►
From YouTube: GitOps The Future of Infrastructure Automation - Panel Discussion GitLab, HashiCorp and plat4mation
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
A
A
What
successful
githubs
looks
like
what
teams
need
to
get
started
on
their
data
journey
and
specifically
what
these
three
companies
hashicorp,
platformation
and
gitlab-
offer
the
market
for
a
successful
github's
transformation.
I
think
we're
up
for
a
very
interesting
panel
discussion
session
with
all
of
our
expert
speakers.
So
let
me
go
over
to
the
speakers
and
request
them
each
to
introduce
themselves
I'll
start
with
william
chia.
B
B
So
mostly
I
get
to
work
with
gitlab's
customers
that
are
using
githubs
or
cloud
native
technologies
like
kubernetes
talking
a
lot
about
what
what
features
are
beneficial
to
them
and
and
what
kind
of
challenges
they
have
to
solve
and
then
at
get
lab.
I
do
a
lot
of
work
on
on
our
go
to
market
motions
and
niko.
C
C
D
Himself,
yes,
hello,
yeah,
thanks
for
having
me,
my
name
is
chris
with
the
with
the
funny
g,
I'm
I
work
with
platformation
and
I
am
our
enterprise
devops
stream
lead,
and
so
what
we
do
mostly
is
we
we.
We
do
consultancy
and
building
applications
on
top
of
the
servicenow
platform,
and
I
particularly
specialize
in
all
the
enterprise
devops
or
the
devops
related
practices,
and,
of
course,
also
github's
falls
within
that
within
that
bucket.
B
So
I
am
really
excited
to
chat
about
the
topic
today
and,
as
we
kind
of
have
discussion
who's
to
nico,
and
I
we've
we've
had
some
pre-conversations
about
get
ops.
I
think
this
as
nico
says
something
we're
all
very
passionate
about
and
before
we
dive
into
it.
What
we
would
like
to
understand
is
where
you
are
at
as
an
audience
with
git
ops.
B
So
I
think
there
are
some
general
concepts:
it's
around
infrastructure,
automation,
storing
your
state
in
a
git
repository
and
and
automating
that,
using
you
know
all
kinds
of
different
tools
that
we'll
talk
about,
but
we
would
love
to
start
off
with
a
poll
question
and
china.
If
you
can
launch
the
poll
question
for
the
audience,
the
question
is
really
where,
where
are
you
at
with
git
ops
and
probably
tend
to
think
about
this
question
from
the
perspective
of
your
business
organization?
B
Of
course,
if
you're
attending
this
session
and
you're
thinking
of
yourself,
as
you
know,
thinking
about
git
ups
for
maybe
an
open
source
project,
you're
working
on
or
a
personal
project,
it's
okay
to
answer
from
that
perspective
as
well,
but
from
from
the
perspective
of
the
organization
that
you
are
in,
have
you
maybe
you
haven't
explored
it
yet
at
all?
Maybe
you've
started
to
look
into
get
offs,
but
you
haven't
really
committed
to
any
get
ops
practices.
B
Perhaps
you've
done
a
lot
of
github's
research
already
and
you
have
a
plan
to
implement
it
or
perhaps
you're
already
using
get
offs
today
and
so
go
ahead
and
click
into
the
pull
answers
there
and
we'll
give
it
just
about
a
moment-
and
you
know
we'll
I'll,
we'll
show
the
answers
to
you
as
well
to
see
who's
on
the
call.
So
it
looks
like
a
majority
of
the
folks
on
the
call.
Thank
you.
B
Everybody
who's
provided
their
response
there,
let's
go
ahead
and
close
the
poll
out
and
take
a
look
at
the
answers
this
way
as
nico
and
huss,
and
I
we're
taking
a
look
we'll
see
who
you
are
so
it
looks
like
majority
of
folks
on
the
call.
This
is
a
new
topic
have
not
yet
explored
it.
This
is
very
exciting
because
you've
come
to
the
right
place.
B
Minds,
the
the
basics
and
the
rundown
and
everything
you
need
to
know
to
get
started.
Even
some
places
look
further
and
it
looks
like
we
also
have
a
meaningful
chunk
about
a
fifth
of
the
audience
today
that
is
already
using
git
ops,
and
so
what
we
would
love
is
any
questions
across
the
spectrum
as
we're
having
a
conversation
today.
B
Any
questions
that
you
have
please
do
type
them
into
the
q
a
feature
and
at
the
end
of
the
session,
we'll
do
some
we'll
take
some
of
your
questions
and
answer
those
and
so
feel
free
to
ask
anything
at
all
from
the
the
very
basics
to
if
you
are
using
a
get
up,
some
limitation
we'll
do
our
best.
Maybe
we
won't
know
the
answer
in
particular,
but
we
would
love
even
in-depth
questions
from
folks
that
are
using
github
slot.
So
from
that,
I
would
love
to
just.
B
We
can
take
the
poll
off
the
screen
and
jump
into
the
conversation
and,
of
course
the
first
question
is
this
is
a
new
term
and
like
many
new
terms
in
industry,
different
people
can
define
it
a
bit
differently
so
for
for
those
of
us
on
the
call,
how
do
you
define
git
ops
in
your
organization?
How
do
you
talk
about
it.
C
I'll
just
go
ahead
and
take
a
start,
you
know
I
I've
been
working
with
organizations
that
are
looking
into
transitioning
into
githubs
for
a
while,
not
only
kind
of
my
current
role,
but
in
my
previous
role
I
worked
at
a
company
that
the
configuration
management
software-
it's
not
a
secret,
is
my
linkedin,
but
ultimately
you
know
we
started
with
that
concept
of.
How
do
we
take
a
new
approach
to
you
know
mostly
infrastructure
changes.
C
C
Our
sort
of
systems
of
coordination
for
changes
were
mostly
based
on
i2
procedures,
but
some
sort
of
loose
interpretation
of
that
item
procedures
where
effectively
when
I
was
working
at
this
very
large
organization.
That
has
three
letters
again
on
my
linkedin.
If
you're
curious,
you
know,
I
was
part
of
a
system
administration
group
and
we
had
to
interact
with
people
managing
you
know,
potentially
storage
or
databases
or
networking
and
so
on.
So
I
remember
weekly
going
into
these
hour
two
hour
long.
C
You
know
change
advisory
board
meetings
where
effectively
someone
went
and
just
said,
hey,
here's
a
change
I
want
to
do.
If
you
have
any
questions,
please
ask
me
if
not
go
ahead
and
improve
that
change,
and
it
was
always
very
hard
to
get
the
full
context
of
you
know
or
or
the
right
information
in
terms
of
understanding.
How
is
this
going
to
impact
me
and
my
role,
I
think
the
beauty
of
bitops
is
first,
it
allows
us
to
have
a
clear
versioning
of
you
know
all
the
iteration
of
changes
that
we
had
through
infrastructure.
C
The
second
aspect
is
the
collaboration
aspect.
I
immediately
see
what
the
change,
not
only
what
the
change
is,
but
what
the
change
is
actually
going
to
be.
How
is
it
going
to
be
implemented?
The
tooling
potential,
if
you're
using
I
know
I
don't
want
to
name
drop
terraform,
but
if
you're
using
terraform
you're
actually
seeing
the
code
and
seeing
effectively
what
is
going
to
change,
it
just
gives
you
a
greater
degree
of
visibility
and
collaboration
within
organization
and
and
it
turns
a
process
that
used
to
be
tedious,
interacting
with
other
teams.
C
B
C
You
know
the
procedure
is,
is
always
the
same.
The
real
question
is
how
we,
you
know
how
we
make
that
procedure,
something
that
is
actually
a
force
of
good
instead
of
just
annoying
people
and
forcing
to
sit
on
an
hour
listening
into
20
changes
that
potentially
they
have.
You
know
no
bearing
or
relevance
in
their
day-to-day
work
right.
B
B
D
No
exactly
it's
it's
quite
funny,
because
we,
one
of
the
things
we
like
to
do
is
actually
automate
a
large
part
of
the
change
management
and
to
be
able
to
do
that.
You
go
actually
in
talk
with
the
people
who
assess
the
changes
in
in
the
old
way
of
working
right
and
especially
in
larger
organizations,
and
you
will
have
this
buy
model
right
where
you,
you
still
have
your
old
stuff
you're,
not
you're,
not
going
to
be
able
to
pull
the
plug
in
your
mainframe.
D
Even
though
you
have
a
nice
couple
of
modern
things,
spinning
you
know,
you'll
have
both
and
then
you
ask
questions
like
what
do
you
look
at
when
you're
assessing
a
change?
And
it's
actually
quite
embarrassing
that
in
in
many
many
cases?
Well,
they
have
a
set
of
questions
they
try
to
to
ask,
and
nobody
really
knows
the
question
and
then
okay
yeah.
D
If
we
define
the
rules,
it
becomes
even
more
even
more
reliable
and
a
lot
more
consistent
than
if
you,
if
you
have
random
people,
asking
the
questions
and
still
some
complex.
Some
situations
are
too
complex
to
be
able
to
assess
automatically,
but
then
there
would
always
be
a
fallback
to
actually
do
a
manual
check
for
for
the
very
complex
situations.
B
So
I
think
this
is
a
this
is
a
critical
point
even
about
the
scope
of
technology
that
can
be
within
your
organization,
so
ginops,
I
would
say,
as
we're
kind
of
honing
on
a
definition
at
a
high
level.
It's
just
operations
by
git,
merge
request
at
gitlab.
We
call
it
a
merge
request
and
some
other
tools.
It's
called
a
pull
request,
but
you're
just
doing
operations
by
merge
request
in
order
to
do
that.
B
Of
course,
you
need
your
your
infrastructure
and
your
environments,
networking
et
cetera
to
be
defined
as
code
stored
in
version
in
a
git
repository
and
at
the
nego's
point
that
merge
request
that
becomes
the
change
management
process.
This
is
where
you
can
garner
your
approvals
and
your
coordination,
and
that
is
the
fundamentals
of
git
ops
but
who's
to
your
point,
I
and
I
heard
a
cio
describe
it
this
way
once
he
said,
I
have
a
smithsonian
of
technology,
so
you
know
it's
just
from
every
single
era.
B
So,
even
as
we're
talking
about
high
levels
of
automation,
everything
as
code
asynchronous
workflows,
we
can
do
that
often
with
our
very
with
the
modern
parts
of
our
stack,
but
sometimes
before
we
can
even
jump
into
a
git
ops
process.
Sometimes
there's
a
modernization
process
or
there's
some
parts
of
our
stack.
That'll
never
get
there,
and
so
we,
this
is
where
servicenow
is
powerful,
because
you
can,
you
can
have
a
funnel
for
across
the
scope
of
that
that
exactly.
D
You
can
bring
it
all
together
in
one
place
and
have
that
that
single
pane
of
glass,
because
I'm
not
going
to
pretend
that
servicenow,
will
actually
be
good
for
for
actually
version
controlling
your
code
or
or
actually
doing
anything
and
with
with
creating
your
environments
from
from
a
bit
of
code,
there's
many
things,
many
applications
that
that
do
those
things
very
well
but
yeah,
providing
that
insight
and
bringing
that
information
together.
That's
yeah!
B
Yeah
and
one
of
the
ways
I've
seen
it
is
to
your
point,
is
about
automating
different
flows,
so
you
might
have
a
manual
process
and
then
you
can.
This
needs
to
go
through
this
set
of
approvals,
or
this
set
of
checks
and
as
many
of
those
can
be
automated
as
possible,
and
so
sometimes,
if
your
application
or
your
infrastructure
is
legacy,
it
doesn't
allow
that
type
of
automation.
Then
maybe
there's
some
manual
steps
to
that
that
you
check
the
boxes
or
you
fill
out
the
ticket
manually.
B
C
C
I
remember
you
know,
sort
of
talking
to
people
and
going
like
hey
we're,
trying
to
drive
every
process
through
git,
and
I
went
like
good
luck,
having
an
account
and
actually
go,
and
you
know
merge
something,
because
that's
just
not
going
to
happen,
and
you
know
in
order
to
for
the
process
to
work
end
to
end.
Even
if
your
interface
is
given
the
rest
of
the
organization
is
going
to
most
likely
use
an
r
interface
right.
D
And
then
I
think
the
the
the
the
power
is
that
you
that
you,
you
store
the
the
truth
in
a
very
flexible
repository
like
git
and
and
that
you
do
the
execution
of
what
you're
delivering
in
a
very
powerful
tool.
That's
actually
specialized
for
that,
and
then
I
think,
by
by
combining
various
tools,
you
really
end
up
end
up
with
the
sweet
spot.
I
mean
I
I've
seen
so
from
servicenow
perspective.
We
are,
there's
always
been
a
lot
of
value
in
automating
stuff,
but
the
the
tricky
part
is
always.
How
do
you?
D
How
do
you
set
it
up
in
a
future
proof
scenario,
because
very
often
those
type
of
automations
they
they
change
a
lot
or,
if
you're,
I
don't
know,
if
you're
provisioning,
some
environment.
If
you're
hard
coding
in
your
request
that
the
version
of
the
environment,
then
you
need
to
constantly
update
that
and
that's
it.
That's
that's
not
really
the
place
to
to
do
those
sort
of
things.
D
B
Yeah,
so
to
that
point,
as
you
see,
and
and
this
is
the
one
thing
I'm
we'll
get
to
at
some
point,
what
are
the
steps
that
you
need
to
adopt?
Maybe
after
we've
had
some
discussion,
but
I'll
just
jump
there
for
a
moment
to
say,
but
it's
always
a
journey
right.
Maybe
the
first
step
is
just
modernizing
your
infrastructure
so
that
it
can
be
defined
as
code.
You
know
in
a
terraform
or
a
cloud
formation
or
some
type
of
tool
that
allows
you
to
do
provisioning
and
configuration
management
as
code
and
then
once
you're
there.
B
Then
it's
it's.
You
need
to
version
control
it,
and
maybe
this
is
even
before
you're
doing
any
kind
of
sophisticated
automation
of
your
approval
process
or
automated
checks
just
using
version
control
and
getting
used
to
that
flow
for
traditional
it
operations
team.
Maybe
that
is
a-
is
a
a
set
of
competencies
to
learn,
and
so
it's
always
it's
always
a
process
as
we
go,
and
so
my
question
is,
is,
as
you
have
seen,
organizations
begin
to
adopt
these
these
devops
and
git
ops
best
practices.
B
D
Oh,
I
think
we
have
a
server
over
here
and
it's
running
this
version
of
linux.
I
don't
know,
I
mean
the
amount
of
effort
that
can
be
reduced
in
that
is,
is
is
huge,
and
I
think
also
you
see
that
the
people
who
actually
and
the
the
teams,
the
dev
teams,
also
the
op
teams
and,
of
course
now
that
the
devops
teams
they
they
get
to
spend
their
time
on
a
lot
more
fun
activities
and
actually
improving
stuff,
rather
than
constantly
trying
to
solve
the
the
ongoing
misery
of
things
that
keep
falling
over.
D
So
I
think
that
the
benefits
of
that
are
quite
clear,
and
then
I
think
that
that
creates
a
little
bit
of
room
for
thinking
about
the
next
steps
right.
How
can
we
help
those
non
non
techies
who
also
need
a
particular
environment
for
something
and
because
they
now
keep
constantly
coming
to
me,
they're
sending
me
emails,
they're,
sending
me
chats
and
they
always
forget
to
to
send
the
right
information
with
it
right.
D
So,
if
you,
if
you
can
ask
them
in
a
structured
way,
and
you
can
feedback
directly
what's
going
on
and
always
offer
them
the
latest
stuff,
but
also
standardize
it
through
your
through
your
if
you're
a
larger
organization,
the
possibilities
to
if
one
team
has
developed
a
spend
a
lot
of
time,
setting
up
the
perfect
recipe
for
a
particular
testing
environment,
you
shouldn't
have
to
have
the
other
team
doing
the
same
thing.
If
you
can
expose
that,
and
you
can
show
that
and
of
course,
that
that's
very,
very
beneficial.
D
C
A
B
B
C
So
you
hit
the
nail
in
the
head
like
a
lot
of
people.
I
you
know
and
again
I
work
a
lot
with
the
sales
team
right.
So
you
you
immediately
hear
you
know
business
value
and
it's
directly
tied
to
like
yeah.
What's
what's
my
return
of
investment
of
offering
this
tool,
but
it
it's
just
so
much
more
like
you
know,
with
all
due
respect,
who
cares
about
quantifying
the
hours
that
you
know,
people
are
going
to
say
because
they
use
githubs
just
their
general
predisposition
to
work.
C
Considering
that
you
know
I,
I
had
a
role
in
an
organization
where
I
actually
had
to
go
and
chase
tickets
through
teams,
and
I
was
an
account
manager
and
hey
yeah.
We
need
to
do
this
change
and
basically
it
will
send
the
ticket
to
the
network
team.
Wait
six
hours
then
go
and
chase
the
network
team
to
pass
the
ticket
to
an
r
team
and
so
on
and
so
forth.
Just
a
general
for
this
position.
C
I
don't
think
that's
something
that
you
can
quantify
and
put
a
dollar
value
or
euro
value
or
pound
value
or
francs
whatever,
but
ultimately
it
just
changed.
The
whole
approach
to
it
just
changes
how
people
think
about
work,
they
go,
they
do
their
thing
and
they
go
and
follow
something
else.
It's
non-blocking
the
handovers
are
handled
elegantly
by
the
tool
and
that's
pretty
much
it.
Okay,
you
go,
you
do
your
work
and
you
don't
have
to
chase
people
to
do
theirs.
D
Exactly
and
also,
I
think
in
terms
of
interacting
with,
for
example,
the
business,
if
the,
if
the
tone
shifts
from
always
complaining
why
something
is
broke
or
why
some
things
are
taking
seven
weeks
or
two
months
or
three
months
versus
actually
asking
something.
Oh,
that's
a
nice
idea.
Let
me
see
what
I
can
do
and
actually
delivering
that
and
thinking
along
that
that
that
that's
a
totally
different
way
and
I
think
all
parties
can
win
in
the
end
and.
B
B
Large
organizations
is
the
most
expensive
talent
and
the
hardest
to
attract
talent
in
your
organization.
Is
your
software
engineering
force
your
software
developers
and
your
operations
team?
That's
gonna.
The
people
who
build
the
people
who
run
your
software
are
the
hardest
to
attract
talent
and
the
hardest
to
retain
talent
right.
D
B
B
So
obviously
you
know
the
some
things
are
tough.
You
have
the
mainframe
that's
going
to
take
a
little
bit
longer,
but
to
to
sometimes
the
enterprise
or
the
large
organization
can
be
scared
of
adopting
new
technologies,
cloud
native
and
get
ops
and
they
say
we're
not
quite
there.
Yet
we
don't
want
to
move
forward
too
fast,
but
there's
a
very
real
business
return
on
if
you
are
using
new
technologies.
This
is
this
is
what
folks,
who
do
software
engineering
enjoy
working
with
and
by
just
moving
a
little
bit
step
forward?
B
D
All
right-
and
I
think,
if
we're
talking
business
guys,
I
mean
developer
developer
happiness
is
one
thing,
but
another
and
another
huge
cost
that
especially
larger
organizations
are
making
are,
is
more
on
the
on
the
audit
side
of
of
things
right,
showing
that
you
are
in
control.
We've
already
touched
upon
change,
control,
of
course,
but
also
actually
showing
that
these
are
my
recipes.
D
But
if
you
have
all
that
information
present
in
in
a
single
in
the
single
system-
and
you
can
actually
audit
and
monitor
those
those
controls
automatically,
which
becomes
a
lot
easier,
if
you
have
that
documented
in
a
structured
way
and
that's
just
it's-
it's
not
documentation
after
effects.
But
it's
the
documentation
that
decide
on
the
facts.
In
the
end.
B
Rather
than
going
out
to
separate
tools,
pulling
data
manually
normalizing
that
data
figuring
out
who
made
which
change
to
what,
when
all
of
that
information
is
now
you
you
get
for
free
in
a
sense
by
using
git,
it
tells
you
what
changed
exactly
to
the
line.
It
tells
you
who
made
that
change
when
that
change
happened,
and
you
can
go
back
in
time
so
auditing
and
compliance
all
of
a
sudden.
Yes,
your
evidence
gathering
is
greatly
reduced.
B
It's
it's
in
one
place,
rather
than
scattered
across
or
the
more
things
you
can
store
and
get
the
you
get
that
audit
log
and
the
other,
the
other
value
that
I
hear
so
with
the
most
most
organizations.
I
talk
to
it's
not
always
about
speed
or
developer
happiness,
although
we
all
care
about
those
things,
but
honestly
they
list
compliance,
improving
their
auditing
and
compliance
is
the
number
one
reason
they
want
to
adopt.
Get
ops
and
you
get
all
these
other
benefits
as
well.
B
B
B
But
now
you
have
a
state
of
record
of
what
the
broken
infrastructure
was
you
can
you
can
set
that
up
in
another
testing
environment
and
now
go
and
do
all
the
forensics
and
figure
out
why
it
broke
and
then
engineer
yourself
out
of
that,
and
so
this
is
something
that,
like
a
large
gitlab
customer,
that's
doing
get
offs.
This
is
one
of
the
values
that
they
say
is
really
help
their
meantime
to
recovery,
because
they
can
separate
the
process
of
figuring
out.
Why,
from
the
process
of
getting
it
back
up
right.
D
And
then,
if
you
connect
it
to
your
environment,
where
you
have
your
itil
process
right,
your
incident
management,
you
have
your
cmdb
there,
you,
you
pull
that
or
you
expose
that
information
from
get
there
and
you
can
actually
see
okay.
This
version
was
applied
to
this
particular
environment,
which
we
spun
up
at
this
time,
and
then
this
happened,
and
you
can
see
that
even
visually
on
the
timeline.
D
C
C
Let's
be
honest,
like
the
the
people
that
are
developing
these
practices
today,
they
do
it
based
on
a
industry
best
practice
which
are
which
arguably
is
ital
and
b
just
to
moder
the
modernization
of
that.
No
one
is
saying:
stop
doing
change
management,
so
do
doing
incident
management.
You
know,
stop
analyzing
changes.
The
only
thing
we're
saying
is
no
one
said
it
had
to
be
a
call
it's
not
on
the
icy
level.
So
I
can
tell
you
that
no
one
said
it
had
to
be
a
call.
C
Okay,
it
says
what
information
you
have
to
collect.
You
know
how
you
collect
information
about
a
configuration
item
and
so
on,
but
ultimately
no
one
said
it
had
to
be
a
call.
So
what
you're
doing
here
is
just
honestly
super
sizing
i2,
and
do
you
need
to
a
a
level
of
control
on
the
level
of
detail
that
I
think
you
know
maybe
20
25
years
ago?
We
just
couldn't.
We
didn't
have
the
tool,
that's
right.
We
also
didn't.
Arguably
we
didn't
have
the
scale
of
it.
B
D
There
have
been
thousands
of
people
that
couldn't
work
for
days
because
the
technology
so
in
that,
in
that
sense,
having
having
cloud
native
applications
running,
which
you
can
scale
at
the
point
that
you
need
them,
is
also
a
very,
very,
very
good
business
case,
so
yeah
indeed,
the
importance
has
also
been
been
rising
a
lot.
Hence
the
yeah.
B
Yeah,
I
think
this
is
a
great
analogy
for
it
that
many
of
us
can
feel
right
now,
because
covet
has
been
so
disruptive
and
at
gitlab
gitlab
has
been
a
remote
company.
Almost
since,
since
git
lab
was
seven
employees,
it
was
all
remote
and
now
it's
1300
employees,
it's
the
largest
all
remote
company
and
we
were
remote
before
covet.
B
So
we
have
perfected
the
art
of
remote-
I
might
say,
maybe
not
perfected,
but
are
have
a
really
great
reference
for
how
to
do
it
and
how
to
do
it
well,
and
we've
been
doing
that
for
a
long
time
and
one
of
the
things
that
we
do
is
because
we're
so
influenced
by
the
git
flow.
This
asynchronous
of
I
can
propose
a
change.
B
Then
this
other
person
on
their
own
time
frame,
can
go
and
review
that
change
and
leave
me
comments
in
line
on
the
code
and
then
I
go
through
and
address
those
in
my
own
time
and
make
the
updates
everything
happens.
You
can
be
around
the
world
in
different
time
zones.
You
make
your
comments
while
I'm
sleeping,
etc
or
while
I'm
taking
my
kids
to
school.
B
No
one
said
it
had
to
be
a
call
yeah
a
lot
of
colleagues,
a
lot
of
colleagues
that
I
I
talked
to.
They
say
okay,
ever
since
covid
I
get
up
in
the
morning,
and
I
get
on
a
video
call
and
I'm
on
the
video
call
all
day
until
the
end
of
the
day-
and
I
was
telling
you
you're
doing
it
wrong
this-
that
coveted
remote.
That
is
not
real
trust.
Me.
I've
been
doing
remote
work
way
before
kovis.
You
have
to
figure
out
how
to
use
write
it
down,
write
something
down.
B
C
That
is
some
git
period
like
we
have
no
better
way
of
having
a
team
that
is
so
distributed
to
collaborate
right.
We
much
like
gitlab,
we
never
had
an
office.
Well,
we
have
an
office
in
san
francisco,
but
our
team
was
never
in
an
office.
So
every
time
we
have
to
collaborate
on
content
or
we
have
to
do
something
that
is
sort
of
outside
the
remit
of
our
local
work.
Hell.
C
B
I
didn't
say
so:
I
wouldn't
I
did
it.
It
was
so
easy,
but
at
get
lab
the
sales
people
do
use
git,
that's
not
something
I
necessarily
recommend
to
everybody,
but
to
your
point,
nico,
there's.
A
lot
of
this
is
a
little
bit
off
the
topic
of
git
ops.
But
there's
there's
a
lot.
You
can
store
in
a
version
control.
So,
for
example,
we
we
have
our
internal
wiki
is
really
actually
just
a
website.
B
We
actually
make
it
public,
but
you
don't
have
to,
but
it's
a
website
and
it's
written
in
markdown
and
markdown
is
something
that
almost
anybody
can
use
so
literally
even
sales.
My
wife
is
a
paralegal
in
the
legal
department,
chooses
get
every
day,
yeah,
so
sales
sales,
folks
legal
marketing,
some
of
those
practices
can
spread
out.
But
for
the
focus
of
this
call,
when
we're
just
talking
about
it,
doesn't
have
to
be
a
call,
you
can
store
it
as
code
and
there's
a
lot
of
infrastructures
code
tools
out
there.
B
I
would
say
the
major
components
to
get
ops
are
storing
the
infrastructure's
code
of
the
environment
state
as
code,
and
then
your
change
management
process
is
now
becomes
the
merge
request
or
the
pull
request.
That
is
your
point
of
inflection,
where
you
and
then
the
last
component
is
the
automation,
the
ci
cd.
So
any
changes
you're
no
longer
manually,
applying
changes
to
your
infrastructure.
B
B
C
Sort
of
you
have,
the
important
part
is
having
tooling
and
people
collaborate
through
that
sort
of
single
unit,
which
is
the
the
merge
request
or
the
pull
request.
Okay,
ultimately,
when
you
look
at
your,
where
is
your
ci
processes?
Or
you
know
your
servicenow
processes
or,
in
our
case
terraform
enterprise?
Would
actually
you
know,
push
this
information
into
the
merge
request
or
the
or
the
pull
request.
You
know
you
have
to
have
on
that
unit.
D
Right
and-
and
I
think
when
it
comes
to
especially
the
larger
organizations,
the
basis
of
your
change
will
indeed
be
that
merge
request
where
you
have
all
those
details,
but
especially
in
large
organizations
where
you
have
also
a
lot
of
different
type
of
organizations
which
are
not
necessarily
emerge
or
even
commit
based
right.
There
could
be
any
type
of
change.
In
fact,
in
in
many
organizations
they
still
have
surfers
sitting
in
wrecks
in
their
basement.
D
That
still
happens
as
well,
and
actually,
if
they,
if
they
take
out
the
surf
of
wreck,
a
and
move
it
to
another
room
because
they
need
to,
I
don't
know,
redo
the
aircraft
or
something.
That
would
also
be
a
change
of
course,
and
I
don't
think
githubs
would
be
suitable
for
for
moving
well.
Actually,
it
might
be,
but
I
think
you
touched.
B
On
that,
it's
it's
a
process
that
you
adopt
over
time.
Not
everything
is
going
to
be
stored
in
git.
So,
although
that
you
can
get
these
powerful
benefits,
I
think
this
is.
This
is
how
we
approach
it.
I
wonder
if
we
have
questions
from
chat.
I
love
that
I
love
where
the
conversation
is
going,
but
I
wanna
see
if
we
have
from
our
audience
chandan.
A
B
B
Is
I
think,
yes,
I
I
think
that
the
components
the
components
of
git
ops
are
in
that
question:
you're
you're
versioning,
your
it's
your
code,
you
are
you're,
automating
the
changes
and
not
to
get
too
deep
into
it.
I
think
there's
two
types
of
of
get
offs
that
I've
seen
or
this
depends
on
just
whatever
tooling
you
have
at
gitlab.
We
actually
have
both
of
these
one
is
the
push.
So
your
cicd
tool
takes
something
happens
in
git.
B
B
So
if
you're
not
using
kubernetes,
then
running
a
running
agent
within
that
infrastructure
clusters
becomes
a
lot
more
challenging,
but
with
kubernetes
infrastructures.
Maybe
you
have
an
agent
and
it's
just
constantly
monitoring
the
state
of
the
infrastructure
to
say:
is
it
the
same
as
as
my
source
of
truth
and
get?
And
if
it's
not
reconcile
the
two,
and
so
it
pulls
changes
into
the
kubernetes
cluster,
so
they
mentioned
a
pull
or
versus
a
push.
A
Awesome,
I'm
gonna
move
on
to
the
next
one,
so
the
next
one
is
I'm
using
github's
integration
with
ci
cd
pipelines,
secrets
with
vault
and
git
as
a
single
source
of
truth,
but
I'm
still
being
challenged
by
the
cab
meetings.
How
do
you
convince
that
we
do
not
need
these
meetings?
That's
the
question.
D
Right,
I
think
I
can.
I
can
take
that
one,
so
this
is
actually
a
scenario
that
we
see
a
lot
with
various
organizations
that
the
the
first
of
all
the
people
doing
that
they
they
might
even
feel
threatened.
If
you,
if
you
say
that
you
you
don't
need
that
anymore,
and
I
think
what
an
indian
boils
down
to.
D
What
we
see
is
that
if
we
integrate
such
a
pipeline
and
before
the
deployment
actually
goes
through,
we
integrate
that
with
the
servicenow
change
management,
module,
for
example,
that
this
change
process
can
still
be
there,
and
we
can
still
make
it
visible
to
them
that
all
the
steps
they
normally
take
are
actually
being
taken
right.
We
attach
all
the
right
evidence
with
the
with
actually
the
commits
that
we
pull
from
get
the
the
even
the
work
items
that
we
pull
from
there
from
the
agile
tool.
D
We
could
even
have
the
test
results
showing
up
there,
and
then
we
could
say
look
because
we
can
see
that
all
the
user
stories
are
closed,
that
the
commits
have
all
been
messaged
correctly.
We
did.
We
did
a
couple
of
automated
tests,
they
passed.
Actually,
in
fact,
we
did
a
static
code
analysis
and
we
and
we
saw
that
in
fact,
all
the
rules
were
complied
with.
D
For
example,
we
can
see
in
the
in
the
code
that
there
are
no
ports
being
opened
that
should
not
be
open
and
for
these
and
these
and
these-
and
these
reasons
we
automatically
approve
it,
they
will
still
have
the
visibility.
They
can
still
see
it.
They
they
they
don't
lose
control,
because
I
think
that's
that's
that's
the
whole.
The
change
management
is
all
about
control
and
and
they
actually
have
a
responsibility
responsibility
to
be
in
control.
So
if
you
take
the
process
out
of
their
hands,
they
lose
control
and
naturally
they're
they're
against
that.
D
But
if
you
keep
them
in
control
and
also
in
case
there
are
certain
exceptions.
For
example,
you
might
need
that
firewall
port
to
be
opened
specifically
for
for
the
application
you're
using
it.
For
then
you
could
ask
them
in
fact,
for
for
approval,
or
you
could
attach
approval
from
security
that
they
are
in
fact,
okay
with
this
situation,
but
I
think
the
key
is
keep
them
involved,
inform
them.
Let
them
see
that
they're
still
in
control,
but
also
it
really
helps
them
right.
Often,
the
the
the
traditional
cap
teams
are
heavily
overloaded.
D
They
have
a
backlog
sometimes
of
four
to
six
weeks.
Some
changes
that
took
half
an
hour
to
develop
have
to
sit
and
wait
six
weeks
before
they
are
queued
up
for
actually
being
approved,
so
yeah
automating.
Eighty
percent
of
what
they
have
to
assess
will
speed
up
that
eighty
percent
massively,
but
it
will
even
speed
up
the
remaining
complex
twenty
20
and
it
will
enable
them
to
do
a
better
job
in
the
end.
B
B
C
Know
justin,
I
mean
honestly
if
you
like.
The
call
call
me
you
know
call
me
anytime,
I'm
happy
to
clarify
anything,
but
it
doesn't
have
to
be
exactly
it
doesn't
have
to
be.
You
know
I
participated
on
my
fair
share
of
those
and
I
can
tell
you
that,
probably
nine
out
of
ten
times
I
was
presenting
a
change
and
I
was
giving
detail
and
I
you
know
the
dba
didn't
couldn't
even
relate
the
information
I
was
providing
to
the
actual
servers
where
you
know
that
dba
was
running
engines.
C
That
is
the
honest
truth
about
the
cavs.
That
is
why
this
process
is
so
much
more
virtuous
that
that
you
know
the
traditional
change
advisory
board.
Again,
no
one
is
saying
get
rid
of
the
change
advisory
board.
The
board
exists.
The
call
is
what
doesn't
exist
because,
ultimately
you
go
you're
going
to.
I
know.
C
C
Ultimately,
I'm
going
to
go
and
mark
us
approvers
everyone
in
that
application
team,
so
they
can
go
and
review
and
see
exactly
from
the
code
which
version
of
wildfly
I'm
going
to
be
deploying
and
go
and
say,
yay
or
nay,
and
that
is
much
better
information
that
they
were
going
to
get
on
the
phone.
So,
ultimately,
we're
not
disbanding
the
cab
we're
actually
making
it
useful
exactly.
B
B
What
is
what
is
the
change
management
process
for
changing
my
change
management?
It's
a
little
bit
meta
way
of
thinking,
and
so
this
is
often
the
case
with
any
type
of
technology.
Modernization,
especially
when
I
talk
to
it
leaders.
Often
the
technology
is
not
the
problem,
it's
the
culture
and
the
people,
and
we
need
to
remember
as
technologists
that
we're
all
we're
always
dealing
with
people
exactly.
B
B
That
was
a
thousand
changes
to
a
thousand
files,
or
maybe
you
do
and
it's
a
mess
to
review
and
it
has
a
thousand
merged
conflicts
and
it
never
goes
in,
and
so,
if
we're,
as
as
platform
engineers
as
software
developers,
we've
learned
over
time
working
with
git
those
of
us
that
have
used
it
for
a
long
time,
the
smaller
you
make
the
change
that
small
change
is
very
powerful.
So
so
many
small
changes
are.
B
What
leads
us
to
the
reliability
is
what
leads
us
to
they're
easier
to
reason
about
and
pull
things
out
that
don't
work.
This
is
how
we
approach
our
software.
Development
is
many
little
small
iterations,
but
all
of
a
sudden
we
go
to
the
change
management
board
and
we
say
you
know
I
stuck
everything
in
git.
You
are
obsolete,
let's
get
rid
of
this
yeah
and
it's
almost
like
you're
saying
to
the
organization.
Here's
this
thousand
thousand
line
merge,
requests
to
a
thousand
files
and
I'm
not
expecting
any
merge
conflicts
right.
B
B
Can
we
try
this
automation
thing
right,
and
I
call
that
the
lighthouse
project?
It's
almost
like
the
lighthouse
on
the
that
avoids
you
from
running
into
the
cliffs,
and
it
leads
you
to
the
way
and
so
to
nico's
point
about
now.
All
of
a
sudden,
you
can
show
them
look
we're
not
obsoleting
you
we're
making
you
more
powerful,
we're
not
we're
not
giving
you
less
information,
we're
giving
you
more
and
if
you
can
show
them
with
a
little
small
way
how
that
works.
B
Sometimes
that
little
small
change
and
then
maybe
you
can
add
one
more
and
so
doing
that
iterative
change
the
same
way.
You
approach
an
application
in
your
infrastructure.
That
is
how
I
see
organizations
change
as
well
with
that.
I
think
we're
just
about
on
time,
but
but
nico.
Closing
final
thought.
C
D
I'm
gonna
say
I'm
I'm
really
inspired
by
the
by
the
quote.
Nobody
said
it
has
to
be
a
call,
I'm
I'm
definitely
going
to
to
keep
that
in
there
now.
I
think
it
was
a.
I
really
enjoyed
this
conversation.
I
I'm
kind
of
sad
that
the
hour
is
already
almost
gone
but
yeah,
I
think,
there's
a
lot
of
possibilities
and
actually,
I
think
to
the
point
of
making
it
happen.
B
Well,
I
want
to
thank
you
so
much
both
of
you
for
being
on
the
call
chandan
for
hosting
us
again,
I'm
william
from
git
lab.
We,
I
would
say,
is
the
next
step
we're
here.
We
want
to
help
you
if
you
are
interested
in
servicenow
technologies.
If
you
are
interested
in
hashicorp
technologies,
a
lot
of
those
are
enablers
of
git,
ops
or
git
lab.
B
We
want
to
help
you
in
continuous
conversation,
so
so
you
can
add
a
question
you
can
type
in
a
chat
we'll
look
at
those
logs
after
this
webcast
is
over,
raise
your
hand
in
the
interface
any
of
those
interactions,
and
our
teams
will
follow
up
with
you
to
keep
the
conversation
going.
So
we
certainly
have
enjoyed
everyone
being
on
this
webcast
today
on
this
call,
and
so
now
let's
go
and
continue
asynchronous
through
some
text.
A
A
So
we
will
now
be
processing
the
recording
of
this.
So
those
of
you
who
want
a
copy
of
this
will
eventually
hear
from
the
team
at
gitlab
who
will
reach
out
to
you
with
the
with
the
copy
of
the
recording
and
then
subsequently
in
order
to
have
conversations
with
you
on
how
they
can
help
you
and
make
a
difference
in
your
processes
once
again.
Thank
you
so
much
and
have
a
nice
rest
of
the
day.
Take
care
bye.