►
From YouTube: Release stage FY22 Roadmap
Description
Release stage FY22 Roadmap
Issue to follow: https://gitlab.com/gitlab-com/Product/-/issues/1906
A
Hi
today
I
wanted
to
walk
through
our
road
map
that
we
have
planned
for
this
year
for
this
fiscal
year
and
if
you
want
to
follow
along,
I
the
issue
is
located
on
the
under
the
product
project
issue
number
1906
and
the
title
is
release
stage.
Fy22
roadmap
and
the
idea
around
this
epic
or
issue
is
that
it
kind
of
gives
the
high
level
picture
of
what
the
team
is
going
to
work
on
this
year.
A
So
I'm
going
to
walk
through
this
issue
and
kind
of
give
a
high
level
picture,
and
if
anyone
has
any
feedback
or
questions
or
remarks,
feel
free
to
reach
out
to
me.
So,
let's
start
with
continuous
delivery.
So
continuous
delivery
is
the
main
pillar
of
the
release
stage
and
that's
why
the
largest
chunk
of
the
work
is
there.
It's
also
organized
by
priority.
A
A
A
I
wanted
to
just
quickly
show
the
figma
file
that
describes
what
we
want
to
do
and
accomplish
for
the
mvc
okay.
So
we
have
it
here
in
this
issue
and
what
we're
we
want
to
have
is.
Basically,
we
started
off
with
adding
all
the
metrics
to
ultimate,
but
we're
gonna,
slowly
kind
of
open
that
up
some
additional
tiers.
A
So,
let's
start
with
core
or
whatever,
when
you
go
under
analytics
ci
cd,
you'll
you'll
be
you'll,
be
met
by
this
new
tile,
which
is
not
above
the
pipeline
graph
that
already
exists,
and
this
tile
we're
taking
it
from
what
value
stream
analytics.
Already
provided-
and
it's
already
supported
in
gitlab
and
what
we'll
see
is
a
numerical
value
for
each
one
of
the
metrics
and
that's
it
for
premium.
What
we
wanted
to
do
was
add
the
same
data
that
we
have
for
the
core
users.
A
A
You
can
toggle
with
the
with
the
dates
displayed
for
the
mvc.
This
is
going
to
be
hard
coded
one
day,
we'll
open
this
up
and
allow
this
to
be
user
customized.
But
at
the
moment
it's
going
to
be
hardcoded
to
these
dates
and
each
of
the
charts
represents
a
different
metric,
but
one
chart
and
you
can
toggle
through
the
different
timestamps.
A
And
then
for
ultimate
the
the
idea
is
that
we
have
all
the
metrics
that
we
have
for
core
and
for
premium,
but
now
we're
also
aggregating
it
to
the
group
level.
So
if
you
saw
here
this
is
on
the
project
level,
the
project
level
will
also
be
available
for
ultimate,
but
this
will
also
be
available
on
the
group
level,
because
usually
the
persona
that
we're
targeting
here,
which
is
the
executive,
wants
to
see
overall
all
the
different
projects
in
the
organization
and
comparing
them
one
to
the
other.
A
A
A
Okay,
another
thing
that
we've
discovered
was
that
there's
a
lot
of
potential
for
people
to
use
cd
features
in
gitlab,
but
they
aren't
there's
about
twice,
if
not
more
users
that
are
using
ci
but
do
not
continue
the
cd
cd
journey
through
gitlab.
So
what
we
wanted
to
do
is
kind
of
add
little
breadcrumbs
and
hints
and
guidance
throughout
the
the
way
to
help
users
discover
the
cd
features.
So
there's
an
epic
called
increased
discoverability
for
cv
features
epic
number
5239.
A
These
are
the
issues
that
are
currently
there
but
we'll
probably
add
more
throughout
the
year.
Just
for
a
general
idea.
What
we
wanted
to
do
was
kind
of
figure
out
who
are
the
users
that
have
a
pipeline
that
don't
end
up
with
a
production
environment
or
don't
have
deploy
job
and
kind
of
just
help
them
out
and
say:
hey,
we
noticed
you
don't
have
deployments,
why?
Don't
you
try
adding
them
by
either
linking
the
documentation
or
giving
them
snippets?
A
Also,
if
anyone
on
the
team
has
ideas
on
where
we
can
add
additional
guidance,
please
feel
free
to
open
these
issues
and
link
them
here.
Some
of
the
ideas
were
in
the
pipeline
view.
Some
are
in
the
yaml
editor,
but
there
can
be
more
so,
for
example,
even
dora
4.
If
we
see
that
deployment
frequency
is
rather
low,
we
can
also
help
help
hint
to
the
users,
maybe
to
drop
manual
approvals
or
so
on.
A
A
This
is
becoming
a
wider,
wider
trend
in
the
industry
and
we
as
gitlab
should
be
able
to
support
this
pretty
nicely.
So
my
first
attempt
is
to
understand
the
pain
points
that
the
users
have
and
then
try
to
find
solutions
for
them.
So
I
I
assume
this
will
be
in
the
second
half
of
the
year
that
we'll
work
on
this,
but
it's
definitely
an
important
topic
to
tackle
a
group
level
resource
group.
A
So
last
year
we
added
something
called
resource
group
which
allows
you
to
limit
the
amount
of
consecutive
deployments
that
you
have
to
a
specific
target.
This
is
extremely
useful
when
you
have
a
physical
device
that
you're
deploying
to,
and
you
can't
have
multiple
deployments
going
to
the
same
physical
device
at
one
time,
and
so
you
limit
the
concurrency.
A
It
was
a
highly
requested
feature
and
people
were
really
happy
that
we
added
it,
but
what
they
still
asked
was
to
have
the
support
on
the
group
level,
because
many
projects
sometimes
deploy
to
the
same
device,
and
so
the
project
level
lock
wasn't
good
enough.
So
we
want
to
expand
it
to
the
group
level
as
well.
A
Auto
manual,
environment,
freeze,
I'm
really
excited
about
this,
but
this
is
the
next
steps
to
our
last
year's
theme
of
post-deployment
monitoring.
We
ended
up
with
the
really
exciting
feature
for
auto
rollback.
In
case
the
environment
gets
an
alert.
This
is
a
different
concept
where
we
want
to
do
an
environment
freeze,
so
this
could
be
either
automatically.
So,
if
there's
some
kind
of
alert,
we're
automatically
going
to
freeze
the
environment
and
not
let
you
do
the
following
actions:
they
are.
A
Either
canceling
any
future
deployment
that
it
won't
allow
you
to
do
any
future
deployments
to
this
environment.
That
includes
also
incremental
rollout
or
canary
it'll
freeze,
any
toggle
for
of
feature
flags
in
this
case,
unless
the
freeze
is
lifted,
and
the
idea
is
that,
if
there's
an
alert
and
someone
needs
to
debug
the
environment,
we
don't
want
more
interference
of
unknowns
like
a
feature
flag
being
toggled
or
another
deployment
rolling
out
the
person,
the
sre
who
is
debugging.
A
That
was
in
case
of
automatic,
but
there's
there's
also
a
really
nice
use
case
of
doing
this
manually.
So
today
we
support
deployment
freezes,
for
example,
under
the
project
settings,
but
it
is
heavily
reliant
on
chrome
jobs,
so
you
have
to
be
planned.
You
have
to
plan
for
deployment
freeze
during
christmas
or
or
during
the
weekend
here.
This
lets
you
manually
take
action.
If
something
is
wrong
with
environment,
you
can
just
freeze
an
environment
unplanned
check
out
whatever
you
need
to
do
and
then
unfreeze
it.
So
this
is
a
really
interesting
concept.
A
A
A
Three
seven,
nine
eight
and
the
idea
here
is
to
introduce
the
advanced
deployments
canary
blue
green
for
non
kubernetes
users.
Today,
advanced
deployments
in
github
are
supported
only
for
kubernetes
users,
but
the
way
that
we
built
the
aws
deployments
allows
us
to
also
utilize
some
of
the
aws
features,
and
so
we
don't
really
have
to
create
something
new.
A
A
But
what
we
do
want
to
do
is
take
the
best
of
both
worlds
and
create
a
really
nice
experience
for
users
using
feature
flags.
So
what
and
what
did
come
up
with
the
solution?
Validation
that
we
did
in
this
issue
was
that
a
lot
of
the
metadata
that
the
issues
have
are
really
useful
for
future
flags
as
well,
and
that's
what
we
want
to
bring
and
let
the
users
use
and
benefit
and
collaborate
on
in
features.
A
A
Attributes
in
the
solution,
validation,
so
people
thought
that
this
could
really
easily
make
let
them
collaborate
with
their
team
on
feature
flags,
and
so
that's
really
really
great
and
something
that
will
definitely
bring
in
labels
and
and
being
having
a
way
to
easily
find
features.
Feature
flags
was
something
that
that
people
really
liked,
and
so
I
think,
what
we'll
start
doing
is
just
slowly
incrementally
adding
these
attributes
without
actually
making
it
an
issue
type.
A
Yeah,
the
next
issue
is
contextual
code,
references
for
future
flags,
and
this
one
is
also
a
super,
exciting
feature.
What
this
does
is
it
really
connects
feature
flags
nicely
to
the
code.
So
if
you're
already
using
the
lsm
you
and
you're
using
gitlab
future
flag,
you
probably
had
to
create
a
connection
to
the
code
to
make
this
feature
flag
work.
A
A
A
Basically,
it
creates
an
auto
change
log,
based
on
any
change
that
you
did
in
the
project,
based
on
the
release
tag,
a
milestone,
that's
connected
connected
to
it
all
the
commits
can
automatically
go
into
the
release
notes.
This
is
something
that
we
can
use
both
internally
when
creating
releases
in
gitlab,
but
also
our
customers
can
use
group
level
environments
and
improve
environments,
they're
kind
of
coupled
together.
So
I'm
going
to
talk
about
improved
environments.
A
A
Environments
are
usually
connected
on
the
on
the
issue
level.
So,
if
you
go
here
to
environments,
you
have
them
on
the
on
the
project
level.
Excuse
me
and
not
on
the
group
level,
but
environments
usually
span
across
a
lot
of
things.
So
that's
kind
of
connected
to
the
group
level
environment
that
was
mentioned
here,
but
not
only
for
that.
What
we
want
to
do
is
we
want
to
face
lift
environments
as
a
whole.
A
So,
first
of
all,
we
want
to
create
a
first
class
concept
for
for
environments,
and-
and
this
is
not
even
a
front-end
issue,
but
just
kind
of
adding
to
the
yaml
syntax
a
type,
so
you
can
define
the
type
of
the
environment
without
being
stuck
to
a
name.
There's
a
naming
convention
that
we
kind
of
decided
that
all
production
environments
are
called
production,
but
even
internally
in
gitlab
our
production
is
called
gprd,
and
so
a
lot
of
the
features
that
are
leaning
on
this
naming
convention
won't
work
for
us
as
gitlab.
A
So
we
want
to
make
it
really
flexible
for
users
to
be
able
to
call
their
production
environments
whatever
they
want.
Sometimes
there's
more
than
one
environment,
and
so
we
have
a
lot
of
things
tied
to
that,
like
value
stream,
analytics
dora
for
feature
flags
even
and
more,
and
so
we
want
to
kind
of
give
the
users
the
ability
to
define
it
there.
However,
they
want
and
tag
it
there.
However,
they
want
with
this
type
and
that
might
also
bring
the
environment
page
itself
to
be
more
useful.
A
So
just
for
example,
when
you
open
the
gitlab.org
project
and
you
look
at
environments,
you
can
automatically
see
that
the
first
thing
that
you're
greeted
with
is
review
apps,
and
so
you
have
a
ton
of
short-lived
environments
that
are
at
the
top
of
the
page,
whereas
the
more
interesting
environments
are
in
the
bottom.
So
there's
a
shift
that
we
can
do
here
at
a
glance.
It's
really
hard
to
understand
what
your
production
environment
is,
so
we
won't
want
to
make
it
so
that
you
can
indicate
it.
A
I
also
want
to
make
make
it
available
to
create
your
favorite
environment,
so
they're
at
the
top,
and
also
kind
of
link
this
to
our
environment
dashboard,
which
is
really
interesting,
because
we
have
two
different
pages
that
are
called
environments
and
they
do
different
things
and
they're
not
even
propagated
from
one
to
another.
So
I
want
them
to
talk
to
each
other
and
kind
of
made.
A
It
make
it
a
better
experience
for
anyone
using
environs,
making
it
really
easy
to
get
to
an
environment,
understand
what's
going
on
in
the
environment,
at
a
glance,
and
so
the
this
epic
here
35304
has
some
ideas
on
how
we
can
kind
of
make
this
experience
better.
But
if
you
have
more
ideas,
feel
free
to
open
them
and
and
link
them
here
to
the
to
the
epic.
A
This
is
really
great,
not
only
because
it
makes
the
experience
better
on
the
ux
better.
It
also
can
help
more
people
on
board
and
use
environments
in
gitlab,
as
I
mentioned,
it
can
unlock
the
terraform
use
case
and
so
on.
So
this
is
a
really
important
thing
to
work
on.
It
involves
a
lot
of
the
stages
as
well,
because
everyone
uses
environments,
whether
you're
using
ci,
whether
you're
using
configure
also
for
monitoring
purposes.
It's
really
important
to
know
which
environment,
you're,
monitoring
and
and
why
so,
this
kind
of
touches
around
everything
in
the
product.
A
So
there's
a
lot
of
impact
here
and
any
anything
that
we
can
do
here
to
make.
The
experience
better,
I
think,
is
a
huge
win
for
gitlab
next
is
pages.
So
pages
is
a
really
important
effort
that
we're
currently
doing
the
infrastructure
work
that
we've
been
working
on
for
over
a
year,
it's
kind
of
in
its
home
stretch
and
so
we're
completing
the
migration
from
object,
storage
from
gitlab.com
from
nfs
to
object,
storage
and
we're
gonna
move
on
to
self-managed.
A
Now
I
didn't
write
here
a
direction
yet
for
pages,
even
though
there's
a
ton
of
work
that
we
have
to
do
in
pages,
because
the
effort
of
the
infrastructure
is
so
large
that
we,
I
kind
of
just
want
to
complete
that,
and
then
we
can
talk
about
other
things
that
we
need
to
do
for
pages
pages
has
so
many
issues
in
the
backlog
with
so
many
upvotes
that
there's
just
so
much
that
we
can
do
here.
I
promise
to
follow
up
with
the
page's
direction.
A
A
A
So
we
also
added
another
check
that
that
would
be
only
also
on
including
the
create
date
and
not
only
the
deploy
date,
but
that's
only
proactive
for
new
environments
that
were
created
for
old
environments
that
we
didn't
have
that
keyword,
they're
still
stuck
in
the
system,
and
it's
really
really
hard
to
clean
them
up.
So
I'm
going
to
go
back
to
our
example
from
before.
This
is
what
the
environments
page
looks
like
for
gitlab.com,
and
you
can
see
here.
A
The
last
commit
so
they're
inactive
they're
in
the
system,
but
there's
really
no
easy
way
to
clean
them
up.
So
what
we
wanted
to
do
is
introduce
a
way
to
clean
them
up,
maybe
by
selecting
all
and
then
do
clean
up
or
maybe
selecting
a
date
and
then
selecting
cleanup.
But
in
any
case
this
is
a
problem
both
in-house
and
out
and
also
for
our
external
customers.
So
we
just
want
to
make
this
experience
easy
and
let
give
people
a
way
to
remove
their
inactive
review
apps.