►
From YouTube: GitLab 13.7 Kickoff - Release:Release
Description
GitLab 13.7 Kickoff - Release:Release
https://gitlab.com/gitlab-org/ci-cd/progressive_delivery/-/issues/26
A
Hi,
my
name
is
enrique
lewinsky
and
I'm
the
senior
product
manager
for
the
release
date
here
at
gitlab.
Today,
I
want
to
walk
through
some
of
the
issues
that
we
have
planned
for
the
13.7
milestone.
You
can
walk
along
and
view
it
with
me.
It's
issue
number
26
under
the
progressive
delivery
project.
It's
called
release,
13.7
planning
issue.
So
let's
get
started.
A
You
can
see
here
all
the
top
priority
deliverables
that
we're
going
to
start
working
on
so
the
first
one
that
I
want
to
talk
about
is
called
chill
deployment
status
in
the
environment
page
today,
when
you
look
at
the
environment
page
there's
no
way
for
you
to
know
what's
going
on
with
your
deployment.
So
what
we
want
to
do
in
this
milestone
is
add
that
status
for
you.
A
So
we're
planning
on
adding
a
bunch
of
diff
all
the
door,
four
metrics
under
different
areas,
so
that
you
can
view
it
both
in
the
project
level
and
the
group
level,
and
even
in
the
instance
level-
and
this
is
the
first
thing
that
we're
doing
is
adding
api
support
for
deployment
frequency,
so
deployment.
A
Frequency
is
how
often
you
deploy
to
production
from
your
project
and
that's
the
information
that
we
already
have
in
gitlab,
and
we
want
to
bring
that
and
have
it
available
for
all
for
all
the
users
and
the
first
step
is,
is
actually
supplying
this
for
api.
So
you
may
want
to
bring
this
information
into
another
tool,
and
this
is
also
going
to
be
the
base
for
our
implementation
of
the
ui.
A
I'm
going
to
show
you
a
sneak
peek
of
what
this
is
supposed
to
look
like
at
the
end
for
you
to
see
exactly
the
quantum
frequency
on
the
project
level.
So
today,
under
ci
cd
analytics
on
the
project,
you
can
see
the
pipelines
and
we're
adding
the
ability
to
to
also
see
the
deployment
frequency.
So
you
will
have
different
tabs
for
pipelines
and
different
types
of
deployments,
and
you
will
be
able
to
toggle
between
them
and
see
your
deployment
frequency
for
the
last
week
last
month
and
last
year.
So
really
really
excited
about
that.
A
And
then
our
next
issue
that
I
want
to
talk
about
is
called
set
deployment,
traffic
weight
via
ui
and
the
previous
milestone.
We
worked
on
setting
the
deployment
deployment
traffic
via
api.
So
today,
if
you're
using
canary
in
gitlab,
you
control
the
the
weights
and
the
rollout
through
the
yaml
file
in
the
previous
milestone,
we
added
the
ability
to
control
this
external
to
the
ammo
through
the
api
and
we're
really
excited
to
follow
through
with
also
adding
this
in
the
ui.
A
A
It's
for
segregation
of
duties,
that,
if
there's
a
maintainer
that
is
not
allowed
to
deploy
to
production
or
to
a
protected
environment,
they
should
also
not
be
able
to
add
or
remove
environments
to
project
and
override
that
ability.
So
what
we
want
to
do
here
is
we're
we're
going
to
start
implementing
it,
and
this
milestone
is
allowing
the
configuration
or
setting
to
actually
prevent
this
from
happening
and,
as
I
mentioned,
we're
going
to
start
with
api.
A
As
part
of
our
dora
4
metrics
that
we
discussed,
we
also
understand
that
seeing
these
metrics
on
the
project
level
our
only
partial
solution
for
this-
and
we
understand
that
the
next
level
up
is
to
see
all
the
metrics
on
the
group
level.
So
what
we
want
to
do
is
introduce
the
cicd
analytic,
analytics
navigation
at
the
group
level
and
not
only
on
the
project
level
like
it
appears
today
so
again
really
excited
about
all
the
door.
Four
metrics
coming
together
and
taking
shape
here
in
gitlab.
A
The
next
issue
that
I
want
to
discuss
is
show
aws
deployment
success
code
in
blogs,
and
the
idea
behind
this
is
that,
instead
of
having
a
user
toggle
between
different
tools
to
understand
the
status
of
the
deployment,
we're
going
to
bring
all
the
deployment
information
into
gitlab
itself,
so
if
you're
doing
a
deployment
of
aws
through
gitlab,
you
will
also
be
able
to
get
the
error
or
success
information
in
the
git
lab
itself.
So
you
don't
have
to
go
to
an
external
tool.
A
So
a
few
milestones
ago,
we
added
the
ability
to
run
forked
projects
in
the
parent
pipeline
by
requesting
someone
with
appropriate
permissions
to
do
that,
for
you,
and-
and
this
is
what
it
looks
like
today-
so
there's
really
not
enough
information
for
you
to
understand
which
pipeline
you're
looking
at
or
where
it
actually
ran,
was
it
in
the
parent
or
was
it
in
the
fork.
A
So
what
we
want
to
do
here
is
actually
add
this
new
information,
so
you
can
see
there's
a
new
badge
that
tells
you
that
this
has
run
in
the
fork
project
and-
and
you
can
understand
from
there.
So
that's
all
for
me
today.
I'm
really
really
excited
about
this
release
and
being
able
to
start
working
on
all
these
cool
features.
As
always,
if
you
have
any
feedbacks
or
comments,
please
ping
me
on
the
issues
or
email
me
at
olgowinski
at
github.com,
and
I
will
see
you
next
time.
Thank
you.