►
From YouTube: Sponsor Demo: GitLab - Developer Flow with Kubernetes
Description
This video takes you on what a typical flow would be like for a developer using GitLab. This technical demonstration uses Amazon EKS (Elastic Kubernetes Service) as the deployment environment. We cover areas such as issue creation, Merge Request creation, Auto DevOps pipeline, Merge Request life cycle, Review App, Security static and dynamic scans, advanced deployment techniques, and staging and production rollout, environment and application monitoring and rollback, among others.
A
Hi,
my
name
is
cesar
savedra
technical
marketing
manager
with
git
lab
in
this
demo.
I'd
like
to
take
you
on
what
a
typical
flow
would
be
like
for
a
developer
using
gitlab.
I
will
be
using
amazon
eks
as
a
deployment
environment.
We
have
a
lot
of
material,
so
let's
get
started
so
as
a
developer.
I
track
my
work
via
boards.
Here
you
can
see
my
three
boards
open
to
do
undoing
and,
let's,
let's
say
that
there's
an
application
already
in
production
and
it's
right
here.
A
A
So
here
I'm
going
to
say,
create
merge
request.
Then,
since
I'm
starting
to
work
on
this,
I
will
go
ahead
and
open
web
ide
and
navigate
to
where
the
source
file
is.
And
let's
just
say,
I
want
to
change
the
background
color
and
I'm
going
to
say
aws
also.
I
know
that
there
is
a
unit
test
in
in
this
project
that
will
test.
A
A
Now,
if
we
go
back
to
the
mr
now
notice
here
that
the
in
the
mr,
you
can
actually
click
on
changes
and
see
side
by
side,
the
changes
that
took
place
in
the
files
of
that
project
that
I
applied
in
this
case.
This
is
how
the
stakeholders
on
this
mark
can
collaborate
down
to
the
source
code
line,
changes
and
say
you
know,
looks
good
to
me
or
something
like
that
for
now,
I'm
not
gonna
put
a
comment
in
there,
but
you
know
you
can
you?
A
This
next
screen,
which
is
the
pipeline,
so
a
pipeline,
has
been
started
as
a
result
of
committing
the
changes
to
the
newly
created
branch,
since
this
pipeline
will
take
a
few
minutes
to
complete
instead
of
waiting.
I
already
have
the
same
pipeline
already
completed.
So,
let's
go
see
it
here
is
the
pipeline.
It's
already
been
run
all
the
way
to
the
end,
and
this
pipeline
is
part
of
our
auto
devops
pipeline,
which
comes
out
of
the
box
and
is
based
on
lessons
learned
and
best
practices
for
continuous
integration
and
continuous
delivery.
A
A
However,
if
these
pipelines
don't
quite
fit
your
needs,
you
can
create
your
own
pipeline
or
modify
an
existing
one.
This
specific
pipeline
includes
the
review
app,
which
is
right
here,
and
this
spins
up
its
own
environment
in
this
case
in
the
eks
cluster,
so
that
updates
can
be
validated
by
the
stakeholders
of
this.
Mr,
so,
let's
briefly
now
go
over
each
of
the
jobs
included
in
this
pipeline,
we'll
start
with
a
build
stage
and
also
the
job
which
creates
a
build
of
the
application
using
an
existing
docker
file.
A
The
resulting
dockerfile
image
is
pushed
to
the
container
registry
and
tagged
with
a
commit
sha
or
tag.
Then
in
the
test
stage,
you
have
a
few
jobs
here
in
general
test
analyzes
your
project
to
detect
a
language
and
framework
that
is
written
in
or
implemented
in,
and
then
it
runs
the
appropriate
test
for
your
application.
It
will
also
use
the
test
you
already
have
in
your
application.
In
this
case,
it
will
run
the
single
unit
test
that
I
showed
you
earlier
and
if
there
are
no
tests,
it's
up
to
you
to
add
them
code
quality.
A
A
Another
area
related
to
secrets
is
the
ability
to
mask
protect
variables.
Gitlab
provides
this
capability
via
our
ci
cd
variable
settings,
which
I
will
show
you
in
a
minute
spot
bugs
sas,
which
is
also
part
of
our
static
application
security
testing
suite.
It
runs
a
static
analysis
on
the
current
code
and
checks
for
potential
security
issues,
for
example
buffer
overflow.
The
review
app
it
actually
creates,
like
I
mentioned
before,
a
container
and
deploys
the
application
on
eks
and
the
stakeholders.
A
But
if
you,
if
you
were
to
change
this,
you
would
just
click
on
these
check
boxes
and
obviously
masking
is
useful
so
that
you
don't
show
the
actual
value
in
any
of
the
jobs
or
output
that
is
generated
from
running
the
jobs.
So
the
ability
to
protect
and
mask
these
variables
shields
organizations
from
potential
security
issues.
A
So,
let's
go
back
to
where
we
were
here
and
let's
continue
going
over
right
here
to
the
next
stage
is
dast
and
that's
our
dynamic
application,
security
testing
capabilities,
the
das
analyzes
the
current
code
and
checks
for
potential
security
issues,
for
example,
you
know
cross-site
scripting
and
then
the
performance
measures
the
performance
of
a
web
page.
It
creates
a
json
report
as
well,
including
the
overall
performance
score
for
each
of
the
pages
and
it
uploads
this
report
as
an
artifact.
So
let's
go
back
to
the
mr
here.
A
One
thing
I
like
to
bring
up
to
your
attention
is
that
this,
mr,
is
related
to
the
issue
that
that
created
it
and
and
when
the
mr
is
completed,
it
will
also
close
the
issue
as
the
jobs
run,
data
is
generated
and
art
and
reports
are
generated
that
are
uploaded
as
artifacts.
You
can
click
on
the
full
report.
A
So
the
review
environment
is
actually
a
running
environment
that
has
all
the
updates
applied
to
it,
and
it's
the
the
point
or
environment
that
these
the
stakeholders
can
use
to
check
that
all
the
changes
that
were
made
are
correct.
Let's
merge
the
the
dmr
now
notice
that
the
merge
button
here
is
not
is
not
available.
A
It's
grayed
out,
and
the
reason
is
that
this,
mr,
has
been
marked
in
draft
mode
okay.
So
this
is
something
that
is
built
in
within
gitlab
and
it's
an
extra
safety
mechanism
to
prevent
an
accidental
merge
and
to
indicate
also
that
this
is
still
being
worked
on.
So
first,
we
need
to
clear
draft
mode
by
clicking
on
the
marcus
ready
button,
and
now
the
prefix
draft
in
the
mr
title
will
be
gone,
and
now
the
merge
button
is
activated.
A
A
Let's
merge
and
this
merge
is
going
to
kick
off
another
pipeline.
That
will
run
all
the
checks
that
you
saw
earlier
and
it
will
take
the
deployment
to
a
staging
environment
that
will
also
be
running
on
eks.
At
this
point,
this
is
going
to
take
a
few
minutes,
so
let's
go
to
an
mr
that
has
already
completed.
A
So
this
is
the
exact
same,
mr
that
is
executed
on
the
other
project,
but
it's
already
completed
notice
here
that
you
know
the
changes
were
merged
into
master
and
the
source
branch
has
been
deleted
and
the
issue
has
been
closed.
So,
let's
go
to
the
pipeline
now
notice
here
now
that
this
is
showing
some
jobs
here
that
were
not
there
before,
and
this
is
basically
the
continuous
delivery
portion
of
the
pipeline.
A
You
can
see
here
that
there
is
a
staging
environment.
So
again,
like
I
mentioned
before
once
the
updates
have
been
merged.
An
environment
is
spun
up
only
ks,
and
this
is
called
the
staging
environment,
and
at
this
point
you
don't
see
it
in
this
case,
but
these
are
manual
steps,
so
this
will
be
grayed
out.
These
actually
were
great
grayed
out
and
you
have
to
manually
click
on
these.
A
You
can
choose
10
25,
50
100,
an
incremental
rollout
into
production,
reduces
the
risk
and
contributes
contributes
to
a
better
user
experience
and
reduces
the
danger
of
an
outage
and
after
the
application
has
been
rolled
out
to
production
into
the
production
environment.
Another
performance
test
is
run
in
production,
so
let's
go
back
to
the
completed
merged.
Mr
and
I
want
to
click
on
production
here.
This
is
showing
the
production
environment.
A
A
The
nice
thing
about
this
auditable
sequence
of
changes
is
that
at
any
point
in
time,
if
you
introduce
a
change
and
you
notice
that
this
is
showing
an
unexpected
behavior
in
production,
you
can
always
roll
back
the
environment
by
clicking
on
this
on
this
button
right
here,
the
rollback
environment,
which
will
take
you
back
to
a
previous
and
previous
known
state.
At
this
point,
you
can
click
on
view
deployments,
and
this
is
actually
the
application
running
in
production.
A
As
you
notice,
it
has
a
new,
the
new
color
that
we
applied
orange
and
it
has
the
aws
prefix.
So
the
two
changes
that
we
introduced
introduced
into
production.
The
other
thing
I
wanted
to
show
you
was
the
monitoring
we
have
prometheus
running
on
the
eks
cluster
collecting
collecting
metrics,
and
this
is
showing
you
metrics
not
just
for
the
cluster,
but
also
for
the
running
application.
Here,
let's
redeploy
this
environment
and
then,
let's
go
back
to
the
monitoring
window.
A
The
the
rockets
that
you
see
here
are
actually
a
change
that
was
just
rolled
out
to
production
and
it's
you
can
actually
see
the
job
itself
that
executed
as
a
result
of
that
that
update
to
production
and
the
nice
thing
about
these
indicators
is
that
they
can
help
you
troubleshoot
production
issues,
because
there
is
a
correlation
between
the
behavior
of,
for
example,
total
memory
here
and
the
introduction
of
the
of
that
change.
So
these
demos
so
far
have
used
eks
and
ecs
as
a
deployment
platforms.
A
However,
you
can
also
use
gitlab
with
bare
metal
and
virtualize
deployment
environments,
as
well
as
different
operating
systems
like
windows,
all
right
so
to
wrap
up.
We
have
gone
over
how
gitlab
can
help
organizations
speed
up
their
software
development
and
delivery.
We
discussed
auto
devops
and
how
it
can
get.
You
started
quickly
with
pipelines
that
are
germane
to
your
project,
language
and
deployment
environment,
whether
it
is
eks
ecs,
bare
metal,
virtualized
environments
or
even
windows.