►
From YouTube: Steve & Sacha talk "Ortelius and GitOps POC"
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
Can
I
can
I
can
I
give
you
some
feedback
just
quickly
now,
just
just
to
see
if
I'm
on
the
right
track
with
you,
like,
basically
your
source
of
truth,
being
your
repo
yeah?
Is
that
right,
so
you've
got
a
code
base
and
a
helm
chart
right,
and
your
argo
is
looking
at
your
helm,
chart,
obviously
for
any
changes:
correct,
okay
and
then
your
and
then
ortilius
is
like
the
grand
orchestra
got
grand
conductor
of
the
orchestra.
Basically,
all
these
changes
and
versions
that
are
being
pushed
and
pulled
it's
being
recorded.
B
B
B
B
B
B
A
B
B
B
B
B
B
A
A
A
A
B
B
A
B
A
B
B
A
B
B
A
B
B
A
A
B
Right,
so
we
just
want
to
make
sure
that
we
record
that
that
it
was
successfully
or
or
if
it
failed,
that
what
happened
so
argo
will
send
the
event
back
to
artelia,
saying
this
for
this
values
file
that
you
just
had
me
update.
I
completed
it
as
part
of
that
and
that
kind
of
wraps
up
our
our
process
for
like
a
ci
event.
Now
the
cool
thing
is
once
we
know
it's
been
completed.
B
A
B
A
A
B
B
Captain
content
can
tell
ortilius,
deploy
roll
back
that
deployment
and
just
deploy
the
minus
one
application
version,
and
what
will
happen
is
when
we
say
go,
deploy
the
minus
one.
Ortilius
would
go
and
update
the
repos
again
with
the
values
file
from
the
minus
one
version,
and
we
go
through
this
whole
process
again
with
the
quality
gate,
check
and
argo
keeping.
A
B
B
A
A
B
B
Basically,
what
we
need
to
do
now
is
now
that
the
source
code
is
passing
the
ci
level.
We
probably
want
to
go
ahead
and
do
our
final
build
to
push
it
down.
Do
our
merge
into
main
and
then
do
our
our
final
build.
So
that's
where
you
get
into
hold
the
into
the
whole
git
flow,
like
you
were
talking
about
of
how
you
tag
things
and
move
things
along,
but
basically
we've
done
our
ci
level,
we're
happy
with
all
that.
B
B
A
B
Yeah
so
once
we
once
we
quality
gauge
ci
and
we're
happy
with
that
ci's,
the
ci
environment
is
all
good
in
in
ci
or
dev.
Whatever
you
want
to
call
it
once
we're
happy
with
that
environment,
we
need
to
do
our
final
build
because,
most
of
the
time,
all
these
prs
are
happening
all
day
long.
You
don't
want.
A
B
You
have
to
do
your
merge
into
a
branch
to
get
your
code,
that's
on
your
pr
code
merged
with
the
main,
so
you
you're
you're
doing
your
integration
and
you're
figuring
out
your
merge
conflicts,
because
at
this
point
we
could
still
have
merge
conflicts.
So
if
you
change
something
I'd
change
the
same
code,
we
could
have
a
merge
conflict
and
we
need
to
resolve
that
as
part
of
our
git
flow.
A
B
A
B
A
B
A
A
A
B
B
So
that's
the
first
time
through
and
we
go
through
do
our
deployment.
We
tell
captain
that
the
deployment's
done
captain
runs
his
quality
check,
everything's
good
now,
captain
because
it
has
a
pipeline
we'll
go
on
to
its
next
step
in
the
pipeline,
which
will
be
like
system,
integration
or
qa
or
whatever
you
want
to
call.
It
doesn't
really
matter,
but
that's.
A
A
A
B
Yeah,
so
once
we
once
we
go
through
the
first
loop
for
ci,
the
quality
gate
is
good.
Now
we
have
to
we're
going
to,
we
could
either
stop
there
or
we
can
automatically
merge
that
pr
onto
main,
for
example,
or
onto
whatever
branch
you
want
to
call
it
doesn't
really
matter
whatever
your
git
flow
process
is.
B
B
B
B
We
tell
come
back
and
tell
captain
that
the
deployment
into
qa
is
complete,
go
check
your
quality
gate
and
it
says
oh
everything's,
good,
on
the
quality
gate
for
qa.
Do
we
want
to
now
go
ahead
and
follow
our
git
flow
and
move
it
to
the
next
stage,
and
that
could
be
like
tagging.
You
can
add
another
tag
or
do
another
merge
from
qa
into
prod,
for
example,
on
the
branch
level
or.
B
A
B
Yeah
and
the
nice
thing
with
our
the
argo
application
sets,
is,
you
could
do
like
prod
dash
values,
dot,
yaml,
and
it
will
recognize
that
that's
the
production
one
or
you
could
do
qa
dash,
values.yeah,
mmo
or
ci,
and
it
that's
some
of
its
filtering
capabilities
that
allow
us
to
have
multiple
values.
Files
in
the
same
get
repo.
A
A
B
A
B
B
B
A
B
B
B
B
So
that's
kind
of
the
process.
It's
the!
If
you,
if
you
step
back
and
look
at
it,
you
know
you
have
your
your
your
change.
That's
happening
to
to
get
captains,
picking
that
up
telling
ortilius
about
it.
Ortilius
does
the
deployment
it
just
comes
back
and
tells
captain
that
it's
done
and
then
from
there
it
says:
okay,
we're
good
to
go
we'll
go
on
to
the
next
stage
of
the
of
your
get
process.
A
A
B
So
normally,
what
you'd
have
to
do
is
after
the
build's
done,
and
you
do
your
push.
You
have
to
go.
Take
that
image,
num
image,
sha
and
then
go
back
and
update
your
values,
file
manually
with
a
new
version
and
then
check
that
in
and
have
a
go.
But
then
you
know
you
don't
have
that
concept
of
an
application
version
and
argo
doesn't
really
have
a
a
concept
of
of
the
an
application
either
and
that's.
A
B
B
A
A
A
B
B
A
B
The
whole
git
process,
like
I
said
it,
will
be
slightly
different,
but
from
the
artillery
side
and
the
kept
inside
doesn't
really
matter.
It
all
happens,
the
the
same
from
there
on
out,
because
one
of
the
things
is
once
we
do
our
merge
into
main.
For
example,
that's
gonna
be
our
last
build
and
we'll
take
that
image.
A
Exactly
okay,
that
makes
sense
to
me
a
really
awesome
process.
Wow,
like
I
said,
I've
got
a
meeting
with
woodcock
tomorrow
morning
at
eight,
my
time,
so
just
to
get
some
captain
feedback
from
him,
but
yeah.
I
can
go
build
this
along
and
it's
cloud
agnostic
right
yeah.
This
is
totally
cloud
agnostic.
You
don't
need
to
worry
about,
be
anywhere.