►
From YouTube: Release Stage Vision
Description
Release Stage Product Vision & Direction
A
All
right
well
we're
here
to
talk
about
the
release,
product
vision
and
I'm,
Jackee
Michel,
the
release
management
senior
product
manager
and
we
have
or
eat
the
senior
manager.
Progressive
delivery.
I'll
pass
over
to
hurry
to
talk
a
little
bit
about
where
we
see
our
three-year
target
for
progressive
delivery.
B
Thank
You
Jackie,
so
progressive
delivery
is
I'm.
Gonna,
give
a
little
bit
of
a
background
before
we
jump
into
the
roadmap.
It's
an
it's,
the
natural
continuation
of
continuous
delivery,
so
in
continuous
delivery
we
basically
have
a
potential
to
ship
our
software
at
any
time,
our
softer
purpose
in
production
and
in
progressive
delivery
kind
of
takes
that
and
and
makes
it
smaller.
B
So
the
idea
is,
we
all
want
to
ship
fast
and
and
very
frequently,
and
the
way
to
do
that
is
by
doing
small
increments
of
the
code
instead
of
these
humongous
releases,
where
it
just
takes
so
long
to
develop
something
to
deploy
it
and
then
to
get
feedback
in
the
agile
world.
We
want
everything
smaller,
faster
and
really
fast
feedback.
So
very
similar
doesn't
exactly
that.
You
take
small
bits
of
the
code
and
you
just
take
that
through
the
pipeline
until
it
gets
to
production
and
that
way
it's
more
controlled.
B
You
get
feedback
faster
and
also,
if
there's
some
kind
of
problem,
it's
really
easy
to
roll
back
and
it's
only
a
small
portion
of
the
hook
of
the
code.
So
that's
like
on
the
tip
of
the
iceberg.
What
progressive
the
lorry
is-
and
this
is,
of
course,
a
very
popular
strategy
that
people
use
today,
the
more
people
are
adopting
the
ICT
solutions,
they're
going
into
progressive
delivery
solutions.
B
So
if
I'm
going
to
go
start
going
through
our
list
of
what
we
stated
here
that
we
want
to
do
is
enable
common
deployment
targets
that
just
works
for
those
of
you
who
are
familiar
with
Auto
DevOps,
which
basically
you
press
a
button
and
magically
the
pipeline's
appear,
and
they
do
all
the
different
stages
of
the
DevOps.
That's
basically
do
we
want
you
to
tell
us
we're
deploying
to
kubernetes
or
to
AWS
or
to
Google
Cloud.
Tell
me
one
of
those
targets
and
get
level
just
connect
the
dots
for
you.
B
So
that's
the
big
idea
there
we're
behind
the
scenes.
We
connect
everything
and
the
users
basically
have
very
minimal
configurations
to
do,
and
we
do
everything
for
them.
Of
course,
we
know
that
doesn't
have
to
be
a
cookie
cutter
solution
for
everyone,
so
it's
we're
still
going
to
leave
the
option
to
have
everything
customizable
for
specific
use
cases,
but
the
baseline,
we're
gonna
have
for
our
common
workflows.
B
Do
everything
for
the
user
and
then,
if
anything,
needs
to
change,
anyone
can
do
that
at
any
given
time,
support
mature
organizations,
so
we're
heavily
focused
on
enterprise
customers
and
they
need
to
navigate
through
cross
repository
multi-cloud
complex
releases,
a
bunch
of
stuff.
So
we
need
to
make
this
easy
and
that's
the
idea
behind
that.
You
know
again
connecting
things
making
everything
accessible.
Making
things
easy
to
find
easy
to
access
is
a
main
objective
release.
A
Management
has
a
couple
of
features
that
we're
looking
at
ship
in
the
next
year
that
focus
really
on
this
cross
repository
action.
The
first
of
that
is
supporting
environments
of
the
group
level
being
able
to
have
a
user
share
a
target
environment
across
all
their
projects
will
be
really
empowering
for
them.
A
Today,
users
are
going
into
each
single
repository,
setting
up
their
target,
sometimes
upwards
of
20
targets
in
a
single
gate,
lab
Yamla
file
and
being
able
to
actually
share
that
and
reap
the
benefits
of
what
something
actually
looks
like
in
production
is
the
first
goal
with
environments.
Another
thing
that
we're
looking
to
share
across
is
this
release.
Association
to
group
milestones
so
like
git
lab,
we
are
currently
only
using
group
milestones
for
our
gate,
lab
or,
and
today
were
unable
to
fully
dog
food
that
releases
capability,
as
we
can
associate
it
to
group
milestones.
A
Another
benefit
of
group
milestones
is
being
able
to
take
this
plan
versus
delivery
comparison.
When
you
can
associate
items
to
the
group
you're
able
to
look
at
all
the
projects
in
that
group
across
the
same
single
pane
of
glass,
look
at
your
timelines
and
adequately
compare
what
you've
planned
to
what
you've
delivered
in
the
releases
page.
A
Another
interesting
thing
that
we're
trying
to
do
to
help
support
this
multi-cloud
and
cross
group
cross
repository
action
is
making
rollbacks
more
discoverable,
which
is
the
last
point
on
our
section
Direction
page,
going
back
to
our
three-year
target.
The
next
item
is
about
organically
capturing
changes
per
to
production,
for
compliance
events
or
audit
events.
This
is
really
the
heart
of
our
release.
Evidence
category
and
a
couple
of
the
features
that
we're
looking
to
ship
this
year
and
into
next
year
are
sort
of
increasing
the
value
of
the
release.
A
Evidence
object
by
adding
more
artifacts,
naturally
inside
that
object.
So
the
first
one
that
we're
looking
to
ship
pretty
soon
in
13.1
is
including
test
results
within
release
evidence.
Another
aspect
of
release
evidence
is
being
able
to
empower
different
personas
and
users
to
use
the
tool
and
then
organically
capture
those
those
actions
in
their
release.
Evidence
object,
which
is
nicely
complemented
by
improving
segregation
of
duties
for
operators.
A
This
is
really
the
the
feature
that
we're
we're
going
to
be
uncovering
this
simplification
of
a
centralized
release
management
set
of
gitlab.
Today
many
customers
are
facing
release
management
across
many
different
teams,
sometimes
they're
in
a
get
ops.
World
soget
lab
needs
to
be
a
tool
that
can
support
all
of
those
various
roles,
personas
technical
aptitude
and
skill,
and
be
able
to
effectively
support
that
DevOps
journey
not
only
in
the
web
UI,
but
the
API
and
y
amal.
A
A
Do
you
create
a
release
organically
upload,
the
relevant
assets
and
create
that
release
tag
on
the
releases
page
and
what's
going
to
be
really
cool,
is
that
they
can
then
specify
the
target
environment
as
a
part
of
this
and,
in
the
end,
the
releases
page
will
be
a
great
view
for
what
your
current
production
state
looks
like
another
neat
feature
about
empowering
users
that
are
also
leveraging
the
mo
file
is
being
able
to
execute
code
from
markdown.
This
is
the
heart
of
our
release.
A
This
all
will
help
feed
our
funnel
of
measuring
post
deployment
metrics,
so
ori
actually
created
this
issue,
I'm
hoping
to
deliver
this
issue
this
year,
because
an
analytics
team
is
swamped
and
value
stream
metrics.
This
is
the
release
section
of
value
stream
being
able
to
caption
these
metrics
and
get
lab
and
help
organizations
at
the
highest
level.
A
Directors
executives
track
their
post
deployment
metrics
like
frequency
time
to
restore
service
and
even
failure
rate
all
feeds
into
the
value
that
get
lab
will
empower
people
to
manage
to
another
management
feature
that
we're
helping
to
widen
this
web
UI
experience
for
all
roles
and
get
lab.
Is
the
director
CI
ACD
group
bored
again?
A
This
will
give
people
that
power
to
look
into
their
teams
across
all
projects
and
see
the
key
see
ICD
metrics,
like
percent
of
projects
with
releases
in
the
group's
last
pipelines
in
the
group,
duration
of
the
30
last
pipelines
in
the
group
just
aggregating
those
various
project
metrics
at
that
level,
going
back
to
our
three-year
targets,
you
can
see
that
the
last
item
is
stop
robot
deployments,
which
is
really
a
part
of
the
progressive
delivery
world.
So
I'll
pass
that
back
to
Ori
yeah.
B
Thank
you.
So
this
is
actually
something
that
we're
currently
working
on
and
something
that
I'm
super
excited
about.
So
the
idea
is
that
once
you
deploy
something
to
production,
it's
really
interesting.
It's
really
important
to
monitor.
What's
going
on
there,
and
so,
together
with
our
monitor
team,
we
kind
of
created
a
view
where
you
can
see
the
alerts
coming
in
on
the
environment
pager
on
the
pipeline
and
really
take
action
on
it.
B
So
if
you
see
a
very
problematic
errors,
let's
say
CPU
usage
over
90%
and
you
know
that
this
is
a
problem
and
you
want
to
stop
your
rollout
so
we're
going
to
give
that
option
to
stop
rolling
that
out
or
to
decide
to
even
do
a
rollback,
and
you
can
choose
whether
to
do
this
manual
or
automatically
so
basically
leveraging
everything
that's
already
supported
by
him
up
the
mountain
routine.
Today
we
just
downstream
even
those
alerts
back
to
the
release
stage
and
take
action
on
them.
B
So
we're
really
really
excited
about
that
and
definitely
connect
it
to
progressive
delivery
since
we're
the
whole
point
of
progressive
delivery
is
fast
feedback
and
easy
rollback.
So
there's
a
there's.
Another
point
that's
not
mentioned
here
that
I
do
want
to
talk
about
and
that's
advanced
deployment.
B
So
we
talked
about
the
natively
supporting
the
cloud
when
I
started
talking
and
we
talked
about
the
post
deployment
monitoring,
but
something
that
the
team
is
really
working
hard
on
is
advanced
deployments,
which
is
basically
allowing
users
to
support
different
kinds
of
of
development
methods,
whether
it's
canary
or
Bluegreen,
or
incremental,
rollout
or
others.
We're
going
to
give
the
users
of
flexibility
to
configure
different
kinds
of
annotations
to
enable
that
to
really
give
you
the
entire
flexibility
to
decide
what
you
want
to
do
per
deployment.
A
That
feeds
really
nicely
into
this
whole
enable
common
deployment
targets
as
well,
given
that
people
are
using
a
wide
array
of
multi
cloud
providers
enabling
them
to
roll
out
how
they
want
to
where
they
want
to
is
super
important,
there's
also
sort
of
our
personal
feature
in
the
release
management
stage.
That
I
want
to
kind
of
highlight
here,
which
is
the
pages
functionality,
this
issue
of
supporting
as
I
scroll
up
sorry
about
that
github
pages
without
DNS
wildcard.
A
So
a
big,
highly
uploaded
issue
is
helping
people
set
up
any
sort
of
deployment
to
pages,
and
this
is
one
of
those
features
that
will
help
our
customers
complete
that
successfully.
Another
sort
of
fit
and
finish
feature
for
pages
is
better
redirects,
being
able
to
support
again
any
sort
of
deployment
methodology
and
redirection
and
experience
that
customers
are
trying
to
create
their
static
sites
is
fundamental
to
get
lab
and
the
gate
lab
page
of
strategy.