►
From YouTube: GitLab 15.2 Kickoff - Release
Description
Release 15.2 Planning Issue: https://gitlab.com/gitlab-org/ci-cd/release-group/release/-/issues/132
A
A
So
our
themes
for
for
this
milestone
are
deployment,
approval,
iterations,
instrumentation
and
usability
issues
and
what
that
looks
like
in
terms
of
issues
I'll
go
through
the
p
ones.
Here
are
these
issues
right
here,
so
the
first
one
is
edit
the
number
of
required
approvals
for
deployments
on
settings.
A
So
this
here
is
letting
users
more
easily
configure
the
deployment
approval
feature
so
specifically
setting
the
number
of
approvals
right
now
kind
of
the
workaround
is
users
have
to
unprotect,
unprotected
environment
reprotect
the
environment
set
the
number
of
approvals.
That's
a
little
cumbersome.
We
want
to
make
that
as
easy
as
possible.
If
they
need
to
make
configuration
changes.
A
The
next
one
is
fixing
the
pluma
the
deployment
approval
pop-up
to
support
multiple
approval
rules,
so
we've
been
iterating
on
deployment
approval
functionality.
A
Past
few
milestones,
one
of
the
enhan
iterations
that
we
made
recently
was
to
allow
a
more
complex
approval
structure
so
having
enabling
separation
of
duties
where
one
group
can
trigger
deployments,
and
another
group
can
approve
the
deployments
and
even
beyond
that,
you
could
have
multiple
groups
be
required
to
approve
deployments,
and
so
this
makes
sure
that
our
existing
deployment
approval
functionality
and
the
ui
is
able
to
support
all
those
different
types
of
complex
approval
structures,
all
right,
the
next
one.
A
Next
one
is
actually
related
to
our
releases
functionality
and
feature
in
gitlab,
so
this
one
has
been
around
for
a
while.
It's
part
of
our
release
direction.
It's
it's
highly
requested
from
customers
as
well,
and
what
we
want
to
do
is
enable
editing
of
the
released
at
date
on
right
on
the
release
page.
This
is
currently
available
in
the
api.
This
is
another
iteration
to
make
that
a
little
bit
more
usable
user,
friendly
and
ui
part
of
the
ui.
A
This
actually
raises
some
errors
during
the
environment
update
process,
and
but
it's
a
little,
but
those
errors
happen
a
little
silently
and
we
want
to
raise
more
visibility
as
to
what's
happening
in
terms
of
updating
and
why
it's
failing,
and
so
what
we're?
What
we're
now
going
to
do
is
add
some
soft
validation
to
the
url
so
that
the
user
can
now
see
whether
that
url
might
be
malformed
or
isn't
is
invalid,
and
they
can
take
action
to
make
make
to
make
updates
to
that
and
correct
it
if
needed.
A
A
The
next
one
is
related
to
our
environments
and
in
managing
environments
within
git
lab,
and
so
this
specific
iteration
adds
the
ability
to
to
set
never
as
a
value
for
the
auto
stop
in
parameter
for
environments,
and
so
today
we
let
users
set
a
time
period
for
for
when
those
environments
should
be
automatically
stopped
and
and
our
documentation
actually
specifies
this
and
it
and
and
some
of
our
other
related
types
of
functionality
lets
users
specify
never.
A
It
sort
of
consistent
with
the
rest
of
our
patterns
for
for
this
types
of
this
type
of
configuration
and
also
users.
We
we've
heard
that
users
actually
want
to
be
able
to
do
this,
specify
this
in
the
in
the
yaml
file.
A
Okay,
the
next
one
is,
is
instrumentation,
and
so
we've
we've
released
our
first
iteration
of
our
new
category
called
continuous
verification,
which
is
really
exciting.
A
We
want
to
add
instrumentation
for
that
and
understand
our
initial
usage
and
understand
areas
where
we
can
improve
upon
it,
and
so
this
this
issue
is
instrumenting
that
specific
functionality
where
users
can
use
or
can
add
the
environment
action,
verify
keyword
into
the
animal
file.
We
want
to
track
that
over
time
and
potentially
roll
that
into
our
monthly
active
user
accounts
for
our
different
stages
and
categories.
A
Today
this
token
will
include
when,
when
when
getting
secrets
as
part
of
a
ci
job
will
include
environment
name
if
relevant,
it
will
also
include
whether
the
environment
is
protected.
We've
had
a
request
from
a
customer
recently.
A
It
builds
upon
some
of
the
some
of
the
other
functionality.
We
have
already
to
add
the
environment
here.
Just
so,
the
the
users
have
more
context
about
what
tier
the
relevant
environment,
the
ci
job
is
deploying
to
what
tier
that
is,
and
so
we
want
to
add
that
that,
as
a
parameter
to
the
the
jwt
for
additional
context,
okay,
so
those
are
the
key
ones
just
really
quickly
to
show
we
do
have
quite
a
few
p2s
and
p3s
on
deck
as
well.
B
Yes,
thank
you
chris.
I
also
want
to
talk
a
little
bit
about
the
great
news
right
that
emily
baldwin
will
be
joining
the
release
team
as
a
product
designer
emily's
transitioning
out
from
the
gitlab
growth
team,
and
we're
really
excited
to
have
her
join
release
in
june.
So
looking
forward
to
have
emily
in
the
future
here
with
you
chris
at
the
session,
definitely.
A
B
We
wrapped
up
the
interviews
and
documented
the
inside
t51,
and
we
have
identified
a
handful
of
opportunities
and
pain
points
that
will
be
addressed
in
future
iterations
for
15
2,
we're
going
to
address
the
low
hanging
fruits
with
different
ux
issues,
a
total
of
six
different
design
issues
and
our
research
goal
was
to
validate
if
the
series
of
interface
updates
to
the
environments
page
actually
improve
the
usability
of
our
product
and
also
to
understand
if
the
information
that
was
being
displayed,
there
was
the
most
relevant,
the
most
important
to
our
users
and
why,
after
these
updates,
were
released
and
we're
shipped
to
production,
we
received
some
feedback
from
customers
to
reach
out
about
how
the
changes
were
impacting
their
workflows.
B
And
that's
why
we
did
this
investigation.
You
can
read
the
full
recap.
This
is
a
a
private
confidential
issue
in
gitlab,
but
for
those
that
have
access,
you
can
see
the
insights
and
the
the
documentation
about
our
finance.
B
But
pretty
much,
we
learned
that
the
ui
changes
implemented
in
the
environment
space
received
the
overall
negative
feedback
from
the
study
participants
and
that
the
interface
was
considered
somewhat
difficult
because
participants,
they
didn't,
have
an
at
a
glance
view
of
how
the
deployments
were
doing
if
you're
familiar
with
the
environments
page,
you
know
that
it
shows
a
series
of
collapse
like
accordions
in
the
ui
and
users
have
to
click
multiple
times
to
expand
and
collapse
the
environment
details
they
can
directly
point
their
team
members
to
a
particular
deployment,
etc.
B
So
we
talked
to,
I
think,
total
five,
six
participants
and
the
issues.
I'm
gonna
talk
a
little
bit
about
now,
we'll
cover,
as
I
mentioned,
the
the
top
insights
right.
The
first
one
is
about
search
discoverability
of
for
for
deployments.
B
Several
participants
mentioned
during
the
research
during
the
interviews.
They
will
like
the
ability
to
search
and
filter
for
environments
and
deployments,
compare
versions
of
codes,
see
the
success
deploy
in
previous
environments
and
that
having
a
search
bar
similar
to
what
we
have
now
in
the
issues,
the
merge
requests
and
other
areas
that
get
left
would
be
really
helpful.
B
To
do
that,
because
they
would
be
able
to
quickly
search
for,
for
example,
the
tire
for
deployment
the
production
and
see
who
would
deploy
it
or
who
approved
something
to
a
particular
protective
environment,
etc.
Vlad
is
one
of
our
front
doors.
Back-End
developers
he's
already
working
on
a
poc
for
search
reading
environments,
a
very
simple
search,
and
then
this
milestone
we'll
be
doing
the
broader
ux
proposal.
B
So
what
would
that
look
like
if
we
have
to
consider
all
the
search
tokens
and
what
those
are,
what
we
have
today
in
the
back
end,
etc?
So
we
can
iterate
on
the
design
proposal
and
possibly
break
down
this
issue
into
further
iterations.
B
The
next
issue,
it's
about
the
overall
I'll,
say
usability
in
that
experience
of
the
expand
and
collapsible
pattern
in
the
environments
page.
As
I
mentioned,
we
learned
the
participants
struggle
to
find
the
relevant
information
in
that
collapsible
view
and
hiding
information
could
be
frustrating
what's
frustrating
to
some
of
the
participants,
especially
for
those
that
manage
a
high
volume
of
deployments
at
scale.
So
imagine
you
have,
I
don't
know
over
100
environments
and
you
have
thousands
of
deployments
to
find
information.
B
You
need
you
need
to
click,
expand
and
then
click
again
to
see
more
details,
etc.
We
will
address
some
of
this.
These
concerns
and
one
of
the
main
issues
is
either
understanding
how
this
interface
can
change
and
potentially
removing
that
pattern
of
expand
collapse
from
the
environment
view.
B
The
next
couple
of
issues
also
address
usability
and
discoverability.
The
the
page
is
mission.
It's
missing
also
some
crucial
information
that
talks
about
the
health
status
of
an
environment
of
a
deployment
right
users
want
to
know
how
the
environments
are
doing.
They
want,
especially
to
troubleshoot
field
environments
and
see
the
information
that
connects
that
environment
to
a
pipeline
or
a
job
or
a
merger
class
or
a
git
tag,
and
that
information
is
not
available.
B
Today
we
show
the,
for
example,
the
commit
shop,
but
you
cannot
link
you,
cannot
click
to
go
to
the
commit
page
that
makes
users
have
to
figure
out
how
to
navigate
through
gitlab
and,
for
example,
go
to
the
pipelines
page
to
see
a
complete
list
of
previous.
You
know
deployments
for
an
environment,
but
then
there
they
will
necessarily
see
what
environment
that
commit
was
deployed
to
so
overall
to
be
able
to
manage
environments
and
deployments.
B
B
Those
are
just
the
evolving
intros
that
we
can
work
on
on
a
particular
view
for
the
environment
interface
and
for
the
the
rest
of
the
the
insights
we'll
be
addressing
those
in
the
upcoming
iterations
with
different
design
proposals,
and,
as
I
mentioned
in
the
beginning,
you
can
check
back
the
research
issue
and
find
all
the
actionable
insights
related
to
environment
management
on
that
issue.
A
Okay,
thank
you.
Hyanna.
I'm
really
excited
about
all
of
the
the
research
that
you
do
and
the
results
and
the
feedback
that
we
got
from
our
users
and
all
of
these
actionable
ways
we
can
make
the
products
better.
I
also
want
to
highlight,
as
you
were
talking
about
these,
it
reminded
me
just
how
usability
is
so
important
with
our
product
and
so
in
one
of
our
fy23
product
investment
themes
is
improved,
key
workflow
usability
and
with
the
environments
page
with
these
deployment
workflows.
Those
are.
A
These
are
critical
workflows
for
organizations
making
sure
all
those
are
streamlined.
We
heard
literally
this
morning
from
a
customer
about
one
of
the
main
pieces
of
feedback
is
just
making
sure
things
are
streamlined
and
easy
to
use,
and
so
just
another
reason
these
are
so
important,
so
excited
we're
working
on
these
as
well.
A
Okay,
so
that
is
it
for
15.2.
If
you
have
any
questions,
feel
free
to
reach
out
and
let
us
know
otherwise
see
you
next
month.
Thank
you.