►
Description
OpenShift Commons Gathering 2022
Brief History of GitOps
Speaker: Cornelia Davis (Amazon)
Full Agenda:
https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_GitOps.html
Learn more at OpenShift Commons https://commons.openshift.org
A
Because
this
this
whole
world,
you
know
we
started
with
devops
and
devsecops
and
all
of
that
stuff.
And
then
this
crazy
thing
called
git
ops
appeared
on
the
horizon
and
it
was
you
know
the
new
cool
kid,
but
it's
actually
quite
an
interesting
history.
So
cornelia
tell
us
a
little
bit
about
how
you
got
involved
and
what
this
history
is.
B
B
Let
me
move
this
thing
and
for
those
of
you
who
don't
know
the
story
of
the
outage,
I'm
going
to
hold
you
in
suspense
for
just
a
little
bit
longer,
because
I'm
in
fact
not
going
to
start
with
the
story
of
the
outage,
because
in
order
to
really
understand
the
history
of
get
ops,
we
have
to
go
back
to
the
future.
We
have
to
back
up
in
time
a
little
bit
because
there
were
a
whole
bunch
of
things
that
came
that
that
kind
of
led
to
the
direction
of
where
we
ended
up
with
get
offs.
B
If
you
will,
there
was
a
whole
bunch
of
gestation
that
needed
to
happen
before
gitops
could
be
born.
Now.
Christian
already
alluded
to
some
of
those
things,
and
I
was
delighted
to
hear
that
there
was
this.
This
continuity
between
the
themes
that
he
talked
about
and
then
diane
just
now
talking
about
referencing
devops,
because
if
we
go
back
in
time,
that's
where
I
want
to
start
to
me.
That
was
the
the
initial
that
was
like
the
in
the
conception
of
get
offs
was
with
the
start
of
the
devops
movement.
B
B
For
those
of
you
who
don't
know
andrew
clay
shafer,
you
should,
he
is
largely
credited
with
coining
the
term
devops,
but
before
we
start
talking
about
well,
what
is
devops
and
I
know,
there's
a
whole
bunch
of
people
in
the
audience
who
are
like.
Oh
devops,
that's
like
that's
just
a
marketing
buzzword,
there's
no
reality
to
it.
What
I
want
to
do
is
remind
us
all
that
what
was
the
point
of
devops
and
the
point
of
devops
was
really
to
get
our
software
working
better
for
customers.
B
Let's
not
immediately
talk
about
the
benefit
to
us.
Let's
talk
about
what
the
end
goal
is
and
the
end
goal
is
to
serve
customers
well.
Well,
what
are
what
do
customers
need
from
software?
Well,
they
need
it
to
be
always
be
there.
They
need
it
to
be
safe,
so
secure
compliant.
All
of
those
things
don't
share
my
personal
information.
B
They
need
it
to
be
cost
effective,
so
they
might
be
willing
to
pay
a
subscription,
but
they're
not
willing
to
pay
thousands
of
dollars,
so
it
needs
to
be
cost
effective
and
they're
also
expecting
it
to
be
continually
improving.
So
when
we
do
find
a
gap
in
the
software,
how
do
we
quickly
address
that
gap?
B
Now,
keeping
that
in
mind
that
that's
the
goal
we
do
have
to
get
better,
there's
no
question
that
we
have
to
get
better
at
doing
software
and
that's
really
where
devops
was
born.
So,
even
though
we
may
have
you
know,
political
discussions
around
is
ci
devops
or
is,
if
you're
not
doing
culture
change?
Are
you
doing
devops?
I
don't
want
to
get
into
those.
Those
things
aren't
particularly
interesting
to
me
in
this
context.
B
They're
interesting
conversations,
but
in
this
context,
where
we're
talking
about
kind
of
the
genesis,
the
the
birth
of
gidops-
let's
not
worry
about
that,
so
the
reality
is
and
by
the
way
I
as
a
part
of
my
intro,
I
should
mention
that
I
have
been
in
I've.
Been
a
computer
scientist.
Technologist
I've
been
in
the
industry
for
30
years,
been
doing
web
architectures
for
20.,
been
in
this
kind
of
cloud
native
and
devops
space
for
about
10
years.
B
And
so,
if
we
started
with
the
developer,
what
we
did
was
we
said:
well,
let's
do
some
some
things
to
make
the
early
part
of
the
developer
life
cycle
better.
So
we
did
things
like
jenkins,
so
we
did
automation
that,
by
the
way
it
triggered
off
of
git
it'll
come
back
into
the
story
in
just
a
moment,
it'll
trigger
it
triggers
off
of
git,
but
then
it
automates
this
pipeline.
That
says
all
right.
B
When
we
make
a
code
change,
then
it
does
these
regular
steps
so
that
we're
not
depending
on
in
you
know,
fallible
humans
to
do
these
steps
consistently.
We
can
automate
that
and
then
I
had
a
really
cool
picture
on
here
too.
That
showed
a
little
trophy
from
from
google.
If
you
haven't
heard
of
google
testing
on
the
toilet,
you
should
look
that
up.
It's
pretty
cool.
There
was
a
whole
movement,
and
I
saw
mike
blank
do
a
keynote
at
the
devops
enterprise
summit.
B
That
was
how
I
got
introduced
to
testing
on
the
toilet,
but
what
they
recognized
at
google
and
some
of
us
may
think
that
google's
always
been
perfect
at
doing
software.
No,
they
had
to
learn.
They'd
learned
this
automation,
along
with
the
whole
rest
of
the
industry,
is
that
they
learned
about
the
importance
of
testing
and
test
automation
to
this
process,
of
delivering
more
value
to
customers
in
an
easier
and
more
cost
effective
way.
B
So
these
are
some
of
the
techniques
that
we
started,
so
we
started
early
and
started
serving
the
developer.
Now
I
want
to
emphasize
the
word
automation
because
automation,
test
automation,
dev
process,
automation,
is
really
important.
So,
like
I
said,
we
started
with
the
developer,
but
then
again
christian
mentioned
puppet
chef.
He
was
on
the
chef's
side
is
that
we
started
applying
this
type
of
automation
to
infrastructure
as
well,
and
the
pictures
that
I
have
here
show
these
nice
little
circular,
things
that
show
these
feedback
loops
like
we're,
constantly
we're
assessing
where
we're
at.
B
Sometimes
we
talk
about
the
ooda
loop,
we're
assessing
where
we're
at
and
we're
making
adjustments
and
all
as
much
of
that
cycle
is
automated
as
possible.
So
we
had
dev
process
automation,
we
had
infrastructure
automation
and
then,
of
course,
again
to
give
a
nod
to
what
christian
talked
about
earlier.
We
also
and
at
the
devops
enterprise
summit,
there's
lots
and
lots
of
sessions
on
changing
process
and
organizational
structures.
B
It
allowed
us
to
shift
from
that
model
where
we
have
these
siloed
organizations
and
we
kind
of
tilted
that
on
its
side
and
said
no,
what
we
want
to
do
is
we
want
to
have
balanced
teams
and
we
want
to
have,
for
example,
the
product
manager
who
might
might
come
from
the
marketing
group
working
alongside
the
developers
who
are
responsible
for
not
only
quality.
So
we
don't
have
a
separate
qa
group
that
we
have
to
schedule
with
to
get
quality
into
our
software.
B
So
we
have
these
balanced
teams,
and
now
we
can
layer
out
there's
the
notion
of
a
platform
which
handles
more
of
the
infrastructure,
concerns
and
security
and
compliance.
Remember
customers
need
that
and
then
we
have
these
empowered
teams
above
it
now.
I
mentioned
that
I
spent
time
on
cloud
foundry
cloud.
Foundry
was
a
platform
that
was
optimized
to
enable
these
individual
autonomous
teams
and
there's
other
obviously
other
platforms.
Here
we
are
talking
about
red
hat,
so
red
hat
has
platforms
as
well.
B
Now
I
keep
talking,
I
talked
a
little
bit
about
gestation
and
I'm
talking
about
these
number
of
things
that
started
to
come
together:
developer,
automation,
infrastructure,
automation,
organizational
changes,
some
platforms
that
supported
these
new
development
and
devops
structures
within
the
organization
and
another
thing,
of
course,
that
started
to
enable
some
of
the
rapid
iteration
some
of
the
security
and
those
types
of
things
was,
of
course
a
techno
thing.
It
was
the
emergence
and
the
ubiquity
of
containers.
B
So
there's
no
question
that
containers
were
an
enabler
of
some
of
the
things,
and
this
is
part
of
the
history
of
git
ops.
Remember
github,
says
it's
bacon
right
now,
it's
not!
It
hasn't
been
born
yet,
but
it's
baking
and
so,
of
course,
cloud
foundry
open
shift.
They
all
have
this
notion
of
containers,
but
then
something
happened
that
made
containers
completely
ubiquitous
and
that
is
kubernetes.
B
B
It
is
this
notion
of
declared
state
and
actual
state
desired
state
and
actual
state
that
existed
in
other
platforms
before
it
certainly
existed
in
cloud
foundry.
I
spent
many
many
years
talking
about
that
and
I
used
to
have
to
teach
enterprises
about
that
concept.
Since
kubernetes.
We
don't
have
to
teach
that
anymore.
Everybody
gets
this
notion
and
gets
the
value
they
can
see
what
happens
when
an
instance
dies
and
it
comes
back
automatically
because
kubernetes
is
a
convergent
system.
B
B
B
B
It
wasn't
a
problem,
and
some
of
you
may
have
heard
that
many
of
you
may
have
heard
this
story
so
I'll
keep
it
brief.
But
this
is
where
we've
works.
Who
are
the
the
originators
of
flux?
One
of
the
projects
that
you
heard
christian
talk
about.
They
at
the
time
were
not
a
git
ops
company,
they
were
a
kubernetes
company
and
they
were
providing
kubernetes
as
a
service
as
a
sas
service
and
they
had
an
outage.
B
B
Now
this
is
where
I
can
start
to
tell
you
a
little
bit
more.
This
wasn't
that
day
was
not
the
birth
of
get
offs.
Yet
perhaps
it
was
the
beginning
of
labor
if
I
keep
using
that
silly
awful
analogy,
but
maybe
it's
working,
because
what
they
had
done
was
they
had
set
up
their
system
so
that
it
was
all
around
this
declarative
configuration.
It
was
all
using
convergent
automation,
so
that
was
their
runtime
system
was
kubernetes,
convergent,
automation.
B
They
also
had
started
storing
because
it's
all
declarative
configuration
they
had
started,
storing
those
declared
configurations
in
git
and
git,
of
course,
there's
so
so
much
value,
and
so
I
should
have
included
that
in
my
list
of
all
the
things,
because
the
git
semantics
are
also
one
of
the
key
ingredients
to
the
whole.
Get
ups
movement
versioned
immutable
store
and
they
had
those
two
things.
B
B
B
Now
since
then,
I'm
going
to
this,
I
I
thought
that
was
a
super
fun
interesting
kind
of
review,
of
how
we
got
to
the
birth
of
get
ups
and
I'm
not
going
to
spend
as
much
time
talking
about
since
then,
because
we're
going
to
have
a
series
of
talks
throughout
the
day.
Christian
already
started,
alluding
to
those
and
I'm
going
to
come
back
to
another
comment
that
christian
made
just
a
moment
ago.
But
what
ended
up
happening,
of
course,
is
that
flux
was
created.
B
Argo
was
created,
additional
tools
started
getting
created
and
we
brought
those
into
the
cncf.
So
the
cncf
started
having
projects
that
were
tools
and
then
a
couple
of
years
ago.
We
realized
that
appropriate
application
of
those
tools
was
equally
important.
The
tools
alone
couldn't
stand,
couldn't
provide
the
value,
so
that
was
where
the
open
getups
project
was
created
and
the
get
ops
working
group
which
cares
for
the
open
gitops
project
and
that's
where
christian
mentioned
the
get-offs
principles.
B
So
this
was
an
industry
cons
group
that
came
up
with
the
these
ideas
of
the
principles,
which
include
things
like
convergent
automation,
and
they
also
include,
of
course,
using
git
as
the
interface
for
operations.
So
those
are
a
couple
of
the
principles
and
and
one
of
the
other
interesting
things-
that's
now
happening
we're
kind
of
at
the
stage
in
the
get
ops
journey
where
we
are
going
beyond
that
basic
understanding
of
gitops
and
the
basic
understanding
of
the
principles,
and
we
are
starting
to
really
understand
the
patterns.
B
Now,
in
closing,
I
want
to
bring
you
back,
and
some
of
you
have
seen
me
talk
to
this
slide
before,
and
this
slide
is
a
picture
of
jonathan
smart
at
the
time
he
was
at
barclays
and
he
is
presenting
at
the
devops
enterprise
summit.
So
I'm
bringing
this
all
the
way
back
to
devops
and
what
he
did
was
he
addressed
the
notion
that
we
started
with
the
developer
and
we
did
jenkins
and
we
did
test
automation
and
yeah.
B
We
even
started
doing
some
infrastructure
automation,
but
then
he
expands
the
slide
and
that's
a
teeny
tiny
part
of
the
slide,
and
he
expands
the
slide
to
the
left
and
says:
look
at
all
of
these
other
things
that
are
happening
not
on
the
cadence
that
our
customers
want.
Remember
one
of
the
customer
things
was.
We
want
to
be
able
to
frequently
update
this
well,
the
stuff
on
the
left
hand,
side,
which
is
yearly
budgets
and
and
long.
B
That's
the
domain
of
get
ops,
so
get
ops
really
handles
a
portion
of
the
entire
development
cycle.
It
almost
picks
up
right
when
development
is
working,
that's
working
really
well
and
takes
it
all
all
the
way
to
the
last
mile.
So
I
don't
know
about
you
diane.
Maybe
you
can
tell
me
whether
the
storyline
held
up
without
the
slides.
Maybe
it
was
even
better.
I
don't
know.
A
You
know
what
I
this
is
the
thing
I
think
we're
all
so
dependent
on
the
slides
in
our
in
our
universe,
almost
as
the
outline
for
our
talks,
but
that
was
wonderful
and
I
think
the
storyline
held
up
the
story
was
great
and
the
background
was
was
perfect.
So
thank
you
so
much
for
for
bearing
with
us
and
and
doing
that,
because
and
we
will
supply
the
slides,
so
people
can
see
andrew
and
josh
and
everybody
else
in
their
in
their
glory
on
your
slides
later
on.