►
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
Hello,
my
name
is
Victor.
I
am
one
of
the
product
managers
at
gitlab
and
me
and
my
team.
We
are
responsible
for
gitlabs
Kuban,
Integrations
and
infrastructures
code
functionality
in
this
series
of
videos
likely
in
three
videos.
I
would
like
to
demo
you
how
gitlab
can
help
you
if
you
are
an
infrastructure,
engineer
and
SRE
or
if
you
are
a
platform
engineer
setting
up
automations
for
your
teams
or
if
you
have
a
good
platform
engine
and
want
to
benefit
from
their
work.
A
Okay,
hello
in
this
third
video
I'm,
going
to
speak
to
you,
how
workflow
that
we
created
with
in
the
previous
two
videos
with
a
incode
platform,
how
it
looks
like
for
the
software
developer
for
the
people
who
actually
own
the
applications
deployed
through
those
projects.
Let's
get
quickly
through
again
what
we
have
spoken
already.
A
So
we
have
an
infra
platform
project
where
we
created
the
cluster
with
tform,
and
we
have
this
project
tform
project
that
hosts
yl
file
that
defines
the
actual
platform,
managed
infrastructure
and
project,
and
all
of
this
in
the
end
deploys
through
clux
and
we
can
visualize
it
with
the
agent.
What
the
project
terraform
project
does
is
that
it
creates,
for
example,
this
repository
here,
which
we
call
a
delivery
repository,
and
this
is
where
I
would
like
to
stop
a
little
withit,
how
we
recommend
organizing
repositories.
A
You
don't
have
to
follow
this
strictly,
but
in
this
demo
this
is
what
we
actually
did.
We
have
a
separate
application
repository
and
a
delivery
repository.
This
means
that
software
developers
can
use
the
well
own
branching
strategies
to
create
a
feature.
Branch
merge
it
to
start
a
merge
request
with
the
changes
they
could
actually
even
build.
An
image
in
the
merge
request.
A
Update
the
respective
manifest
in
the
delivery
repository
to
deploy
to
a
development
environment
then
merge
the
merge
requests
into
the
main
pipeline,
update
the
develop
delivery
repository
again
to
deploy
to
their
staging
environment
and,
at
some
point,
tag
the
repository
to
build
the
necessary
artifacts
and
start
this
a
process
to
deploy
the
application
into
the
production
environment
so
that
totally
feasible,
and
but
what
you
have
seen
in
the
industry
is
that
software
development
requires
a
very
different
branching
and
branching
strategy
and
update
frequency
than
the
delivery
code
requires.
A
For
that
reason,
we
prefer
to
keep
delivery
in
a
separate
repo
in
this
repository.
Basically,
everything
that
matters
lives
on
the
main
branch,
because
infrastructure
is
by
definition,
stateful,
and
this
means
that
we
store
the
Manifest
for
the
different
environments
in
subdirectories
and
why
flux
could
read
these
this
repository
directly
with
the
git
repository
Source,
we
are
going
to
use
an
oci
repository,
that's
an
add,
added
layer.
You
can
think
about
it
as
it
does
just
caching.
You
can
think
about
it,
as
it
simplifies
a
little
bit
developer
experience
in
local
development
setups.
A
You
can
think
think
about
it
that
it
just
scales
better
because
your
images
are
likely
much
smaller.
If
you
only
package
the
files
that
are
needed
needed
for
a
specific
deployment
and
not
the
whole
git
repository
needs
to
be
checked
out
and
it
might
be
even
more
stable,
for
example,
if
use
a
if
your
git
repository
is,
for
whatever
reason,
less
stable
than
your
container
registry.
So
this
is
the
setup
we
have
a
separate
application,
repository
and
separate
deler
repository
with
the
environments
and
the
actual
actual
code.
A
The
gthp
repo
is
this
one.
Now
I
will
show
you
how
one
Updates
this
repository
and
how
it's
reflected
afterwards
in
the
development
and
production
environments.
We
have
right
now
these
two
will
deploy
to
the
same
cluster
just
to
different
name
spaces,
but
this
is
just
because
this
is
demo.
So
in
this
U
repo,
as
I
already
said
in
a
previous
video,
we
have
the
chart.
This
is
the
Potato
Head
chart
without
any
modifications,
and
then
we
have
these
environments
and
within
both
we
have
the
same
two
directories.
A
One
is
a
setup
directory
that
can
host
any
kuus
resources.
You
need
to
prepare
the
environment
to
be
ready
for
the
application.
It
might
be
sealed,
Secrets
or
just
references
to
secrets
in
in
whatever
external
store.
It
can
be
additional
applications
that
you
want
there
side
cards
or
whatever,
and
you
will
likely
want
to
add
a
resource
that
points
to
your
application.
A
In
this
case,
we
are
using
OC,
as
I
already
mentioned,
so
we
just
point
to
the
same
project
to
this
Potato
Head
image,
and
then
we
have
a
customization
that
goes
together
with
that
and
requires
the
whole
image.
Now
what
that
oci
application
oci
contains
it
contains
the
flux
resource
definition.
That's
a
ham
repository,
it's
the
same
chart
from
this
project
again
packaged
as
a
oci
container
and
the
related
ham
release.
A
Here
you
can
even
use
customize
and
run
a
customize
command
in
the
gitlab
pipeline,
a
customize
build
that
creates
you,
the
final
ham
release
or
you
can
use
another
customization
flux
customization
in
your
cluster.
It's
totally
up
to
you
how
you
structure,
I'm
here,
demoing
it
with
the
chart.
You
can
see
that,
for
example,
here
we
have
replica
count.
Two,
and
here
are
the
different
potato
part
configured.
While,
if
I
go
to
the
development
application,
then
I
have
a
replica
count
of
one.
A
It's
not
defined,
and
we
have
the
same
part
numbers
right
now.
So
this
is
the
basic
setup
and
and
together
with
that,
as
the
platform
project
already
set
up
this
project
and
even
actually
the
application
project
they
are
set
up
for
us
to
be
able
to
see
the
cluster
State.
We
can
open
the
the
cluster
State
and
see
that
in
production
we
have
12
running
pods
and
everything
is
healthy
and
reconciled
by
flux.
While
in
the
in
development
we
have
only
likely
six
pods
if
everything
works.
A
A
This
D
and
production
environments
by
hand
and
as
we
don't
deploy
from
here,
you,
you,
don't
really
see
any
deployment
data,
but
you
can
still
see
the
application
status
from
your
cluster
and
this
brings
the
cluster
close
to
the
development
developers
who
might
have
access
already
to
your
gitlab
instance,
who
might
be
familiar
with
gitlab,
and
they
can
just
easily
check
out
these
views
whenever
they
a
little
bit
wor
that
something
might
go
wrong.
A
Okay,
now,
let's
see,
how
do
you
update
something,
of
course,
in
a
real
setup,
you
would
likely
create
a
new
version
in
this
repository
and
have
that
to
kick
out
everything
now
I,
don't
want
to
change
the
code
and
build
out
the
container,
but
basically,
in
the
end,
what
it
ends
up
with
is
a
change
in
your
manifest.
So
what
I'm
going
to
do
I
would
just
change
the
Manifest
here
in
the
delivery
repository
you
can
automate
these
changes
across
the
repositories
through
triggers
and
things
like
that.
A
Different,
let's
use
even
numbers
here
and
U,
there's
no
six,
if
I'm
not
mistaken,
so
we
use
two
and
four
for
the
development
environment
and
we
will
use
the
odd
numbers
three
and
five
for
production
and
as
I'm
already
in
a
in
an
ID,
will
show
you
quickly
a
few
things
about
our
pipeline
that
we
be
run.
We
will
skip
the
chart
because
nothing
changed
there
and
then
we
will
skip
the
entry
point
as
well.
A
What
we
will
run
is
this
Dev
app
job,
which
just
runs
every
time
when
we
change
these
manifests
and
it
will
create
the
flux,
oci
image
and
it
will
trigger
flux
to
Recon
side
that
image
and
we
do
the
same
with
the
production,
but
there
it
will
be
a
manual
job,
so
the
raise
manager
can
come
in
and
hit
the
button
whenever
needed.
Okay,
let's
update
the
environments
and
what
we
want
to
do.
We
want
to
commit
this
to
a
different
branch.
A
Now,
in
this
case,
we
can
continue
working
in
the
merge
request
and
once
we
are
done
with
that,
we
can
merge,
and
even
though
we
merge
to
our
main
branch,
it
will
only
deploy
to
development
cluster,
because
we
are
building
the
development
image
right
now
and
once
it's
built,
it
will
immediately
go
out
to
the
development
environment.
We
should
be
able
to
see
it
here
once
it
arrives.
I
will
update
it
a
couple
of
times
to
see
once
it's
there,
and
actually
we
should
be
able
to
see
it
as
well
under
the
environments.
A
Let's
do
it
here,
Dev
and
the
calan
view
it
said
already
reconcile,
but
we
don't
know
whether
it's
the
new
one
or
the
old
one.
Oh
it's
the
new
one,
okay.
So
this
is
it
everything
changed
as
expected,
but,
as
you
can
see
now,
the
pipeline
is
the
block
State
and
the
production
job
did
not
run.
We
can
see
this
as
well
in
the
production
view
that
there
is
a
waiting
job
and
this
job
is
that
one
to
start
it?
You
should
click
on
this
job
and
then
run
the.
A
A
So
now
something
happens
in
my
cluster.
Things
are
loading
there
we
go
so
this
is
in
development.
This
is
in
production
and
simply
by
updating
the
delivery,
we
manage
to
retain
the
control
over
the
deployment
of
different
versions
into
production.
While
we
could
automate
the
deployment
delivery-
and
we
do
this
with
the
best
practices
from
flux
using
an
oci
registry
as
a
caching
layer
between
your
git
repository
and
your
cluster,
but
it's
still
100%
giops,
because
it's
driven
by
your
git
repository
the
oci
is
not
modified
outside
of
git.