►
From YouTube: What Happened To Observability In GitOps?
Description
Speaker: Dan Garfield from Codefresh
With the increase in popularity of GitOps, we are getting more and more tools that are focused on specific aspects of it. As we move towards Git being the only source of truth, and employing different tools to converge the actual state into whatever our desires are, we face observability challenges.
How can we gain insights into the desired and the actual state, and connect those with all the other transient information that led to those states? How can we combine all the information we have into a single source of truth beyond the desired state and the actual state? Can we gain visibility that will guide us towards better insight into the outcomes of GitOps processes and allow us to have all the information we need to make future decisions?
Let's see whether we can answer those and a few other questions. If we can, we might have a better understanding of where GitOps is and where it is going.
A
B
So
thanks
everybody
for
joining,
excited
to
chat
with
you
and
and
go
through
and
talk
about,
observability
and
get
ops.
I
see
we
got
a
couple
of
stalwarts
here.
Tracy's
on
the
line,
hey
tracy
good,
to
see
you
we're
gonna,
be
talking
about
observability
and
get
ops.
Get
upset,
of
course,
is
a
common
topic
and
we're
going
to
go
a
little
bit
through
the
history.
But
I
guess
before
we
do
that,
I
should
introduce
myself.
B
My
name
is
dan
garfield,
I'm
the
chief
technology
evangelist
for
a
company
called
code
fresh,
the
devops
automation
platform
you
can
follow
me
on
twitter
at
today
was
awesome,
and
I
am
a
member
of
the
forbes
technology
council,
as
well
as
a
google
developer
expert
focused
on
cloud
and
kubernetes
and
all
things
cloud
native.
So
I'm
a
big
fan
of
that
platform
and
have
a
lot
of
fun
with
it.
The
topic
today
is
again
git,
ops
and
observability,
and
so
before
we
go
there.
B
I
want
to
kind
of
contextualize
this
a
little
bit
and
I
think
it'll
make
sense
this
way.
So
I'm
gonna
want
to
talk
first
about
what
I
call
the
before
times.
This
is
in
the
days
of
yesteryear
when,
when
deploying
software
was
a
simpler
exercise,
perhaps
or
rather
more
complicated,
it
was
characterized
by
monolithic
handoffs.
B
You
had
a
monolithic
application,
typically
architecture
deployments
were
very
manual
and
they
were
very
periodic
right.
So
you
had
these
releases
that
were
every
couple
of
months.
You'd
have
kind
of
all
hands
on
deck,
you'd
release
software-
I
don't
know.
If
any
of
you,
I
don't
know
how
how
old
the
audience
is.
If
you
remember
deploying
software
this
way,
I
remember
zipping
up
my
my
code
and
sending
it
over
to
my
operations
person
to
implement,
and
we
would
do
that
every
couple
of
weeks,
so
this
process
is
very
personal.
B
It
required
a
lot
of
hands-on
attention.
The
risks
were
were
very
high
because
you
were
typically
delivering
a
lot
of
changes
all
at
once.
The
changes
were
very
manual
and,
of
course,
the
art
you
could
afford
that,
because
the
architecture
was
monolithic.
You
didn't
have
tons
of
services.
You
had
to
update
you
had
to
update
a
few
services,
you
know
so
that
made
it
simpler
to
do
in
the
sense
that
you
could
afford
to
do
it
manually
now,
whether
or
not
you
could
actually
afford
to
do
it.
B
Manually
is
another
question
because
of
course,
any
manual
process
typically
leads
to
downtime.
It's
not
very
repeatable,
so
this
wasn't
a
great
situation
to
be
in
so
over
the
last
few
years,
obviously,
there's
been
a
transition.
We've
moved
from
monolithic
architectures
to
microservice
architectures.
This
allows
us
to
scale
our
development
processes
scale.
Our
services
independent
of
one
another
been
a
really
fantastic
change,
and
that
means
that
to
support
that
we
need
to
get
rid
of
those
manual
deployments
and
do
more
automated
deployments
more
gradual
deployments.
B
Things
like
canary
releases,
things
like
using
feature
flags
and
instead
of
managing
you
know
lots
of
bare
metal
servers.
We
can
take
advantage
of
kubernetes
and
we
can.
We
can
essentially
declare
what
we
want
as
code
and
rock
and
roll
with
it,
and
we're
good
to
go
just
a
reminder:
keep
feel
free
to
throw
q
a
in
there
I'll
be
watching
the
chat
and
I'll
try
to
address
it
live.
I
I
like
having
the
interaction.
So
let's
do
it.
B
That's
fine,
because
how
many
people
could
be
deploying
at
a
time
you
did
it
once
every
two
weeks
you
already
know
who
and
even
as
you
started
to
get
just
a
couple
of
microservices.
Maybe
this
was
okay,
but
what
you'll
notice
is
that,
because
we
are
using
microservices,
we
have
way
more
applications
and
identifying
the
failure.
Points
isn't
always
easy.
You
might
have
one
application.
That
starts
throwing
a
lot
of
errors,
but
it's
actually
because
of
a
regression
in
another
microservice.
B
B
Oh
gosh,
quite
a
few
people
just
deployed
recently
and
you
start
to
investigate
the
issue
and
more
people
turns
out
just
deployed
and
now
you're
getting
more
answers
and
now
you're
getting
more
answers
because
it
turns
out
lots
of
people
are
deploying
you've
got
5,
000
microservices,
shouting
on
slack
that
something
is
broken,
isn't
scaling
very
well.
We've
now
become
completely
overwhelmed,
just
trying
to
manage
the
responses
to
the
problems
and
they're
piling
up,
because
there's
a
service
outage
and
everyone's
freaking
out
and
the
messages
are
flying
fast
and
furious
all
over
the
place.
B
I
once
had
this
this
experience.
We
have
at
code
fresh,
we
have
a
lot
of
our
engineers
are
out
of
israel.
I
don't
know
if
you'll
think
this
is
a
funny
story
or
not,
but
we
have
a
lot
of
engineers
out
of
israel
and
a
few
years
ago
we
had
an
outage
and
they
started
a
zoom
war
room
and
everybody
logged
in,
and
I
said
I
was
sitting
next
to
my
ceo,
who's
israeli
and
I
said
gosh.
B
It
must
be
really
bad
because
they're
they're
only
speaking
hebrew,
they
won't
speak
any
english
and
he
said
dan,
it's
much
worse
than
you
know,
they're
speaking
russian.
So
that's
that's
not
a
scalable
process
right,
so
I
don't
know
if
you
think
that
was
funny
or
not,
but
but
that
always
makes
me
laugh.
So
this
isn't
really
fine.
This
isn't
a
great
way
to
decode.
B
B
So
last
week
it
was
announced
the
gitops
working
group,
which
consists
of
aws
code,
fresh
weave,
works,
azure
and
github
to
start
and
we've
received
a
lot
of
interest
in
discussion
from
other
companies,
and
the
working
group
is
formed
underneath
the
umbrella
of
the
cncf
and
we've
come
out
with.
We've
started
with
the
definition
and
I've
I've
been
part
of
this.
So
I'm
happy
to
have
discussion
about
the
get
offs
working
group
and
talk
to
folks
about
that.
B
But
what
we've
done
is
we've
put
together
a
formal
definition
for
get
ops
and
get
ops
has
actually
been
a
term.
That's
been
used,
it's
been
floated
around
for
the
last
few
years.
It
was
coined
by
alex
over
at
weaveworks
who's,
really
sharp
and
was
kind
of
leading
the
way
on
this,
and
it's
meant
different
things
to
different
people.
Some
people
feel
like
it's.
Well,
it's
just
infrastructure
as
a
code
kind
of
renamed.
It's
really
just
about
application
management.
It's
really
just
about
kubernetes.
It's
all.
B
These
things
have
floated
around,
and
people
have
talked
about
different
patterns
and
things.
So
our
goal
in
the
get
ops
working
group
is
really
to
define
not
only
the
best
practices
but
some
of
the
strategies
and
kind
of
formal
conformance
at
some
point
of
what
it
means
to
be
doing,
git,
ops
and
and
how
what
we
can
actually
measure
in
an
objective
way.
So
it's
not
just
people's
opinions.
It's
it's
something!
The
community
comes
together
and
agrees
upon
as
where
we
want
to
go
so
the
there
are
five
features.
B
You
need
to
use
some
kind
of
version
controlled
immutable
storage-
usually
that's
git,
but
technically
in
order
to
do
git
ops,
you
don't
necessarily
need
git,
it
could
be,
you
know
perforce
or
s
or
or
whatever
some
of
those
other
older
version
control
systems.
You
need
automated
delivery
of
of
of
code.
You
need
to
be
able
to
deploy
in
an
automated
way.
B
You
need
software
agents
that
are
actually
executing
those
deployments
that
are
pulling
the
changes,
not
pushing
them
and
it
needs
to
be
a
closed
loop,
so
it
needs
to
be
be
able
to
kind
of
self-sustain.
You
can
read
more
detail
on
those
configuration
at
the
links
below
I'll.
Throw
these
in
the
chat.
Oh
wait!
No!
I
won't
throw
these
in
the
chat
because
it'll
all
have
to
drop
out
of
my
deck
I'll,
throw
them
in
the
chat
later.
You
can
also
just
google
them.
B
So
if
you
think
about
it
in
its
simplest
term,
git
ops
is
basically
saying
I
want
to
be
able
to
define
my
application
in
source
code
in
source
conversion
control
and
my
run
time
should
come
to
reflect
that
and
that's
the
simplest.
Oh
yeah.
Taran
got
it
posted
to
the
plant
panelist
I'll
copy
and
paste
the
link
here.
Oh
yeah,
she
got
it.
Thank
you
karen.
So
that's
the
simplest
way
of
thinking
about
it,
but
we
need
to
actually
have
a
little
bit
more
around
it
to
be
within
that.
B
First
of
all,
we
need
an
operator.
We
need
something
that's
actually
sitting
in
the
runtime
environment
that
can
actually
pull
changes
onto
it.
So
it's
looking
at
the
version
control
it's
pulling
the
changes,
it's
applying
them
and
it's
reconciling
so
you
can
think
of
it
like
a
system
of
reconciliation
to
get
where
you
want
to
go
now.
B
You
actually
need
something,
usually
a
little
bit
more
than
that.
Now.
This
isn't
necessarily
a
conformance
question,
but
this
is
a
this
is
a
pattern
that
is
the
most
common.
It's
the
one
that
I
recommend
you
actually
have
an
application
code,
repo
where
you've
defined
your
application,
you're
making
changes
to
that
and
as
changes
are
made
to
that,
there's
an
automated
test
process
that
fires
off
in
in
your
automation,
platform
of
choice,
and
once
that
occurs,
you
can
actually
have
an
automated
way
of
generating
manifests
that
then
are
deployed
into
a
runtime
repo.
B
So
you
actually
have
two
get
repos
one
for
your
application,
one
for
your
your
runtime
definition,
your
manifest
and
things
like
that,
and
this
is
then
what
you
use
it
that
the
operator
actually
goes
off
of
to
actually
deploy
into
the
cluster
now
tracy's
bringing
up
a
question.
I
think
this
is
a
good
one
and
and
we'll
we'll
stop
here
for
just
a
second
to
go
through
that
tracy
asks.
Why
does
git
ops
need
an
agent-based
delivery?
Isn't
agentless
a
better
way
to
go?
Could
it
not
be
an
agentless
delivery
method?
B
That's
actually
a
great
question,
and
and
if
we
go
to
the
conformance,
which
does
say
that
there
need
to
be
software
agents,
the
longer
definition
around
that
and
I'll
pull
it
up
here.
Really
quick.
Just
so
just
so
that
I
think
it's
want
to
make
it
super
clear
all
right.
Let
me
pull
this
guy
up
so
here
in
the
in
the
conformance
blog
post
announcement
blog
post
when
we
talk
about
software
agents.
Basically
we're
talking
about
reconcilers
that
maintain
system
state
and
apply
resources
described
in
the
declarative
configuration
now
technically.
B
B
So
that's
a
great
question
and
it
doesn't
necessarily
have
to
live
on
the
cluster,
but
basically
it's
really
the
description
that
there
is
a
role
which
is
your
reconciler.
Oh,
why
does
this
just
have
weaveworks
on?
It
should
have
all
of
them
anyway.
Okay,
so
we've
got
our
process
right
for
get
offs
essentially
baked
here,
and
this
is
the
common
pattern
that
we
see
today.
This
is
this
is
the
one
that
is
the
most
common
most
used.
B
Automated
manifest
generation
is
a
little
bit
less
common,
it's
kind
of
a
little
bit
more
advanced.
This
is
what
we
do
internally
at
code
fresh.
This
is
how
we
do
it
is.
We
generate
all
of
our
manifests
and
then
check
them
into
a
separate
repo
and
basically
no
one's
making
manual
changes,
and
why
don't
you
want
make
people
making
manual
changes
because
they
typically
cause
problems?
B
So
you
don't
want
you
don't
want
those
things
manually
happen.
You
want
them
all
to
go
through
version
control.
Of
course,
what
I
just
described
means
that
you
were
not
using
git
ops,
because
if
you
were
using
git
ops,
that
change
would
have
been
checked
in
would
have
been
tested
in
some
automated
fashion
and
would
have
been
caught
before
it
went
and
wreaked
havoc
and
caused
down
time
for
many
hours,
but
the
time
that
you
go
through
the
outage.
B
B
So
what
I
actually
have
looks
a
little
bit
more
like
this,
except
we'd
have
to
zoom
out
four
or
five
more
times.
So
now
you
can
see
where
the
problem
starts
to
come.
In
immediately,
if
something
goes
wrong,
how
do
I
identify
where
the
problem
lies?
I
have
a
multitude
of
services.
They
rely
on
upon
each
other
in
complex
ways.
Failures
in
one
service,
don't
necessarily
dictate
the
where
the
problem
is
because
it
could
be
coming
from
another
service
that
that
service
relies
upon
now.
B
Why?
Why
can't
you
deploy
on
friday
afternoon?
Because
everyone
is
worried
that
they
might
lose
their
weekend,
that
something
could
go
wrong?
They'll
get
paged
and
you'll
have
issues,
and
so
I
think
you
know
that
may
be
the
reality
of
your
organization
today,
but
I
think
that
if
we
aren't
confident
enough
confident
enough
in
our
deployment
process
that
we
don't
believe
that
we
can
deploy
on
a
friday
afternoon
at
4
45
p.m
and
have
full
confidence
that
the
process
is
going
to
work.
B
B
It's
knowing
that
this
process
is
not
a
black
box
and
that
you
can
get
lost
in
so
I
might
be
looking
at
this
complex,
microservice
stack
and
suddenly
I
see
a
slack
message
come
up
that
says
something
is
broken.
Who
just
deployed
now
we
saw
where
that
leads
right.
All
of
a
sudden,
an
explosion
of
people.
Oh,
I
deployed,
I
deployed
I
deployed
and
you're
trying
to
track
down.
What's
going
on,
so
how
do
you
actually
identify
regressions
and
where
they
came
from
right,
so
you
you've
identified
that
a
regression
is
happening.
B
There's
some
kind
of
degradation,
you've,
gotten
alerts,
you've
got
monitoring,
set
up
or
whatever.
So
how
do
you
actually
identify
how
to
fix
it?
There's
a
couple
things
we
need
to
know
to
help
us
narrow
it
down.
First
of
all,
we
want
to
be
able
to
identify
when
the
regression
started,
because
this
is
going
to
give
us
a
baseline
of
where
we're
going
to
look
for
potential
changes
that
have
caused
this
regression.
B
When
did
changes
to
our
application
to
our
system
take
place,
what
exactly
was
changed?
What
issues
were
being
addressed?
Who
worked
on
it?
All
of
those
things
will
help
you
narrow
down
very
rapidly.
What's
going
on
now,
your
system
excuse
me,
will
probably
allow
you
to
do
rollbacks
and
we
definitely
recommend
that
and
usually
get
driven.
Rollbacks
are
a
deal,
but
you
may
have
a
regression
that
started
again.
B
B
So
do
you
even
know
which
service
needs
to
be
rolled
back
and
if
you
do
a
rollback,
what
will
happen
if
someone
pushes
additional
changes?
Will
those
have
the
problems
that
cause
the
regression
again?
So
you
can
see
how
you
know,
as
you
scale
this
thing
up
yeah.
I
can
understand
why
some
people
might
not
want
to
deploy
on
a
friday
afternoon,
because
answering
those
questions
feels
difficult.
B
So,
let's
get
in.
Let's
leave
the
theory
behind
for
a
minute
and
let's,
let's
go
back
and
actually
look
at
a
practical
example,
and
what
I'm
going
to
do
is
I'm
going
to
pull
up
an
app,
an
application
that
I'm
managing
now
this
one's
a
fairly
simple?
This
doesn't
have
the
two-step
kind
of
system
that
I've
described,
but
this
is
a
repo
that
I
use
to
manage
my
atomic
cluster,
which
is
a
kubernetes
cluster
that
I
have
sitting
on
my
desk
that
I
built
out
of
atomic
pies.
B
B
B
B
Oh,
it's
good
to
commit
in
front
of
people.
It
reminds
you
to
do
things
correctly.
All
right,
git
has
been
committed,
so
I'm
going
to
get
and
push
origin,
and
this
will
fire
off
my
change
right
and
if
we
look
now
at
argo,
argo
will
pick
up
this
change
automatically
within.
I
think
it's
set
to
change,
check
every
60
seconds
or
something
I'm
just
going
to
tell
it
to
refresh
just
so.
We
don't
have
to
wait.
B
So
you
can
see
it's
act
now
out
of
sync
and
it's
now
syncing
and
this
is
progressing,
so
we
can
actually
see
it's
spinning
up
the
new
pods
and
rocking
and
rolling
those
things,
and
so
so,
once
this
one
is
started,
this
one
will
go
away
right.
Oh
actually,
this
one,
this
one
is
going
away,
yeah,
so,
okay,
so
now
we've
completed
an
update
right
to
the
cluster,
so
it
went
pretty
fast.
B
So
you
can
see
how
the
mechanisms
of
this
work-
and,
if
I
were
using
this,
I
can
actually
use
this
inside
of
code
fresh
as
well,
because
I
normally
you
know,
would
have
a
ci
process
we're
not
going
to
get
into
the
ci
process
elements
here.
But
if
I
go
over
to
my
git
ops,
dashboard
and
code
fresh,
you
can
see
that
the
netboot
xyz
is
synced,
and
so
it's
actually
showing
me
a
similar
amount
of
information.
B
B
So
this
gives
me
time
right,
which
is
which
is
one
useful
metric,
but
let
me
show
you
a
different
example
of
how
we
solve
this
problem
because
remember
that
I
said
that
there
are
a
number
of
things
that
I
want
to
know.
I
want
to
know
what
changes
occurred.
What
were
the
commits?
What
were
the
issues?
So
I'm
going
to
show
you
how
we
actually
tackle
this
internally
to
get
the
visibility
that
we're
looking
for.
B
So
here
you
can
see
I'm
actually
in
the
code
fresh
platform
and
it
looks
like
there's
currently
a
release
happening
on
our
production.
So
let's
pull
up
production
and
see.
What's
going
on
now,
let's
say
that
I
had
I
had
identified
an
issue
that
occurred
at
you
know,
10
o'clock
this
morning
I
can
actually
narrow
down
and
see
exactly
when
my
deployments
have
all
occurred,
and
so
here's
my
10
o'clock
range-
and
I
can
jump
straight
to
that
one
and
I
could
find
out
what
was
going
on
with
this.
B
So
this
was
about
two
hours
ago.
I
can
see
that
it
was
dennis
co
code
fresh
that
worked
on.
This
didn't
have
a
jira
issue,
but
it
did
have
a
pull
request,
so
I
could
jump
over
to
that
pull
request
and
try
to
and
see
what
actually
changed
and
see
if
that
actually
fit
the
profile
of
the
issue
that
I'm
having.
B
B
B
B
So
this
makes
it
I'm
not
going
into
slack
anymore
and
that's
a
real
use
case.
I'm
not
going
into
slack
and
shouting
hey.
What's
changed
who's
been
doing
stuff,
I
can
actually
just
go
straight
to
my
dashboard
and
see
not
only
the
status
of
production.
I
can
see
it's
all
healthy
everything's
running
properly,
but
I
can
also
see
and
narrow
down
the
entire
history.
So
it's
not
just
about
what
is
currently
running
because,
as
you
can
see
we're
making
changes.
Quite
often
we
had
a
change.
B
An
hour
ago,
we
had
one
two
hours
ago,
three
hours
ago,
five
hours
ago
six
hours
ago.
I
could
issue
a
rollback
right
from
here
and
get
get
to
a
working
version
if
something
had
gone
wrong
and
addressed
that
very
easily
right,
and
so
you
can
see
how
this
this
works.
I
can
see
all
the
different
committers
I
can
see
what
they're
doing
this
gives
you
a
lot
of
confidence
in
your
process,
because
you
can
see
what's
actually
going
on
and
drill
down
into
that.
B
B
So
what
we
do
is
we
create
a
single
pipeline,
and
I
can
show
you
this
here.
If
I
go
to
the
cd
pipeline
here,
what
you'll
see
is
we've
actually
defined
a
pipeline
that
triggers
the
update
of
all
of
the
elements
that
are
going
to
go
into
a
sink,
and
this
is
a
shared
pipeline
now.
What
does
that
mean?
Well,
the
old
way
of
doing
this
is
you
have
one
application,
one
repo
one
pipeline
and
that
works
great.
B
When
you
have
a
couple
of
applications
or
a
dozen
applications,
when
you
have
five
thousand
now,
all
of
a
sudden,
you
have
to
maintain
5000
pipelines
and
if
you
want
to
add
a
security
step,
this
is
something
we
actually
did
in
the
last
two
last
week
and
a
half.
Is
we
actually
added
some
additional
security
policy
scanning
to
our
pipelines?
B
B
This
is
actually
operating
off
of
a
single
repo,
the
cf
helm,
repo,
that
stores
different
helm,
charts
that
are
meant
to
be
deployed
into
production,
and
so
the
cd
pipeline,
as
a
pull
request,
is
opened.
This
will
actually
go
and
test
and
validate
that
the
change,
that's
what
that
is
being
pushed,
is
going
to
work
properly
and
then
it
actually,
even
as
a
step
triggers
the
argo
sync
as
part
of
the
pipeline
and
then
can
do
a
roll
back
if
it
needs
to
or
those
kinds
of
things.
B
So
in
this
case,
it's
actually
not
even
it's
not
using
the
automated
sync
feature
of
our
deployment
agent,
but
it
is
being
triggered
instead
by
this
automation,
which
allows
us
to
build
some
additional
logic
and
barriers
and
things
around
it,
and
this
is
on
the
cd
side
and
if
we
go
back
over
to
the
ci,
this
is
another
shared
pipeline.
So
you
can
see
this
one
also
has
dozens
of
microservices
associated
with
it
all
from
different
repositories.
B
B
So
you
can
see
it
adds
a
pull
request
on
and
sends
the
helm
package
onto
that
repo
and
a
pull
request,
which
then
is
tackled
using
my
cd
pipeline
and
then
of
course,
deployed
in
an
automated
fashion
to
to
my
production
cluster
so
definitely
recommend
that
and
the
nice,
the
other
nice
thing
about
that
is
that
in
your
git
ops
element,
of
course,
that
means
I
can
actually
represent
all
of
these
services
with
very
little.
You
know
configuration
overhead
because
it's
not
it's
not
just
about
the
pipelines.
B
So,
let's
go
into
the
questions.
This
is
what
I
wanted
to
share
with
you
today
is
a
pathway
towards
observability
and
doing
that
is
really
about
gathering
all
of
the
information
into
one
easily
searchable
place,
and
this
is
what
we've
been
working
on
internally.
You're
welcome
to
check
it
out
at
codefresh.io.
B
But
let's
go
into
these
questions
here
about
git
ups
and
we
can
have
any
questions
about
git
ops
in
general,
johannes
asks,
possibly
a
question
for
the
end
of
the
talk.
Are
people
using
get
ops
mechanisms
outside
of
the
kubernetes
world?
That's
a
great
question.
Yes,
I
I
am
seeing
this
in
some
places.
You'll
see
people
doing
it
purely
with
infrastructure.
Right
so
they'll
be
doing
you
know
terraform
or
those
kinds
of
things
to
try
to
accomplish
good
ops.
I
like
to
think
of
git
ops
as
sort
of
an
adoption
curve.
B
B
Tracy
asks
cord
ortalius
push
a
microservice
into
a
shared
code,
fresh
pipeline,
for
example,
the
team
is
working
on
the
concept
of
truth
tables,
pushing
a
microservice
through
a
pipeline
based
on
a
risk
level
which
may
change
over
time,
become
less
risky
or
require
more
scrutiny
via
the
pipeline.
So
I
guess
the
question
is:
how
dynamic
are
those
shared
pipelines?
B
They're
super
dynamic,
so
the
this,
the
shared
pipelines,
actually
sort
of
enforces
a
standard
about
how
your
application
is
defined
and
so
a
trigger
which
is
like
saying,
there's
been
a
change
to
this
repo.
You
can
do
those
through
a
cli,
so
there's
an
api
for
it
as
well.
So
if
you're
using
ortilius-
and
you
want
to
say,
oh-
go
trigger
this
pipeline,
you
could
actually
do
that,
and
you
can
say
this
is
the
context
of
what
I
want
you
to
test.
This
is
the
reaper.
B
I
want
you
to
clone,
you
could
pass
in
all
you
know
whatever
variables
you
need,
and
at
that
point
you
can
actually
run
all
the
additional
testing
and
things
that
you
want,
and
you
can
also
pass
parameters.
So
it
could
be
a
single
pipeline
that
takes
parameters
in
order
to
decide
what
risk
level
of
testing
scrutiny
you
want
it
to
go
through,
or
it
could
be
a
few
different
pipelines
that
you
trigger
based
on
the
urologic
and
artillery.
B
B
B
Okay,
so
that's
a
that's
a
good
point,
if
you're
using
different,
so
in
our
case
we're
using
a
ci
pipeline
and
a
cd
pipeline
now
the
ci
pipeline
could
be
potentially
non-kubernetes
dependent
and
then
your
cd
pipeline
could
be,
and
so
you
could
actually
have
potentially
multiple
different
cd
pipelines
depending
on
what's
being
deployed.
You
could
have
it
as
a
step
in
your
pipeline
that
is
to
fight
deciding
how
it's
going
to
define
whatever
it's
going
to
be
deployed
that
could
be
terraform,
that's
not
working
on
kubernetes.
B
B
So,
for
example,
in
ours
we
clone
a
repo
and
we
build
a
docker
file
that
is
and-
and
so
that
means
every
repo
every
application
that
we
work
with
it's
enforced
that
you
have
to
have
a
docker
file.
If
you
want
to
use
this
pipeline
now,
if
you
want
to
go
create
another
pipeline,
you
want
to
have
a
different
process,
that's
possible!
You
should
you
can
totally
do
that.
That's
fine!
But
if
you
want
to
deploy
and
let's
think
of
like
nomad,
maybe
maybe
we've
got
with
some
people
using
nomad.
B
I
could
very
easily
foresee
a
scenario
where
we
have
the
nomad
configuration
in
a
repo
and
the
kubernetes
configuration
for
an
application
in
its
repo
and
it's
basically
consuming
and
looking
for
the
configuration
in
the
in
the
context
that
it
needs
to
operate
and
actually
deploy.
So
you
could
you
could
easily
envision.
B
You
know
a
scenario
where
you
have
a
single
cd
pipeline,
but
you're
actually
supporting
supporting
multiple
deployment.
You
know
strategies
or
potentially
combinations,
so
you
could
have
one.
That's
kubernetes,
one!
That's
a
nomad
one!
That's
your
android
application
whatever,
but
it
still
allows
you
to
reuse
those
pipelines
in
a
kind
of
a
centralized
way,
because,
even
if
you,
even
if
you
have
multiple
pipelines,
you
don't
have
5
000
right.
So
you
have
three
that
cover
your
three
specific
different
use
cases
and
that
becomes
oh.
If
we're
doing
kubernetes,
this
is
the
path.
B
This
is
how
it
works.
This
is
the
policy
if
it's
nomad.
This
is
the
path.
This
is
the.
This
is
the
way
that
we
do
it
if
we're
using
serverless.
This
is
the
one,
and
so
you
could
see
a
scenario
where
you
have
you
know
four
or
five
pipelines
that
are
actually
doing
the
heavy
lifting
for
5000
different
microservices
that
are
all
running
on
different
infrastructure,
so
yeah.
I
think
that
would
be
cool.
This
is
the
way.
B
Well,
I
don't.
I
don't
know
if
we
have
any
other
questions,
I
think.
Oh
there
is
another
one.
Sorry
neil
asks:
does
the
single
cd
know
about
the
nomad
and
k8's
implementations,
or
do
the
individual
implementations
expose
a
common
interface?
Oh
okay?
Actually
this
is
a
cool
topic,
so
this
is
a
little
bit
off
topic,
but
I
can
tell
you
how
we
do
it
in
code
fresh,
so
in
code,
fresh,
the
resources
that
I
want
to
deploy
to
are
defined
as
objects,
so
I
actually
define
my
cluster.
B
My
atomic
cluster,
for
example,
is
a
defined
cluster
that
exists,
and-
and
so
I
can
now
reference
this
within
my
pipeline.
So
if
I
went
to
let's
say
I
was
going
to
add,
let's
like
I
I
can
actually,
I
can
actually
reference
a
cluster
as
an
object
in
my
pipeline.
So
if
I
were
we'll
just
pull
any
random
pipeline
here,
really
quick,
let's
say
that
I
wanted
to
deploy
to
this,
not
using
my
github
step,
but
just
for
an
example.
B
In
my
steps,
maybe
this
huge
step
library-
let's
say
I
was
doing
a
kubernetes
deployment.
What
I
would
do
is,
I
would
just
pass
in
the
reference
to
my
cluster
now
that
cluster
actually
has
permissions
around
it
and
security
and
stuff.
So
I
can
actually
say,
like
only
certain
pipelines
or
certain
people
can
actually
update
it.
So
there's
there's
you
know
permissions
and
security
and
stuff
around
it,
but
yeah.
B
B
B
No,
maybe
there
isn't
a
nomad
one.
I
we
do
have
an
example
in
there
somewhere.
I
gotta
go,
find
it
anyway
yeah
I
can.
I
can
just
reference
that
as
an
object.
That
then
has
the
proper
permissions
and
stuff
around
it.
So
that
could
be
a
lot
of
fun.
Let
me
see
if
I
or
do
the
individual
implementations
explode,
expose
common
interfaces.
I
think
what
you're
asking
neil
is
actually
a
little
bit
deeper
than
what
I've
answered,
which
is
like.
I
have
my
get
ops
dashboard.
B
That
shows
me
the
status
of
all
of
my
applications-
and
this
right
now
is-
is
within
code
fresh,
only
a
kubernetes
feature,
but
I
don't
think
that's
the
intention
that
it
would
stay
that
way.
So
we
did.
We
did
design
and
architecture
in
such
a
way
that
we
could
potentially
add
additional
here.
So
we're
going
to
be
adding
serverless
into
here
and
we're
going
to
start
exposing
serverless.
That
way,
simon,
says
great
lecture.
Thank
you.
B
Is
it
possible
to
get
your
presentation
and
the
answer
is
yes,
you
know
what
we'll
go
over
to
the
final
slide
here
and
I
will
throw
a
link
in
the
chat
I
have
some
extra
slides.
I
need
to
clean
up
at
the
end,
so
nobody
get
too
riled
about
that
and
and
I'll
remove
those
post
haste,
but
I'll
throw
these
into
the
chat
right
now,
so
you
can
get
a
copy
of
it
and
I
think
we
can
we'll
send
out
an
email,
probably
in
the
follow-up.
So
thank
you
everybody
for
joining.
B
B
I
felt
like
it
was
a
chance
where
we
had
a
little
bit
more
conversation,
which
I
really
enjoy
again
you
can
follow
me
on
twitter
at
today
was
awesome,
love
to
have
full
conversations
with
any
of
you
that
would
like
to
please
reach
out
and
happy
to
chat.
So
with
that
I
will
say,
take
care
and
good
luck,
and
I
don't
know
if,
if
there's
any
other
commentary
from
jacqueline
that
you
want.
A
Yeah
I
just
dropped
in
yes,
thank
you
so
much
dan
and
taryn
for
for
joining
us
and
code
fresh
for
for
helping
out.
This
is
awesome.
I'm
really
glad
that
you
guys
are
taking
advantage
of
our
channels.
I
dropped
in
the
link
for
the
youtube
playlist
for
all
of
the
cdf
member
and
ambassador
webinars.
So
as
soon
as
we
get
off
this
call,
I'm
gonna
do
a
little
bit
of
editing
and
then
I
will
make
sure
that
this
video
is
uploaded
to
this
playlist.