►
From YouTube: GitLab GitOps Flow
Description
Demonstrating the GitLab Flow applied to GitOps and an IaC use case following a new hire onboarding task to deploy into production on their first day of onboarding
A
Value
of
gitlab
is
this
flow
because
without
the
flow
we're
not
actually
exercising
all
of
what
the
platform
is,
we
start
with
high
level
epics
portfolio
management.
We
do
point
in
time
milestones.
We
create
issues
assign
issues,
do
something
with
it
push
code.
Even
if
that's
infrastructure
as
code
do
testing
do
scanning
collaboration
and
review
fix
our
code,
make
sure
it
works
before
we
approve,
merge,
accepted
and
deploy
into
production,
and
so
it's
this
flow
that
I
want
to
demonstrate
for
you
today.
A
It's
demo
time,
I'm
going
to
take
on
the
Persona
of
a
junior
infrastructure
engineer
a
junior
Ops
person
at
a
company.
Let
me
introduce
you
to
be
kind
com.
This
is
the
entire
group
that
I
have
and
within
it,
I
have
an
apps
subgroup
with
applications
deployed.
I
have
a
governance
subgroup
where
I've
defined
team
members
on
infrastructure
group,
where
I've
put
kubernetes
clusters
that
could
be
deployed
out
there
in
into
the
world
I
mean
put
the
the
terraform
project
that
will
deploy
those
clusters.
This
is
Ops
Ingrid,
she's
devops.
A
So
when
she
looks
into
Apps
she
can't
see
any
of
the
apps
she's.
Only
a
member
of
team
devops,
so
she
only
sees
that
there
infrastructure
she
has
some
visibility
to,
because
this
is
more
related
to
her
job.
There
is
a
cluster
manager
project
here
which,
if
you're
familiar
with
gitlab
you're
sort
of
familiar
with
I,
have
highly
customized
this.
This
is
in
name
only
familiar
to
you
if
you're
familiar
with
gitlab
and
how
we
do
kubernetes
manage
management
now
to
show
you
having
introduced
as
a
new
hire.
A
Ingrid
has
an
onboarding
issue,
and
so,
if
we
look
in
her
to
Do's,
a
Scott
rival
has
assigned
Ingrid
a
an
onboarding
issue,
and
so
we're
going
to
follow
this.
Welcome
to
your
first
day,
please
deploy
an
application
called
post
facto
into
production
in
your
own
namespace,
okay.
Well,
that's
wild
day,
one
we're
going
to
install
something
into
production
so
because
I've
done
this
before
I'm,
just
going
to
create
a
new
tab.
So
I
can
see
my
tasks
here
in
this
tab
and
okay,
we're
going
to
create
a
merge
request
against
this
issue.
A
A
So
in
the
merge
request,
we
can
come
here
and
check
out
the
the
feature
branch
that
has
been
created
in
the
web
IDE,
and
this
is
against
the
cluster
manager
project.
Okay,
within
the
Manifest
for
our
production
cluster,
create
a
new
namespace
and
install
the
post
facto
home
chart
use
the
Ops
onboarding
snippet
to
complete
the
following
okay.
What
is
that?
Oh,
we
have
Snippets.
So
in
our
onboarding
task
we
can
have
code
that
is
commonly
used
that
people
can
leverage
and
use
for
their
own
projects.
Okay,
so
create
a
namespace
manifest
and
manifest.
A
Okay,
so
create
a
namespace
under
the
cluster
that
we're
related
to
under
manifests
I'm,
going
to
create
a
manifest,
create
a
new
file
under
Manifest.
This
file
is
going
to
be
called
team,
Ops,
Ingrid
or
the
the
folder
is
going
to
be
team,
Ops
and
grid,
and
the
the
name
of
the
file
will
be
this
all
right,
Ops
and
grid
our
ID,
the
contents
of
the
file.
We
will
just
copy
and
paste
we're
going
to
change
this
to
Ops
Ingrid,
very
nice.
Now
what
else?
What
else
are
we
doing?
A
Namespace
manifest
in
the
same
folder
create
an
Ingress
for
the
anticipation
of
installing
post
facto
okay.
He
wants
me
to
create
an
Ingress
all
right:
here's
the
file
name
file
name
and
in
my
IDE
in
Ops,
Team
Ops,
Ingrid
I'm,
going
to
create
a
new
file.
Oh
that's
already
there
file
name
Ingress,
all
right.
What
is
my
Ingress
here
we
go
so
the
Ingress
is,
you
know,
going
to
give
me
name
services
for
my
application
that
I
deploy,
Ops,
Ingrid
I,
can't
believe
they're
just
going
to.
A
Let
me
deploy
straight
into
production
on
my
first
day
in
the
in
the
run
me
sh
in
charts,
oh
deploy
a
Helm
chart,
I
thought
this
was
git
Ops,
because
git
Ops
just
takes
and
pulls
manifests.
Where
is
the
helm
command
actually
going
to
run?
That's
interesting,
okay,
well,
I!
Believe
it,
let's
see
how
it
works,
runme.sh,
what
that
is.
Manifest
charts,
we're
gonna,
create
a
new
file
team,
oops
Ingrid
in
this
folder
and
I'm
going
to
put
runme.sh
okay.
What
does
that
do
run?
Me.Sh
looks
like
it's
like
home
commands,
so
this
is.
A
This
is
like
imperative,
so
the
first
one
in
manifest
that
must
be
a
get
pull
capability
and
kubernetes
and
the
agent
is
going
to
pull
the
Manifest
into
kubernetes
to
deploy,
but
in
this
one
this
is
an
imperative
command.
This
is
a
push-based
get
Ops
where
something
is
going
to
run
the
helm
command
and
deploy
using
all
these
variables,
where
these
variables
Cube
cuddle,
commands,
Cube,
cuddle,
Cube
control,
we're
actually
going
to
exactly
create
an
admin
user.
I
wonder
what
the
credentials
are
all
right.
Well,
that's
what
they
told
me
to
do.
A
A
Now.
What
I
see
down
here,
there's
some
Pipelines?
What
is
this
so
here's,
my
pipelines,
it's
doing,
Secret
detection,
that's
cool,
commit
scan,
no
secrets.
Yeah
I,
didn't
add
any
secrets.
They
were
all
variables
all
right.
So
what
am
I
supposed
to
do?
I
made
I
made
the
commit
I
did
the
namespace
the
folder.
The
run
me
monitor
your
pipeline
for
any
leaked
credentials.
Yeah,
okay,
I
did
that
okay
set
the
merge
request,
reviewer
to
S
Brightwell,
to
accept
and
merger
changes
into
production.
A
Oh
that's
right!
So
as
a
junior
admin
first
day
on
the
job,
I
don't
have
access
to
deploy
into
production.
I've
made
all
these
manifest
changes,
but
they're
not
in
production.
Yet
because
they're
on
a
feature,
branch
right,
I've
created
a
feature
branch.
In
my
merge
request,
my
merge
request:
here's
my
merge
request,
I've
created
a
feature:
Branch,
not
production,
and
so
all
these
pipelines
and
scans
are
running
on
the
feature.
Branch
I
can
mark
it
as
ready
to
merge,
but
I
don't
have
the
possibility
of
merging
of
accepting
okay.
A
Sprite
well:
okay,
there's
that
guy
he's
a
handsome
guy
all
right,
so
I've
set
him
as
the
reviewer.
Now.
What
well?
Let's
see
s
Brightwell
needs
to
come
back
s
Brightwell
and
be
kind.
Here.
Has
a
new
to
do.
Ops
Ingrid
requested
a
review.
Okay,
so
I
need
to
go
review
this.
What
this
is
my
my
favorite
new
employee,
Ingrid
she's
on
our
Ops
Team
no
vulnerabilities
were
selected.
The
pipeline
looks
good.
What
changes
did
she
make?
Oh
yeah
she's,
going
through
the
Snippets
that
I
did
run
me.sh,
Yup,
she's
added.
A
A
There
can
be
an
approval
process
formally
as
well,
and
we
might
see
that
later
in
the
dev
section,
where
we
have
security
vulnerabilities.
But
here
it's
enough
to
accept
the
merge
now
what
happens?
Two
things
happen
in
this
particular
scenario.
Now
that
I've
accepted
the
merge
onto
the
production
branch,
two
things
are
happening.
The
gitlab
agent
has
automatically
pulled
the
manifests
that
Ops
Ingrid
created
and
has
deployed
a
namespace
and
a
Ingress
controller.
A
A
A
So
the
the
script
that
I
wrote
to
do
this
actually
interrogates
all
the
different
cluster
folders
that
I
have
for
demo
purposes.
So
it's
interrogating
all
the
folders
that
have
charts
I'm
re-running
the
home
chart
for
the
get
lab
Runner
every
time.
I
do
this.
How
can
I
do
it
because
it's
idem,
potent
right
I,
can
re-run
the
helm
charts
every
time
and
if
it's
already
there
and
nothing
has
changed,
nothing
will
change.
A
But
if
a
new
version
is
out
there
in
the
repo
in
the
in
the
container
registry
or
something
like
that
for
Ingress
nginx,
then
it
will
be
redeployed.
So
make
sure
if
you're
doing
things
like
this,
that
your
scripts
are
item
potent.
So
here
comes
team,
Ops
Ingrid,
the
post
facto
Helm
chart
is
being
deployed.
A
A
Post
facto
instance,
so
now
that
postgres
and
redis
are
up
the
actual
application
is
up
as
well
and
keep
in
mind.
This
is
very
important
functionality.
You're,
you
won't
be
deploying
into
kubernetes
only
the
things
that
your
developers
author,
so
while
pull-based
get
Ops
and
hydrating
your
own
manifests
and
doing
that
that
sort
of
by
hand
and
then
doing
the
agent
based
pull,
is
great.
A
Some
of
you
will
want
to
run
Helm
charts.
Some
of
you
will
want
to
run
the
customize
command
to
actually
template
and
hydrate.
Those
final
kubernetes
manifests.
Where
are
you
going
to
run
it
on
your
laptop
and
hope
it
works
in
production?
No,
you
should
run
those
in
CI
to
hydrate
the
final
manifest
and
then,
if
you
need
to
commit
it
back
to
the
repo
and
that
commit
back
to
the
repo
is
actually
what
pulls
the
hydrated
manifests
down
into
production.
A
So
there's
a
couple
of
different
design
philosophies
for
how
you
might
use
this,
but
they
all
you
can
do
anything
you
would
like
to
do
because
gitlab
has
both
the
pull-based
and
the
push-based
get
Ops
immediately.
You
can
see
the
power
of
the
get
lab
flow
in
that
Junior
kubernetes
admins
Junior
infrastructure
people
can
edit
the
infrastructure
as
code
in
the
git
repo,
but
do
so
in
a
feature
branch
that
mandates
review
by
senior
administrators
to
then
run
in
production.
So
it's
not
a
free-for-all.