►
From YouTube: GitLab Releases & Traceability
Description
How can GitLab be leveraged fully as a "single application for the complete DevOps lifecycle". This aims to show how from a release standpoint GitLab provides immense value but also where we could improve.
A
Hi,
this
is
tim
poffenberger
and
I'm
a
solutions
architect
at
get
lab,
and
I
wanted
to
walk
through
an
expected
flow
that
I
have
in
my
head
over
really
the
the
power
that
get
lab
provides
in
terms
of
traceability.
There's
a
few
gaps
that
I
want
to
highlight,
but
I
I
think,
where
we're
at
is
really
cool
and
I
think
we're
so
close
to
getting
this
right.
So
when
it
comes
to
releases,
how
can
I
leverage
gitlab's
knowledge
of
all
things
to
my
advantage?
A
A
A
That
release
will
create
a
tag
via
a
get
tag,
but
I'm
not
going
to
have
any
pipeline
run
for
that
release
and
then,
subsequently
that
deployment
object
is
created
within
gitlab
within
the
environments
page
and
related
to
the
the
commit
shaws,
and
this
is
really
where
we're
so
close.
But
this
is
what
I'm
expecting
to
to
happen.
A
A
I'm
really
just
copying
and
pasting
some
of
the
things
that
we
already
leveraged
for,
I
think
our
13.6
release
here.
You
can
actually
you
can
see
the
commit
shaw
and
if
I
drill
into
that
commit
shall
you
can
see
that
there's
no
merger
related
requests
and
no
related,
merge
requests
found,
but
the
the
actual
merge
message
provides
that
all
for
me.
A
So
it's
nice
because
I
have
one
the
issue
relation
as
well
as
the
the
merge
request
relation
and
you
can
also
see
that
there
was
a
pipeline
run
and
that
the
production
job
ran
successfully
as
well.
So
if
I
click
on
this
merge
request,
I
can
drill
in
and
see
again
a
different
view,
but
it's
also
nice
here,
because
I
have
the
pre-merge
pipeline
that
ran
and
then
all
the
the
request
approvals
and
then
the
merge
action
and
then
subsequently
the
this
deployment
out
to
production.
A
So
you
can
actually
see
that
it
was
deployed
out
to
production
from
the
the
merged
merge
request
page
so
far.
This
is
great
everything's
kind
of
tied
together.
Lastly,
I'm
going
to
click
on
this
production,
which
is
going
to
take
me
to
this
production
environment
page
and
here's
where
it
gets
a
little
a
little
confusing.
So
I
just
deployed
this
is
my
most
recent
deployment,
but
it
is
a
an
older
deployment,
so
you
don't
actually
see
it
all
the
way
up.
A
You
know
this
merger
commit
message
is
not
useful
based
on
get
lab
flow.
This
commit
shaw
is
not
going
to
be
very
useful
because
I'm
not
a
machine,
and
this
master
branch
is
not
going
to
be
very
useful
because
you
know
consistently.
I'm
only
seeing
this
this
commit
where
this
page
comes
really
into
play,
is
being
able
to.
You
know,
manage
those
rollbacks.