►
From YouTube: Canonical GitOps - David Flanagan, Pulumi
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Canonical GitOps - David Flanagan, Pulumi
JW Grand Ballroom 4
Speakers: David Flanagan
Templating. Helm. Overlays. Bases. Directories. Branching. There's many ways to make your GitOps pipeline work across multiple environments, but they're all prone to complexity, environmental coupling, strange Git strategies, and at the end of the day all boil down to the same thing: Just-in-time rendering of YAML. What if we could actually define our application deployment once, without all the noise? In this session, David will introduce you to the concept of Canonical GitOps. A process that acknowledges the Law of Demeter, using environmental inference, and enabling branch based promotion of your application workflows. Let's take a look.,
A
A
A
I
spend
a
substantial
amount
of
my
limited
free
time
working
on
my
rockwood
academy,
which
is
a
youtube
channel
where
I
share
live
streams
that
feature
cloud
native
technologies.
One
of
my
most
popular
shows
is
something
called
clustered
where
I
always
say
it's.
The
worst
idea
ever
had
it.
100
is,
and
I
give
people
working
kubernetes
clusters
and
I
ask
them
to
break
it
in
48
hours
and
we
try
and
fix
them
live.
A
So
if
you
really
want
to
get
into
the
the
deep
bad
bits
of
kubernetes
api
server
in
cubelets,
then
it's
worth
checking
it
just
as
a
show
of
hands.
Has
anyone
seen
my
channel
before
all
right
cool
and
I'm
also
organizing
a
kubernetes
conference
and
my
home,
not
my
hometown,
my
home
country,
I'm
from
glasgow,
and
but
I
can't
bring
people
to
glasgow
because
I'd
have
to
give
you
a
map,
but
the
streets,
you
can't
walk
down,
but
edinburgh
is
nice
tourist
friendly.
A
So
if
you're
interested
in
a
small
community
kubernetes
conference,
we'd
love
to
have
you
now,
I
really
suck
at
naming
this
talk.
I've
been
trying
to
get
people
to
make
one
small
change
to
their
getups
pipelines
for
a
number
of
years
now.
My
first
version
of
this
talk
was
in
2019
at
get
up
con
or
get
upstairs
saturday,
and
I
called
it
applying
the
law
of
demeter
to
get
ops.
A
Anyone
heard
of
the
law
of
the
mirror,
all
right:
okay,
cool,
very
obscure
rule
for
building
maintainable
software
was
list
coupling,
but
of
course
it
means
nothing
to
nobody
that
hasn't
heard
of
it
before,
and
I
realized
on
my
flight
here
that
I've
also
given
another
really
shitty
name
and
called
it
canonical
get
ops
which
is
not
associated
with
ubuntu
or
canonical
in
any
way.
So
maybe
I
think
that
the
next
time
I
give
it
I'll
give
it
a
different
name,
I'm
just
not
sure
what
that
is.
A
Yet
what
I
want
to
start
with
is
just
kind
of
giving
you
a
quick
overview
of
the
law
of
demeter.
It's
a
really
good
set
of
rules
for
building
software,
and
when
we
apply
it
to
our
continuous
deployment
and
delivery
pipelines,
especially
get
ops.
I
think
it
unlocks
a
couple
of
really
cool
super
powers,
and
my
mission
today
is
just
to
try
and
get
you
to
make
this
one
small
change
to
your
githubs
pipelines.
A
The
main
message
and
takeaway
from
the
law
of
demeter
is
that
we
should
build
our
software
and
small
modules
or
components
that
don't
leak
too
much
information
out
to
other
pieces
of
our
other
modules.
But
then
your
infrastructure
or
your
your
software,
so
we're
really
trying
to
build
small
contained
bits
of
software
that
we
can
test
right.
This
is
what
we
all
want
from
our
software.
We
want
software
that
is
going
to
grow
and
be
maintainable
without
carrying
on
too
much
technical
debt.
A
Every
time
we
have
this
coupling
and
we
expose
those
members
and
our
interfaces
to
other
pieces
of
software,
those
become
part
of
the
contract
that
we
can
never
break.
So
we
really
want
to
make
sure
that
we
understand
the
law
of
demeter
as
far
as
software
goes
and,
more
importantly,
towards
get
ops.
A
A
But
githubs
did
make
a
big
difference
here,
because
we
inverted
the
control.
We
actually
removed
the
knowledge
of
our
environments
or
almost
removed
the
knowledge
of
our
environments
from
our
workflows,
because
our
job
now
is
just
to
build
an
image,
an
oci
effect
and
push
it
somewhere.
And
then
we
have
some
sort
of
chain
reaction
that
then
triggers
the
end
cluster
deployment.
A
So
what's
really
cool
here
is
we
still
have
our
traditional
kind
of
ci
and
delivery
method
and
then
inside
of
our
each
of
clusters,
each
each
of
our
environments.
We
can
notice
and
detect
these
changes
to
the
outside
environment
and
bring
them
in.
So
we
use
an
operator
and
it's
inside
of
our
environment.
So
I
really
like
the
separation
and
I'm
assuming
we're
all
here-
we're
probably
looking
at
get
ops
and
you're
probably
started
using
github.
So
hopefully
we're
all
on
the
right
track.
A
Now
a
question
that
has
been
going
around
the
gear
ops
community
for
a
number
of
years
now
as
well,
how
do
we
handle
multiple
environments
and
what
does
that
look
like
we?
I
mean
we
don't
all
just
ship
every
commit
to
prod.
I
mean
it'd
be
nice
if
we
did,
but
typically
we
want
performance
environments
or
qa.
We
want
to
make
sure
that
we
don't
break
things
too
quickly,
and
I
love
this
issue.
This
is
on
the
flux
repository.
A
This
is
2018
and
it's
one
of
the
flux
maintainers
from
wework,
saying,
hey.
We
should
actually
try
and
document
this,
and
this
issue
is
actually
got
a
number
of
thumbs
up
right,
56.,
it's
not
huge,
but
there's
interest
here.
People
want
to
know
how
do
I
do
multiple
environment,
getups
and
what's
really
interesting,
although
it's
not
visible
in
a
screenshot
here,
is
people
still
comment
on
this
issue,
even
though
fluxv1
isn't
really
a
thing
anymore?
So
there's
still
a
lot
of
confusion
concerning
questions
about
how
do
we
do
this
right?
A
So
what
do
I
mean
by
multiple
environments,
quick
image,
I'm
not
going
to
go
over
this
too
much,
but
you
know
we
don't
ship
to
prod
by
default
and
we
need
to
be
able
to
promote
and
progress
our
code,
at
least
in
some
environments.
You
know,
financial
regulations
are
much
stricter
start-ups.
You
maybe
could
just
go
straight
to
broad
now
back
to
this
issue.
A
A
Nothing
now
this
is.
I
have
spoken
to
the
square
male,
the
github
user.
Here
there
was
good
intentions.
There
are
other
branches
that
show
a
branching
model
for
multi-environment
get-ups,
but
at
first
sight
you
look
at
this
and
you're
like
oh.
We
don't
actually
good,
have
a
good
answer
here,
especially
from
the
people
that
essentially
coined
the
term
and
tried
to
promote,
get
ups
in
its
early
days.
A
So
what
are
our
options
when
it
comes
to
this?
I
only
see
three
in
the
wild
and
again
it
comes
down
to
the
type,
the
type
of
company
that
you
are
and
what
you're
shipping,
whether
you're
doing
you
know
microservices
and
kubernetes
or
not,
but
really
popular
one
is
the
directory
model
where
we
have
one
directory
that
describes
an
environment
and
we
have
some
concept
of
overlays
and
to
kind
of
augment
or
enrich
the
base
layer.
A
A
So,
with
the
repository
approach,
you
get
a
really
strong
authentication
boundary.
You
can
actually
restrict
access
to
the
entire
production
repository,
maybe
keep
it
to
automation
only
or
maybe
to
one
or
two
people
that
have
the
keys
to
the
kingdom
again.
This
is
banks
that
I
see
going
down
this
approach
where
they
really
need
to
have
strict
concerns,
but
the
challenge
with
the
repository
approach
is
drift,
especially
as
your
number
of
environments
grow
being
able
to
syndicate
and
replicate
all
of
these
changes
to
all
of
the
environments,
and
it's
really
painful.
A
To
be
honest,
it's
not
something.
I
would
encourage
anybody
to
try
unless
you're
forced
to
now
the
branching
model
I
like,
like.
We
can
promote
through
a
pull
request,
which
is
quite
nice,
assuming
we
apply
the
law
of
demeter
to
our
github's
pipelines,
but
it
can
be
difficult
to
automate
that
promotion.
A
Unless
you
know
it
depends
where
you
fall
on
that
line,
there
seems
to
be
people
that
are
okay
with
machines,
pushing
commits
to
the
repository,
and
then
there
are
people
who
are
just
never
going
to
have
a
machine
push
a
comment
to
the
repository
unless
there's
only
machines
that
push
come
out
to
their
brother
and
so
on.
So
it's
really
a
trade-off
and
personal
style
and
drift
still
can
be
an
issue
where
we
can
define
workflows
and
how
we
expect
things
to
be
promoted
from
branch
to
branch.
A
The
directory
approach
is
what
we're
all
stuck
with.
I
think
we
can
still
do
promotion
for
your
pull
request,
but
we
have
to
make
the
same
change
multiple
times.
If
the
environments
all
need
it-
or
I
guess
you
can
use
the
base
again,
it
depends
on
how
much
your
environments
deviate
and
that
comes
down
to
understanding
all
the
variants
within
your
your
pipeline.
A
Existing
tooling
already
does
this,
and
unfortunately,
with
the
director
reports,
you
don't
really
have
an
authentication
boundary
at
all.
Anybody
can
open
a
pull
request,
change
in
any
environment.
Now
we
can
do
things
like
restricting
pull
requests
to
have
certain
number
of
approvers
before
we
merge
it,
but
again
in
some
environments,
it's
not
a
strong
enough
or
strict
enough
authentication
boundary
so,
which
one
should
we
pick
well
looking
around,
I
only
see
directories.
A
Every
single
tool
out
there,
that
is
in
the
getup
space,
is
just
kind
of
defaulted
to
this
approach
and
customize
being,
I
think,
one
of
the
early
ones
that
promoted
this
but
helm
also.
Does
this
I
mean,
I
don't
know
how
often
you
go
to
github
and
search
for
helm,
dash,
staging.yaml
or
helm.production.com.
A
There
are
hundreds
of
thousands
of
people
adopting
that
pattern
and
using
a
different
values,
value
for
help
and
there's
a
cool
python
project
called
ket,
which
also
just
kind
of
defaults
to
this
approach.
So
all
the
github
schools
do
it.
I'm
assuming
most
of
the
people
in
this
room
also
properly
do
that,
and
hopefully
I
can
encourage
people
to
re-evaluate
that
decision.
A
A
So
I'm
not
a
big
fan
and,
let's
not
forget,
12-factor
manifesto
right.
This
is
why
we
have
containers
these
days.
This
is
why
you
know
the
heroku
team
came
out
with
all
these
great
rules
about
how
we
should
run
applications
right.
We
want
to
build
a
single
image
for
our
application
and
ship
it
to
all
environments,
but
then
we
have
all
of
this
environmental
knowledge
encoded
into
the
deployment
pipeline
like
how
did
we
take
that
step?
I'm
not
entirely
sure
so
for
building
one
image.
We
want
one
description
of.
A
A
So
what
if
we
could
have
a
shared
contract
with
them
that
we
need
the
environment
to
produce
a
certain
amount
of
information
for
our
application
to
be
able
to
run
and
the
environment
that
may
sound
familiar
as
part
of
the
12-factor
manifesto
right.
We
build
an
image
and
the
environment
produces
everything
that
you
need
to
run
that
application.
A
So
really,
the
only
change
you
need
to
make
to
kind
of
have
this
approach
to
your
pipeline
is
just
define
what
that
shared
contract
is
and
the
process
for
doing.
That
is
identifying
all
of
the
overlays
that
you
have
currently
and
having
a
list
of
invariants
and
variants
and
making
sure
that
the
contract
is
defined.
In
order
to
do
that.
A
Now,
when
you're
deploying
to
kubernetes
and
again
I'm
just
assuming
that
most
people
are
these
days,
the
things
that
need
the
shared
contract
are
ingress
right.
We
need
to
be
able
to
specify
the
urls
that
we're
going
to
make
available
to
each
application
and
from
the
platform
we
also
shouldn't
really
be
setting
replicas
on
our
deployments.
A
Obviously
secrets
can
be
a
bit
of
a
challenge,
so
you
need
to
build
that
into
your
contract
and
have
the
platform
provide
access
tokens
to
container
registries
to
databases
to
cloud
services
whatever
you
need,
of
course,
if
you're
very
lucky
and
you're
in
spiffy
inspire
land
amazing,
if
you
have
workload
identity
in
your
cloud
provider,
great
too
and
and
there's
more,
but
these
are
definitely
the
main
ones.
I
see
people
struggling
with
when
I
try
and
try
and
convince
them
or
show
them.
How
can
they
do
this
in
their
application?
A
So
what
I'm
going
to
show?
You
is
how
I
do
this
with
polymer.
Obviously,
I
work
for
polymer,
but
there's
a
couple
of
really
cool
things
you
can
do
here,
because
polymer
is
code
and
it
runs
inside
of
my
cluster.
However,
I
have
built
proof
of
concepts
that
use
cavernous.
Mutating
admission
controllers
to
augment
resources
as
they're
going
into
the
cluster
and
prefix
in
domains
within
an
ingress
is
all
quite
easy.
A
Swapping
momentum
max
values,
however,
you're
going
to
have
a
certain
level
of
frustration
with
the
caverno
approach,
and
then
it
may
be
that,
if
you're
not
using
the
lumia
inside
of
your
cluster,
that
just
writing
an
operator
that
the
platform
team
provides
that
handles
the
augmentation
to
your
manifest
as
they
hit.
The
cluster
will
also
work
just
as
well.
A
All
right,
so
that
is
my
application
and
here's
my
platform,
so
I
have
two
very
distinct
sets
of
responsibilities.
I
have
my
platform
team
that
provides
what
I
think
is
a
nice
interface,
mainly
because
I
built
it,
but
the
platform
is
a
a
class
or
a
function
returns
an
object
that
has
methods
it
can
be
called
on
it.
A
A
A
A
So
I
have
this
rocket
academy,
and
inside
of
that
there
is
the
platform
directory,
which
is
the
application
side
of
the
platform.
I
need
to
tell
it
which
ingress
controller
I'm
using
and
then
this
environment
is
actually
my
contract.
This
is
a
really
simple
use
case
and
the
only
thing
I
don't
need
to
scale.
My
api
is
just
for
personal
use,
but
I
do
need
to
make
it
available
on
a
url
or
a
domain.
So
when
I
do
deploy
another
environment,
I
can
actually
just
swap
out
the
domain.
A
I
need
what's
actually
a
much
better
approach
is
to
randomize
it
as
much
as
possible
as
well.
So
you
can
have
ephemeral
environments
and
then
just
have
something
push
get
upcoming,
but
let's
slightly
deeper
down
a
rabbit
hole.
So
that's
the
platform,
that's
what
your
platform
engineers
will
do
you
as
a
developer.
Working
on
microservices
can
go
to
the
platform
and
say
I
want
to
onboard
my
project
and
you
specify
the
contract
that
you
need.
A
A
A
I
then
pull
out
the
contract
now
in
kubernetes,
it's
just
a
conflict
map.
Of
course,
if
I
wanted
it
be
a
secret,
I
can
make
it
a
secret.
It
depends
what
I'm
stuffing
into
it,
but
then
I
have
this
variable
called
cm
where
I
can
access
all
those
fields
that
I
expect
to
be
there
now
I
have
got
a
type
here.
I
should
probably
make
this
shadeable
between
the
platform
side
and
the
application
side.
A
But
again
it's
my
own
infrastructure,
definitely
room
for
improvement,
and
but
I
have
my
api
domain
and
there's
a
few
other
things
that
I
could
be
tweaking.
If
I
wanted
from
there,
this
is
just
me
deserializing
that
json
blob
that
we
get
from
the
config
map
back
into
a
type
script
type,
so
that
I
can
reference
the
values.
A
I
create
a
service
again,
I'm
using
nice
helper
methods
here
to
kind
of
not
have
to
duplicate
and
write
the
same
old
ammo
every
single
time,
and
then
I
have
my
ingress
object
and
the
metadata
and
the
fqdn
are
pulling
from
that
shared
contract
that
we
have
besides
two
teams-
and
that's
it-
the
operator
runs
this
polymer
program,
my
application.
The
deployment
logic
is
all
defined
once
next
to
the
code.
That
is
running
itself
and
things
are
quite
cool.
A
Let's
jump
back
over
here,
so
you
can
do
it
with
cavarno.
You
could
write
your
own
controller,
I'm
just
obviously
slightly
biased
towards
the.
Let
me
approach,
there's
some
quick
tips.
If
you're
going
to
do
this
really
extracting
the
variance
and
variance
is
the
most
important
thing
here:
understanding
what
changes
between
each
environment
and
having
that
shared
contract
is
critical,
randomize
as
much
as
possible.
A
So
now,
if
I
were
to
say
which
one
or
approach
would
we
go,
I
would
encourage
you
all
to
look
at
the
branching
model.
Being
able
to
promote
via
pull
request
is
really
cool
and
you
have
branch
level
protections
on
how
we
can
merge
stuff,
there's
no
overlays
and
in
thermal
environments,
which
are
really
important.
A
A
A
Yeah,
I've
never
really
bought
into
that
exactly
redeployable
thing
I
mean
you
could
still
do
that.
What
I'm
experimenting
with
right
now
is
whenever
I
do
a
deployment
with
pollution,
it's
actually
to
create
an
oci
artifact
of
predator
registry
to
see
that
these
were
the
contract
values
and
all
the
containers
that
were
deployed
et
cetera,
so
that
I
still
have
a
bill
of
materials
which
is
good
for
auditing
and
security.
A
But
for
me,
what's
the
most
important
part
about
github.
Is
that
constant
reconciliation
and
inverting
the
control
that
is
in
the
cluster?
You
know
I'm
not
leaking
that
environment
information
to
build
systems
or
workflows,
etc.
So
I
mean
I
like
that
approach
first
and
then
I'll
work
on
the
audit
and
security
site,
but
yeah
there
are
a
lot
of
people
that
are
like
well,
I
should
have
a
machine
commit
all
the
image,
shares,
etc.