►
From YouTube: Keynote Panel: Why GitOps? - Tracy Ragan, Dan Garfield, Cornelia Davis, Moderated by Dan Lorenc
Description
Keynote Panel: Why GitOps? - Tracy Ragan, DeployHub; Dan Garfield, Codefresh; Cornelia Davis, Weaveworks; Moderated by Dan Lorenc, Google
GitOps, Infrastructure as Code, and the DevOps pipeline, how do they fit together and how are they different? Join this amazing panel of industry leaders including Cornelia Davis, Weaveworks, Tracy Ragan, DeployHub, and Dan Garfield of Codefresh, moderated by Dan Lorenc of Google and the CDF TOC chair. Hear how they define GitOps and where it fits into CI/CD. They will explore the beginnings of GitOps and discuss how it will mature as more companies begin their journey into operations by pull request. Learn if GitOps will work for your organization and understand the challenges before you make the move.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
All
right,
hello,
everyone
and
welcome.
We
are
doing
a
panel
today
on
git
ops.
The
title
is:
why
get
ups
so
we're
going
to
be
discussing
a
whole
bunch
of
topics
related
to
the
practice
of
git
ops
and
the
motivations
for
it?
So
my
name
is
dan
lawrence.
I'm
the
chair
of
the
container,
still
refoundation
toc
and
I'm
a
software
engineer
at
google.
I
have
a
bunch
of
awesome
panelists
here
that
I'm
going
to
let
introduce
themselves
dan
garfield.
Do
you
want
to
go
first.
B
D
All
right,
I
think
that
leaves
me
I'm
cornelia
davis,
I
am
the
cto
at
weave
works.
Weave
works
refers
to
itself
as
the
get
get-ups
company,
and
so
I
think,
we'll
talk
a
little
bit
more
about
where
that
came
from
in
just
a
moment.
My
background
is
I've,
been
in
the
industry
for
about
30
years,
I've
been
working
on
developer
platforms
for
about
the
last
10
years
prior
to
weave
works,
which
I've
been
here
for
almost
a
year
and
a
half.
D
I
was
at
pivotal
where
I
first
worked
on
cloud
foundry
and
then
later
on,
worked
on
kubernetes-based,
developer
platforms,
but
all
was
from
the
focus
of
developer,
enablement
and
developer
self-serve,
I'm
also
an
author.
I
wrote
a
book
called
cloud
native
patterns
which
is
targeted
at
the
application,
developer
and
architect,
and
I'm
part
of
the
cncf
technical
oversight
committee
as
well.
A
D
Yeah
sure
so,
quick,
quick
history
lesson.
So,
yes,
I
do
believe
I
don't
think
anybody's
ever
like,
like
suggested
otherwise,
but
my
founder
one
of
my
co-founders
and
ceo
alexis
richardson
coined
the
term
and
the
way
this
story
goes
is
before
my
time
at
weave
works.
Weave
works
was
not
originally
a
get
ops
company,
it
was
originally
around.
You
know
networking
for
container
based
environments
and
things
like
that
went
through
a
number
of
evolutions
and
it
had
an
observability
project.
D
It
was
the
founder
of
cortex
as
well,
which
is
another
cncf
project,
and
we
were
running
that
as
a
sas
service
and
long
story
short.
We
had
an
outage
and
we
were
able
to
recover
from
that
outage.
It
was
a
complete
total
outage
of
the
sas
service.
We
were
able
to
recover
from
that
in
about
45
minutes
and
the
reason
we
were
able
to
recover
from
that
was
because
of
what
turned
out
to
be
these
getups
principles
that
we'll
talk
about.
D
Throughout
the
conversation,
we
had
a
complete
representation
of
the
desired
state
of
the
system
and
we
had
the
right
kind
of
automation
that
could
make
it
so,
and
so
all
we
needed
to
do
was
point
that
to
new
infrastructure
and
it
came
back
up,
and
that
was
a
big
aha
moment.
It
was
that
our
engineers
that
were
running
the
sas
service
had
put
into
place
these
practices
because
they
saw
value
in
them
and
found
value
in
them.
A
Interesting
to
hear
it
came
from
averting
a
potential
disaster.
I
was
just
there
myself
last
week
when
I
it
wasn't
a
real
production
system,
but
I
ran
control,
delete
on
the
wrong
cluster
and
had
to
quickly
scramble
and
had
a
moment
of
panic,
to
find
out
what
cluster
I
was
in
and
I
got
everything
restored
because
it
was
all
in
a
git
repository,
tanner
and
tracy.
What
were
your
first
experiences
with
get
ops.
B
A
C
So
I've
just
begun
seeing
github
sort
of
show
up
over
the
course
of
the
last
like
few
years,
but
my
first
kind
of
exposure
to
this
kind
of
technology
really
came
from
infrastructure
as
code
when
we
started
playing
with
you,
know,
spinning
up
environments
and
having
a
an
operator
that
lived
outside
of
a
cluster
and
was
able
to
define
your
infrastructure
really
really
quickly
and
for
a
small
company.
We
found
that
to
be
extremely
helpful
because
having
somebody
sit
and
do
things
in
a
very
declarative
way
or
imperative
way
was
not
an
option.
B
I
mean
we've
been
doing
this
stuff
for
years
right,
we've
been
storing
our
stuff
in
git
infrastructure,
as
code
has
been
huge,
we've
been
following
all
these
patterns,
you
know
consistently
and
so
having
it
kind
of
put
and
packaged
in
that
way
where
it
all
felt
like
it
was
part
of
one
specific
paradigm
that
was
really
valuable,
and
so
we
started
building
on
top
of
that
and
figuring
out
like
how
do
we
do
this
with
like
a
canary
release?
And
how
do
we
do
this?
B
B
You
know
you,
you,
young
upstarts,
with
your
with
your
fancy
words.
This
is,
you
know,
we've
been
doing
this
a
long
time
I
invented
this
15
years
ago.
Why
are
you
talking
about
git
ops
as
if
it's
a
new
thing,
and
so
I
thought
a
lot
about
that
and
what
the
difference
is,
and
I
think
that
people
like
henry
ford
wasn't
the
first
person
to
invent
the
car.
You
know
there
were
a
bunch
of
people
that
invented
the
car.
B
They
were
they
built
cars,
but
what
he
did
was
he
built
an
assembly
line
and
made
it
so
that
cars
were
accessible
to
everybody,
and
I
think
that
what
where
get
off
started
and
where
now
it's
going,
especially
with
the
work
that's
happening,
is
to
make
it
accessible
and
repeatable
and
easy
for
everybody
to
do,
and
so
that
stage
I
mean
that's.
Why
we're
talking
about
it
today
is
because
get
ops
is
getting
to
a
point
and
the
tools
are
getting
to
a
point
where
it's
easily
accessible
by
everybody,
and
it's
not
just
you
know.
B
Well,
you
know.
Here's
some
principles
and
you've
got
a
road
map
and
and
get
five
engineers
together,
and
you
go
figure
out
how
to
implement
all
this
stuff.
You
know
they're,
really,
it's
really
getting
streamlined
into
something
straightforward
and
the
tools
are
maturing
to
a
place
where
everybody
can
use
it.
D
A
Okay,
so
I
think
one
of
the
other
big
trends
we've
seen
you
know,
since
this
is
the
continuous
delivery
foundation
is
people
trying
to
integrate,
get
ops
into
a
cd
pipeline?
Is
that
the
only
way
to
do
git
ups?
Do
you
think
it's
possible
to
do
git
ops
without
doing
continuous
delivery,
or
is
there
some
kind
of
benefit
to
combining
them?
I'll
start
with
you,
tracy.
C
So
definitions
are
important
right,
get
ops
if
you
think
about
what
getups
is
in
relation
to
the
continuous
delivery
pipeline.
It's
really
the
continuous
deployment
phase
of
the
continuous
delivery
pipeline,
and
it
is
an
amazing
way
to
get
to
continuous
deployment
and
in
dan
garfield's
analogy
of
you
know
henry
ford,
his
assembly
line.
C
It
isn't
it's
not
orchestrating
testing,
it's
not
orchestrating
a
ci
build
it's
not
doing
any
of
that.
It's
doing
what
it
needs
to
do
to
make
it
to
make
sure
that
we
have
a
true
repeatable,
continuous
deployment
process
that
that
the
deployment
at
dev
is
done,
the
same
as
test
as
the
same
as
prod.
We
have
not
achieved
this
in
continuous
delivery.
Really
some
people
have
and
there
are
tools
out
there
that
are
making
that
happen.
C
D
Yeah
I
mean
if
I
could
I'd
love
to
interject
and
add
a
little
bit
to
that,
there's
so
much
to
unpack.
You
said
an
awful
lot
there,
but
the
way
that
I
I
sometimes
think
of
it,
as
I
think,
of
what
you're
referring
to
as
continuous
delivery
and
again,
I
think
that
there
isn't
one
way
that
people
use
the
term
continuous
delivery,
but
in
the
way
that
you
are
using
the
term,
I
think,
of
the
kind
of
continuous
delivery
pipeline.
D
As
this
horizontal
thing
that
says
all
right,
I've
got
various
stages
of
my
software
delivery
life
cycle.
I've
got
my
dev
stage,
my
testing
stage,
my
you
know,
user
acceptance,
testing
my
staging
and
then
my
production
and
you're
controlling
a
great
deal
of
the
of
the
gates
that
need
to
be
gone
through
the
things
that
need
to
be
satisfied,
the
conditions
that
need
to
be
met
as
you
go
through
that,
and
I
think
what
you're
saying
tracy
is
that
within
one
of
those,
then
we
have
a
consistent
way.
You
know
kind
of
going
downward.
D
We
have
a
consistent
way
across
all
of
these
different
stages.
To
then
realize
things
into
that
environment
and
that's
where
we
can
consistently
apply
these
git
ops
practices.
Of
course,
some
people
consider
taking
things
from
git
out
into
the
into
say,
kubernetes
as
part
of
the
delivery
process.
So
we,
I
don't
think
we
can
work
through
kind
of
that
that
definitional
thing
here
on
this
panel,
but
you're
right
that
that
goes
down
there.
D
But
the
the
last
thing
that
I
want
to
say
is
that
there
is
in,
in
my
mind,
no
such
thing
as
the
continuous
deployment
operator,
the
the
get
ops
operator,
because
git
ops
is
really
about
not
only
the
the
watching
get
and
then
bringing
things
into.
Let's
say
the
kubernetes
store
the
fcd
store,
but
it's
also.
D
How
do
you
relate
that
to
the
actual
running
state
of
the
things
that
you
have
expressed
in
that
in
that
get
repository,
so
there
you
have
to
link
it
together
with
these
other
operators
that
are
making
it
so
and
so
there's
this
kind
of
pair
between
I've
got
to
get
things
into
my
runtime
environment,
and
then
I've
got
operators
that
operate
on
that,
not
until
it's
a
running
pod.
If
you're
doing
containers
is
it
actually
in
operations,
so
get
ops
is
about
managing
that
it's
not
just
about
git
to
kubernetes.
B
But
ideally
you
know
you
don't
have
people
with
connections
to
a
production
cluster
like
after
it's
set
up.
Maybe
even
ever
I
mean.
Ideally,
every
single
operation
is
happening
through
git,
and
so
you,
I
think
we're
going
to
get
to
that
point
from
a
cd
standpoint
where
no,
no,
we
don't,
we
don't
have
keys
to
production.
What
are
you
talking
about
like
it's
not
sitting
on
somebody's
laptop,
like
that's
crazy,
like
what.
B
We
can
eliminate
all
that
stuff
by
following
this
process
and
relying
on
it
and
I'm
not
saying
that
we're
a
hundred
percent
there.
Yet
I
think
we're
getting
close.
But
you
know
there
are
certain
situations
where
you
might
need
to
escalate,
but
ideally
you
are
able
to
accomplish
and
get
to
continuous
delivery
with
get
ops,
because
it
is
a
pattern
that
lets
you
do
it,
and
so
so
so
many
deployments
that
are
happening
today
I
mean
what
percentage
of
deployments
are
happening
in
a
fully
automated
fashion.
B
D
D
Operator
would
have
said,
wait
a
minute,
there's
a
difference
now
between
what
we
have
and
get,
and
you
could
set
up
the
policy
that
says
you
know
what,
if
you
drift
from
that,
then
restore
it
back
to
what's
in
git.
Git
is
the
source
of
truth,
so
you
wouldn't
have
had
to
scramble.
Get
offs
would
have
scrambled
for
you.
A
Yeah,
I
really
like
that
term
and
the
operator
term.
We
talked
about
a
bunch
of
times
because
I
think
it
really
encapsulates
the
all
the
manual
tasks
that
a
human
operator
would
have
been
doing
in
the
past.
Thankfully
my
case
wasn't
a
production
system.
Nobody
is
silly
enough
to
let
me
near
one
at
all,
in
particular
my
laptop,
but
you
started
to
touch
on
some
other.
I
guess
pretty
important
things
in
the
news.
A
lot
lately
down
with
security.
B
Yeah,
I
think
that
it's
critical
and
security
is
often
thought
of
as
things
that
we
keep
out
of
production,
but
security
is
just
as
much
about
getting
things
into
production
because
the
software
that
you
have
deployed
in
production
right
now
has
vulnerabilities.
I
mean
it's
statistically
certain
that
you
have
vulnerabilities
in
production
today.
You
don't
know
about
them.
Maybe
nobody
knows
about
them.
B
Ideally,
nobody
knows
right,
but
as
patches
come
out
to
the
software
that
you're
relying
on
you're
gonna
want
to
get
that
patched,
really
quick
right
and
the
best
way
to
do
that
is,
if
you
have,
if
you're,
using
git,
ops
and
you're
using
a
standard,
you
know
protocol
for
rolling
things
out,
you're
going
to
be
able
to
easily
commit
those
changes,
get
them
staged,
get
them
into
production.
You
know
in
seconds
or
minutes
rather
than
hours
or
days
or
weeks.
B
So
security
is
about
deploying
faster
if
you
want
to
be
more
stable
and
more
secure,
you're
going
to
have
to
find
a
way
to
deploy
faster
for
sure,
and
it's
also
about
auditability
going
back
on
the
other
end,
where
drift
detection
is
a
key
element
here.
If
somebody
is
able
to
gain
access
to
your
environment
and
start
making
changes
well
with
drift
detection,
they're
going
to
be
just
constantly
getting
rebooted
out,
because
it's
going
to
be
noticed
that
the
state
is
not
the
one
that's
desired
and
defined
in
git.
B
Now,
ideally,
you
got
to
go
patch
that
hole,
so
they
can't
keep
getting
in.
But
but
it's
super,
it's
super
critical
from
a
security
standpoint
and
to
be
to
be
effective
from
the
security
standpoint.
You
have
to
be
effective
from
the
productivity
standpoint,
which
is
great,
because
that
means
it's
a
win-win.
If
you
can
figure
it
out.
C
So,
as
cornelia
pointed
out,
if
you
tweak
it
manually,
the
getups
operator
is
going
to
say
yeah,
that's
out
of
sync,
I'm
going
to
bring
it
back
to
the
state,
that's
defined.
So
by
doing
that,
you
eliminate
the
external
hacker
that
is
tweaking
things
that
they
shouldn't
be,
even
if
they
are
somebody
who
works
for
the
company.
This
is
this
is
one
of
the
the
the
cultural
things
that
will
change.
There
are
so
many
people
I
talk
to
that
are
like,
but
I'm
so
used
to
using
the
command
line.
C
I'm
so
used
to
doing
this
manually.
How
do
I?
How
do
I
let
go
of
that
control?
And
that
is
that's
what
is
required
when
you
move
from
something
that's
imperative
to
something?
That's
declarative
and
that's
a
shift
that
we're
going
to
be
seeing
not
only
in
in
this
get
ops
movement
we're
going
to
begin
seeing
that
shift
in
many
places
the
more
we
can
define
an
end
state
and
then
just
manage
a
some
kind
of
declarative
script
to
define
that
state.
The
more.
A
D
D
Yeah,
there's
a
there's,
a
phrase
that
that
I
really
like.
I
think
that
describes
what
you
that
that
kind
of
captures
what
you
just
described
there
tracy,
which
is
that
git,
is
the
interface
to
operations
so
you're
right
people
used
to
use
clis
or
they
use
the
vsphere
console
or
they
use
the
aws
console.
Those
were
their
interfaces
to
operations
and
now
git
becomes
the
interface
to
operations
that
doesn't
mean
that
you're
not
going
to
have
some
continuous
delivery
tool.
D
B
This
is
actually
something
we've
talked
about,
even
in
terms
of
like.
If
I
built
a
tool
to
simplify
my
management,
you
know
I
wanted
to
be
able
to
use
a
ui.
What
should
that
ui
actually
do?
Well,
it
should
make
changes
and
get
or
make
a
pull
request
automatically,
or
something
like
that
for
you
like.
B
So
you
eliminate
a
lot
of
the
possibilities
where
problems
occur,
especially
downtime
can
occur
like
aws.
How
many
times
have
they
gone
down,
because
somebody
fat
finger
to
change?
You
know,
while
they're
connected
to
production
too
many
far
too
many
right,
but
you
can
get
rid
of
that
because
to
this
point,
git
is
the
interface
of
operations.
C
Yeah
and
automating
that
the
front
end
of
git
is,
I
think,
is
where
my
strongest
interest
in,
because
if,
when
we
do
that,
but
what
you
just
described,
then
we
are
really
tightening
up
the
process,
because
somebody
didn't
copy
the
wrong
shaw
right,
something
as
simple
as
that
is
where
the
weakness
is
and
the
more
we
can
automate
that
and
lock
it
down,
so
that
it
just
happens
for
you,
the
closer
we're
getting
to
a
a
really
clean
way
of
managing
our
deployments.
Regardless
of
what
environment
it's
going
to.
A
More
so,
let's
pretend
you're
a
company
just
hearing
about
all
this
for
the
first
time
somehow
and
you
want
to
get
started
with
it,
are
there
some
tips?
Are
there
incremental
approaches?
People
can
take
before
jumping
all
the
way
in?
Do
you
have
any
kind
of
advice
you
give
to
people
in
that
situation?
D
D
A
D
Pretty
darn
mature
at
this
point
we've
got
that
reconciling
automation,
that's
happening,
that
the
replica
set
controller,
the
the
deployment
controller
that
make
it
so
and
we've
got
declarative
configuration
that
expresses
what
you
want
running
there.
So
now
you
add
some
additional
reconciling
automation.
D
What
tracy
was
referring
to
is
the
get
ops
operator
and
I
was
saying:
well
it's
a
little.
It's
get
ops,
there's
more
than
one
operator,
but
you've
got
some
operators
that
handle
getting
it
from
git
into
kubernetes
and
then
kubernetes
already
has
these
reconciling
controllers.
These
convergent
controllers
that
actually
create
the
pods,
because
you
get
that
for
free,
the
declarative
and
the
reconciling
controllers
for
free
with
kubernetes.
D
That's
a
great
place
to
start
your
get
ops
journey
because
you
don't
have
to
bring
you
don't
have
to
build
that
convergent,
non-imperative
automation,
it's
already
there
and
then
you
can
leverage
something
like
flux,
which
is
a
cncf
project
that
weaverx
creates
or
argo
cd,
which
is
another
reconciling
kind
of
mechanism
for
bringing
things
from
git
into
kubernetes.
That's
also
in
the
cncf.
D
B
Yeah,
I
agree
the
the
starting
with
kubernetes
and
the
tools
that
were
mentioned.
Both
cncf
projects,
famously
flux
from
weave
works,
argo
cd,
which
is
something
that
code
fresh
works
quite
a
bit
on.
Those
are
those
are
really
perfect
for
kubernetes
and
kubernetes
is
ideal
for
it,
but
it's
worth
calling
out
too.
That
kubernetes
is
by
no
means
the
end
destination
of
get
ops.
B
C
C
Your
containerized
application
you're
going
to
find
out
that
breaking
up
is
really
hard
to
do,
and
you
need
to
have
a
strategy
for
doing
that
now
when
I'm
starting
to
see
some
mistakes,
because
we
work
a
lot
in
the
microservices
area.
It's
our
focus
is
that
we
are
seeing
a
lot
of
application-based
deployment
files
and
yaml
files.
C
They
don't
break
it
up
into
application.
The
each
microservice
have
having
its
own.
So
when
you
move
from
a
containerized
application
to
start
decomposing
your
applications,
you
really
have
to
sit
down,
get
on
the
whiteboard
and
start
looking
at
all
of
the
parts
and
pieces
that
have
to
be
touched.
You
know,
are
we
going
to
go
to
polyrepo
and
if
you
go
to
polyrepo
you're,
going
to
have
a
lot
more
places
that
you
have
to
check
in
those
yaml
files?
A
Cool
something
interesting,
I
think
a
couple
of
people
said
in
that
last
section
is
get
offs,
doesn't
stop
with
kubernetes.
What
are
some
of
the
strangest
places
you've
seen
it?
I
can
think
of
a
few
like
how
the
kubernetes
community
and
different
open
source
communities
are
using
git
ops
to
manage
calendars
now
or
like
you
can
change
the
meeting
invitations
in
a
git
repo
and
it
gets
reconciled
to
the
shared
calendar
everyone
has
and
it
it's
awesome
to
do
stuff.
That
way.
Have
you
seen
any
strange
or
fun
or
new
insightful
spots?
C
No,
but
we're
thinking
about
how
to
do
that
for
the
cd
pipelines
right
you
should
be
able
to.
You
know,
declare
what
you
want
in
your
pipeline
and
then
you're
going
to
have
events
and
sequences
you're
going
to
you're
not
going
to
have
a
pipeline
anymore,
you're,
going
to
have
a
sequence
right
and
the
events
will
determine
that,
and
you
could
declare
that
for
your
your
your
pipeline
check
it
in
to
get
and
your
pipeline
would
run
off
of
it
now.
That
would
be
really
cool.
I'm
hoping
that
we
see
that
sooner
than
later,.
D
D
That
I've
seen
are
the
thing
there,
a
lot
of
like
kind
of
policy
related
things,
so
it
could
be
the
groups
that
you've
defined
in
your
ldap
system
and
you're,
using
ldap
as
kind
of
your
central
place,
to
come
up
with
your
groups
and
who
has
which
roles
and
and
all
that
and
then
propagating
that
out
into
the
systems
that
then
apply
those
policies.
That's
something
that
I'm
starting
to
see
pretty
commonly
you
know
doing
things
around.
Opa
is
kind
of
a
more
general
like
get-offs
and
your
ego
rules.
D
B
But
one
of
the
one
of
the
funny
conversations
that
we
had
when
the
get
ops
working
group
was
started.
Is
somebody
came
in
and
was
like
hey?
Why
are
we
using
a
google
doc
like
we
should
be
using
git
for
taking
notes
and
stuff
and
we're
like?
Well,
maybe
we
will
someday,
but
it's
probably
okay-
for
us
to
do
a
little
bit
of
live
collaboration
in
a
tool.
That's
meant
for
it.
B
It's
not
quite
meant
for
that
in
that
same
way,
but
even
though
this
is
kubernetes,
I
think
this
is
a
really
interesting
use
case.
Leonardo
maria
gave
a
really
cool
presentation
a
while
ago
about
doing
air,
gapped
environments
and,
basically,
what
they
did
is
they
set
up.
Essentially
a
thumb
drive
that
had
a
get
repo
on
it
and
then
they
would
walk
up
and
they
plug
it
into
the
device,
and
it
would
go
through
the
reconciliation
loop
with
a
reconciler
that
was
on.
B
B
It
still
actually
simplifies
the
process
that
they
would
go
through,
because
before
that
you
know
if
they
wanted
to
update
dozens
or
thousands
of
nodes
and
people
had
to
walk
up,
they
would
have
like
a
handbook
of
instructions
that
everybody
needed
to
follow
and
if
you
don't
follow
it
exactly
or
you
run
into
some
issue
suddenly
now
you
have
divergence
across
all
these
nodes
and
you
have
to
have
really
super
skilled
technicians
to
deal
with
that
in
this
case
now
it's
it's
easier.
They
can
prepare
a
simple
thumb
drive.
B
A
I
can
just
imagine
how
much
easier
it
makes
debugging
later
when
you
just
have
to
check
what
version
your
aircraft
system
is
at
by
looking
at
the
git
commit,
and
instead
of
having
to
check
the
state
of
every
single
system
inside
of
there
cool.
That
was
a
good
transition.
I
guess,
because
you
started
to
mention
the
cncf
get
ops
sig.
The
special
interest
group
get
ups
is
evolving.
What
are
some
of
the
things
going
on
on
the
get
up
sig
and
how
is
it
helping
out?
Why
should
people
get
involved
there.
D
B
Github,
of
course,
launched
this
just
at
the
end
of
last
year,
and
the
goal
was
really
let's
put
together
standards
and
best
practices
and
principles
for
what
git
ops
is
and
how
to
do
it,
and
let's
make
something:
that's
inclusive
and
streamlined
and
simplified,
because
we've
seen
github
start
to
come
into
discussions
where
people
are
saying.
Well,
I'm
doing
get
ops,
no
you're
not
doing
get
offs.
This
is
get
ups,
that's
not
a
good
option.
B
You
know
and
there's
confusion
about
what
it
means,
and
so,
for
example,
one
of
the
things
that
many
people
don't
realize
is
that
git
ops,
the
principles
and
they're
not
completely
finished
yet
they're
actually
being
drafted
right
now
that
so
please
we
encourage
anybody.
Listening
come
get
involved
in
the
community.
There
are
dozens
of
people
working
on
this
from
all
kinds
of
different
companies.
B
That's
something
that
even
if
you've
been
doing
infrastructure
as
code
you're-
probably
not
doing
that
yet,
and
there
are
a
number
of
other
principles
in
there
that
are
being
worked
on-
that
are
incredibly
valuable
once
you
start
using
them
so
creating
this
standard,
making
it
easy
for
people
to
to
use
showing
which
tools
are
are
compliant
or
support.
That
standard
like
flux
like
argo
and
then
helping
vendors,
understand
hey
if
you
want
to
make
your
tool
get
ops
friendly.
These
are
the
principles
that
you're
gonna
need
to
follow
and
even
providing
a
pattern.
B
Different
patterns
and
community
contributor
patterns
that
people
can
look
at
to
see
hey
if
I'm
doing
aws
and
I
wanna
and
I
wanna-
deploy
serverless
infrastructure.
What's
what's
the
best
way
to
do
that,
having
things
that
people
can
contribute
and
view
that
way,
so,
there's
essentially
the
get
ops
working
group
which
is
under
the
sig
app
delivery
of
the
cncf
and
we're
working
on
a
standard
that
is
called
open,
getups,
which
is
going
to
be,
which
is
a
project
under
the
cmcf
and
cornelia.
D
D
There
are
certain
benefits
that
are
realized
only
if
you
do
things
in
a
certain
way,
and
so
we
don't
want
to
water
down,
get
offs
to
be
something
where
somebody
says.
Oh
well,
I'm
doing
get
offs,
but
wait
a
minute.
I
can't
do
recovery.
I
can't
do
disaster
recovery
in
the
in
the
story
that
I
told
you
at
the
very
beginning,
because
I
haven't,
I
haven't
protected
against
drift
detection
and
my
runtime
environment
doesn't
match
what's
in
git,
because
I
wasn't
constantly
reconciling.
I
had
didn't,
have
a
convergent
system.
D
Well,
then,
you're
not
doing
get
ups
you're
doing
get
plus
automation,
but
you're
not
doing
get
offs.
So
you
don't
realize
this
business
business
benefit
of
disaster
recovery,
and
so
that's
what
we're
aiming
to
do
with
the
get
ops
working
group,
and
these
principles
in
particular,
is
to
identify
the
essential
principles
that
yield
the
kind
of
results
that
we
want
to
deliver
with
these
practices.
A
C
Yeah
and
for
companies
like
deploy
hub,
we
need
to
see
those
we
need
to
understand
those
standards.
We
need
to
have
standard
protocols,
we
need
to
have
standard
integrations,
and
so
it
will
be
essential,
as
git
ops
is
embraced
by
more
companies
and
we
start
building
it
into
these
cd
pipelines
that
we
have
a
you
know
a
community.
We
can
go
to
and
say,
hey
can
we
can
we
solve
this
problem.