►
From YouTube: GitLab 15.3 Kickoff - Release
Description
Release 15.3 Planning Issue: https://gitlab.com/gitlab-org/ci-cd/release-group/release/-/issues/148
A
Hey
everyone:
my
name
is
christopher.
I'm
the
senior
product
manager
for
the
release
stage
here
at
the
lab
and
we'll
be
covering
the
release.
15.3
planning
issue
I'll
also
be
joined
later
k-sync
by
hayanna.
A
To
talk
about
design,
so
let's
go
ahead
and
start
with
the
planning
issue,
all
right,
so
the
themes
for
this
milestone
are
working
on
a
few
customer
related
issues,
their
customer
requests
or
things
to
help
support
customers,
roll
out
and
use
and
adopt
a
lot
of
our
features.
A
Next
is
enhancements
related
to
group,
protected
environments
and
that
functionality
and
kind
of
permissions
related
to
that,
and
then
also
continuing
our
work
on
declining
approvals
and
iterating
on
that,
and
so
in
terms
of
p1
issues.
A
We've
got
a
bunch
as
you
can
see
here,
and
so
let's
go
through
those
the
first
one
here
is
authentication
type
and
audit
events
for
deploy
keys.
So
we
currently
have
this
for
deploy
tokens,
but
we
have
a
customer
request
and
we
want
to
make
sure
that
functionality
applies
also
to
deploy
keys.
So
the
idea
here
is
that
we're
adding
deploy
keys
as
a
type
as
an
audit
event
type
in
the
streaming
in
the
streaming
audit
events
service
that
we
have
the
next
one
here
is
showing
the
deployment
approval
comment.
A
Ui,
I'm
really
excited
about
this
one
and
we've
we've
been
doing
a
lot
of
iterations
and
we've
seen
great
adoption
deployment
approvals,
and
so
we
now
allow
users
and
operators
of
those
those
folks
in
charge
of
approving
deployments
to
environments
to
leave
comments.
Now
we
want
to
display
those
comments
in
the
environments
page
and
the
ui
so
that
others
developers
others
other
folks
related
to
deployment
can
easily
see
it
and
auditors
as
well,
and
the
next
one
is
showing
upstream
group
level
protected
environments
in
the
project
page,
and
so
this.
A
What
this
really
enables
users
is
easy
visibility.
If
and
if
higher
level
loop
environments
are
being
protected,
and
so
they
understand
kind
of
a
hierarchy
of
how
group
group
environments
will
be
protected
versus
project
levels
and
so
there's
a
screenshot
of
what
that
will
look
like.
So
here
we
have
a
user
looking
at
a
project
and
looking
at
the
protected
environment
settings
you
can
see
at
the
bottom
of
this.
This
modal
environment
is
protected
upstream,
so
they
can
again
at
a
glance,
easily
see
what's
protected
by
a
higher
level.
A
The
next
one
is
just
making
sure
that
our
permissions
are
consistent
across
api
and
and
the
ui,
and
so
we'll
be
working
on
a
proposal
to
make
sure
that
the
api
permissions
are
for
changing
group
environment
settings
are
for
owners
for
the.
A
Commissions,
the
the
next
one
that
we
have
here,
we're
going
to
talk
about
is
controlling
visibility
of
deployments
related
functionalities.
So
we've
implemented
a
lot
of
recent
changes
to
the
navigation
and
sort
of
the
hierarchy
and
different
pages
and
what
we
call
them,
and
so
this
is
bringing
consistency
to
the
settings
with
what's
been
changed
in
the
actual
navigation.
So
now
that
we
have
a
whole
section
related
to
deployments,
we'll
want
to
control
the
visibility
and
the
enablements
of
those
features
in
a
consistent
way.
A
Is
another
tech,
deck
kind
of
maintenance
type
feature
so
fix
n,
plus
one
environment
serializer
we
got
this
about
a
month
ago
and
we
want
to
just
make
sure
that
we're
keeping
our
tech
tick
down
and
the
next
one
here
we
have
is
allowing
to
complete
delete
deployments
by
api
right
now.
This
finale
doesn't
actually
exist.
A
A
The
last
feature
that
we'll
talk
about
today
is
it's
actually
a
dog
fooding
feature.
I'm
really
excited
about,
so
I've
been
collaborating
with
farnoosh
and
brian
from
the
product
operations
team,
and
the
idea
is
that
to
dog
food
and
use
a
lot
more
and
extend
a
lot
more
of
our
releases
feature
and
use
that
as
part
of
our
internal
management
and
marketing
and
release
counts
process.
A
So
the
first,
the
very
preservation
is
just
making
sure
actually
that
we
bring
content
parity
to
the
information
that
we
have
in
the
releases
page
in
our
gitlab
project.
So
you
want
to
take
all
the
rich
information,
that's
currently
being
written
by
our
product
managers
and
then
publish
to
the
the
release
blog
post
that
we
have
each
month
and
start
to
populate
our
release.
A
Notes
for
each
of
the
gitlab
releases
that
we
have
for
the
project
into
the
release,
notes,
section
and
so
excited
for
this
and
future
iterations
and
making
sure
that
we
bring
more
functionality,
usability
and
dog
through
more
of
our
own
releases
feature
for
our
release,
release,
notes
and
release
process
all
right
and
that's
it
for
the
p1
milestones.
I'm
going
to
turn
it
over
to
emily
hyanna
to
talk
about
sound
work.
B
All
right,
so
we
are
here
to
talk
about
the
planning
for
designers,
research
for
the
release
group.
Today,
I'm
I'm
with
the
emily
balman
she's
the
new
product
designer
for
release
and
emily.
Maybe
you
want
to
talk
a
little
bit
about
yourself
and
also
what
you're
going
to
be
working
on
in
your
first
map
song.
C
Yeah
hi
everyone,
my
name
is
emily
and
I'm
the
new
product
designer
on
release.
I
joined
the
team
about
almost
a
month
ago.
Now
I
came
over
from
the
growth
team,
so
I
spent
my
first
few
weeks
really
onboarding
getting
to
know
the
team
and
53
is
when
I'll
actually
be
able
to
jump
into
some
work,
so
really
excited
for
that.
So
my
first
task
that
I'm
doing
for
15
3
I'll
just
share
my
screen.
C
If
I
can
find
where
it
is
this
one
right
I'll
be
doing
a
job
to
be
done
for
release
orchestration.
So
I'm
really
going
to
be
focusing
on
this
for
the
first
part
of
15,
3
and
kind
of
using
this
as
a
jumping
off
point
to
really
get
the
knowledge.
I
need
to
start
working
on
some
issues
as
well.
So
my
goal
for
this
is
really
to
go
through
all
of
our
existing
research
to
write
up
two
jobs
to
be
done.
C
We
have
a
ton
of
research
around
release
orchestration
so
just
watching
through
some
interviews,
reading
through
all
the
stuff
we
have
already
and
then,
if
needed,
reaching
out
to
internal
get
lab
team
members
to
further
validate
our
job
to
be
done.
So,
as
I
said,
this
will
give
me
a
great
window
into
release
orchestration
and
help
be
really
good,
jumping
off
point
for
some
other
issues,
but
yeah.
This
will
be
kind
of
my
first
issue,
I'll,
be
working
on
and
I'll
pass
it
over
to
hyanna.
B
Thank
you
so
much
emily
really
excited
to
have
that
job
to
be
done
for
release
orchestration
drafted
so
that
we
can
use
it
right
as
a
part
of
the
maturity
plan
for
this
category.
So
it's
really
really
awesome
I'll
start
sharing
my
screen
now.
So
I
can
talk
about
the
other
ux
deliverables
for
this
milestone.
So
this
is
our
planning
issue
and
then
for
design
and
user
research.
B
Our
team
worked
on
the
poc
for
that
a
couple
of
milestones
ago,
both
back
in
the
front
end
right
so
to
allow
users
to
be
able
to
retrieve
the
title
like
the
name
of
a
given
environment
in
the
environments
page
and
that's
helpful,
because,
especially
for
organizations
that
have
a
high
volume,
a
high
number
of
environments,
it's
really
difficult
to
find
a
particular
item
and
to
understand,
like
the
health
status
of
that
environment
and
its
deployments.
B
So
in
1503
we,
I
wrapped
up
the
the
design
proposal
and
worked
with
the
team
to
refine
it.
We
have
the
the
proposal
for
that
that
would
still
include
only
the
ability
to
search
for
a
specific
environment
name,
but
in
the
future
we
also
want
to
explore
how
users
can
filter
right
for
environment,
for
example,
by
the
trigger
or
by
the
status
of
the
latest
deployment
and
etc.
B
So
that's
a
one
small
step
towards
the
iteration
and
it
will
help,
as
I
say,
organizations
and
the
the
users
that
need
to
manage
the
environments
and
deployments
to
just
quickly
find
the
tasks
and
the
items
that
need
the
most
attention.
B
Next
up
is
linked
to
the
deployment
pipeline
from
the
environments
page.
This
is
also
an
item
that
it's
actionable
insight
from
the
research
and
the
user
interviews.
I
did
a
couple
of
milestones
back
and
then
this
the
scope
of
this
is
also
very
small,
but
it
would
allow
us
to
link
to
that
particular
pipeline
in
the
environment's
overview
right
for
a
particular
deployment.
B
That's
because
you
know
the
what
we
showed
today
in
the
ui
seems
to
be
clickable,
but
it's
not
it's
something
like
this
like
this,
a
badge
that
is
green,
that
confuses
users,
because
in
the
pipelines
view
they
can
actually
on
the
merge
request,
view
or
issues,
they
can
actually
click
on
that
pipeline
badge
and
then
go
to
the
pipeline
page,
but
also
users
want
to
be
able
to
navigate
back
and
forth
within
gitlab
to
understand
how
that
deployment
that
environment
is
doing.
B
So
that's
a
front-end
task
as
well,
and
then
next
up
is
keeping
the
expanded
state
for
the
details
in
the
environments
page.
I
also
talked
about
this
item.
We
had
more.
We
had
a
chance
to
refine
this
one
recently
and
instead
of
keeping
everything
expanded,
that
was
the
scope
of
the
initial
issue.
We
are
now
only
going
to
remove
the
show
details
button
in
the
in
the
environments
page,
so
I'll
quickly
show
you
how
that
works
right.
B
So,
in
the
environment
view
everything
is
collapsed,
but
when
you
open,
for
example,
a
particular
environment
in
this
case
cannery
there
is
this
show
details
button
here.
That
is
just
an
additional
click
right.
There's,
no,
really,
a
reason
why
we're
hiding
this
content
so
we're
gonna,
get
rid
of
that
and
that's
what
the
design
proposal
is
about,
so
that
users
have
a
better.
B
You
know
overview
of
the
data,
while
we
continue
to
iterate
on
some
design
proposals
for
improving
the
overall
usability
and
also
the
interface
of
this
page
next
still
on
environments,
but
in
this
case
text
we
have
this
issue,
it's
a
it
has
a
higher
number
of
upvotes.
If
I'm
not
mistaken,
that's
right,
that
is
about
showing
the
tags
related
to
the
deployment
on
the
environments
view.
We
have
discussed
this
one
extensively.
It's
also
an
actionable
insight.
B
We
also
learn
right
from
the
user
interviews
that
people
want
to
have
a
way
to
see
which
tags
are
related
to
that
particular
deployment
to
that
particular
environment
and
we're
going
to
work
on
the
ui
proposal
to
make
sure
that
you
know
whatever
we
add
here
to
the
interface,
it's
usable
and
it's
discoverable
to
users
right
now.
B
This
description,
it's
quite
old,
git
labs
interface,
doesn't
even
look
like
this
anymore
and
we
just
need
to
look
at
it
and
see
what
patterns
we
want
to
apply
here
and
also
how
we
want
to
work
on
a
version
right
and
that
we
can
change
later
on
without
completely
in
a
way
having
to
redesign
that
view,
because
the
views
are
different
and
we
know
already
that
this
environment's
view
here
needs
more
updates
right.
It
needs
to
be
changed.
B
The
second
last
issue
is
about
linking
to
the
deployment
commit
from
the
environments
page.
We
already
do
that
today,
I'm
gonna
scroll
down,
there's
a
comment
here
by
andrew
that
we
do
show
in
the
in
the
environment
to
detail
that
you
know
that
branch.
B
Sorry,
the
commit
message
as
a
link
to
the
commit,
but
that's
we
learned
from
the
usability
interviews
that
information
is
not
useful
to
people,
because
usually,
if
you're
merging
something
to
master,
that's
just
going
to
be
like
that
a
default
copy,
a
default
message
as
in
emerging
something
to
master
right,
and
then
we
also
show
the
shot
here
of
a
particular
commit
that
is
not
clickable.
So
this
issue
is
about
designing
that
experience
and
understanding
how
we
can
better
show
and
display
that
information
without
creating
noise
and
adding
more
noise.
B
To
that
view,
and,
lastly,
show
the
deployment
approval
comment
in
dui.
That's
a
a
very
important
issue.
Right
we've
been
talking
about
environments
and
management
with
the
other
issues,
and
this
one.
Now
it's
about
deployment
approvals.
So
we
have
the
ability
today
to
add
comments
when
approving
or
rejecting
a
particular
deployment.
But
you
cannot
see
the
comment
anywhere
in
the
ui.
B
So
in
this
proposal
we
are
discussing
where
and
how
we
are
going
to
display
that,
while
keeping
in
mind
how
we
want
to
continue
to
iterate
and
expand
on
the
experience
of
the
environment's
environment
view
and,
of
course,
that's
a
very
important
issue,
because
for
teams
that
have
deployment
approval
set
right
for
protected
environments,
they
need
to
see
who
approved
what,
when
and
also
have
access
to
that
information
so
that
they
can
be
informed
about
the
decisions.
B
So
that's
that
a
lot
of
ux
a
lot
of
ux
front-end
issues
and
improvements
and
also
usability
changes
to
the
environment
stage,
and
I
think
that's
that.
Thank
you
emily
for
joining,
and
I'm
excited
to
continue
to
work
with
you
yeah
me
too.
Thanks
for
having
me.