►
From YouTube: Release 3-year Mocks
Description
We have been working to create a visualization of the Release Three Vision - which is captured in this direction page (https://about.gitlab.com/direction/ops/#release). As an overview, we have three primary goals: Offer a market leading progressive delivery solution, Automatically deploy to any environment, and support complex cross project releases for the entire lifecycle of release - from creation to audit.
A
A
What
we'll
show
you
today
is
not
at
all
a
commitment
of
what
we're
going
to
be
delivering
in
three
years,
but
it's
definitely
something
that
we
want
to
directionally
accomplish
with
our
collective
teams
between
progressive
delivery
and
release
management
as
an
overview,
we
have
three
primary
goals
that
we're
trying
to
accomplish
in
the
release
stage.
First,
we
want
to
offer
a
market
leading
progressive
delivery
solution.
A
Second,
we
want
to
automatically
deploy
to
any
device
in
any
environment,
and
we
also
want
to
support
complex
cross
project
releases
for
the
entire
life
cycle,
of
a
release
from
creation
to
audit
and
everything
in
between.
First
up
in
this
flow
of
our
three-year
mocks.
Is
arie
she'll
be
walking
us
through
the
idea
of
automating
rollbacks
with
run
books.
B
That's
a
good
idea,
jackie.
So
let
me
just
repeat
these:
these
mock-ups
are
available
under
the
release
section
under
ops
under
the
vision,
general
vision.
You
can
find
the
mock-ups
that
we're
talking
about
here.
I'm
gonna
just
do
a
full
screen,
so
everyone
can
see
it
and
if
you
need
to
go
back
after
this
and
look
into
it,
then
feel
free
to
do
that.
So
the
first
thing
that
we
want
to
talk
about
is
this
email
notification
that
you
will
be
receiving
in
case
deployment
has
automatically
rolled
back
now.
B
B
You
can
then
go
ahead
and
press
view
environment
which
will
bring
you
to
the
environment.
Dashboard
under
the
environment.
Dashboard
you'll
see
there's
a
ton
of
different
columns,
and
one
of
them
is
rollbacks
and
you'll
see
here
that
the
rollback
was
done
for
exactly
that
same
commit
that
we
saw
in
the
email
that
we
received
with
the
same
alert,
but
we'll
also
see
some
addition.
So
we'll
see
this
notification
that
auto
rollback
was
triggered.
B
So
you
can
see
the
notification
and
you'll
also
see
that
three
issues
were
created
from
failure
to
deployment.
So
if
we
click
this
you'll,
you
can
see
there
was
an
auto
rollback
triggered
and
you
can
even
go
back
and
view
directly
in
the
run
book
itself
to
see
exactly
what
step
in
the
run
book
failed.
So
this
brings
you
to
the
run
book
and
you
can
see
exactly
the
three
issues
that
we
saw
before
in
the
environment
dashboard.
B
B
What
you
can
also
do
is
press
here
on
auto
rollback
settings
and
what
this
does
is
imagine
you're
in
a
situation
where
you
have
repetitive
rollbacks
and
you're,
just
like
man
what's
going
on
here,
and
you
want
to
figure
out
what's
going
on,
so
you
can
go
back
to
the
rollback
settings
themselves
and
configure
exactly
which
alerts
are
triggering
these
rollbacks.
You
may
want
to
add
or
remove
alerts
accordingly.
B
B
B
As
I
mentioned
so
from
here
again,
you
can
you
don't
have
to
go
through
the
run
book
itself
to
see
the
issues
you
can
see
the
issues
directly
from
the
environment
dashboard
itself,
so
you
can
see
from
here.
You
can
also
assign
it
from
here.
You
can
set
a
milestone
from
here.
It's
just
saving
you
a
bunch
of
clicks
in
order
to
take
action
as
the
minute
you
see
the
alert
and
the
problem.
B
I'm
going
back
so
just
one
minute.
Another
really
really
nice
thing
that
we
can
do
is
some
jumping
back
to
the
road
to
the
run
book.
Once
you
see
these
incidents
that
were
automatically
created,
you
can
take
action
on
it,
so
you
can
acknowledge
it.
You
can
decide
to
ignore
it,
and
you
can
also
state
the
reason
why
you
did
either
action.
B
So
we
get
all
this
log
as
the
history
of
this
runbook
and
everything
is
also
going
to
be
written
to
the
audit
log.
So
we
can
get
full
compliance
around
this
and
know
historically,
what
happened
for
every
deployment
and
even
if
we
roll
back
some
things
that
I
didn't
mention
yet,
but
are
also
really
interesting
to
discuss.
I'm
going
to
go
back
to
one
of
the
pages
here.
B
Okay,
so
when
the
the
system
automatically
creates
issues,
for
example,
for
example,
this
resolves
cve
issue.
What
this
is
actually
going
to
do
is
it's
going
to
suggest
how
to
fix
the
error?
That's
that's
triggering
this
rollback.
We
want
this
to
be
as
automatic
as
possible.
So
a
reason
for
rollback
may
be
a
performance
issue.
It
could
be
a
security
issue,
a
quality
issue,
so,
besides
opening
the
issue,
we're
also
going
to
suggest
how
to
fix
it.
B
Another
thing:
that's
really
really
nice,
that's
going
to
be
connected
directly
into
the
runbooks
itself.
Is
this
concept
of
templates
and
deployment
templates
so
in
case
there's
a
repetitive
problem
in
deployment?
We
can
help
you
out
by
either
suggesting
different
pieces
to
snippets,
to
cut
and
paste
into
the
yaml
file
or
even
resources
that
just
can
be
dragged
and
dropped
and
to
fix
your
deployment
pipeline
and
even
suggest
that,
so
the
idea
is
to
solve
the
problem
as
quickly
as
possible
and
also
suggest
the
remediation,
since
this
is
an
automatic
flow.
B
It
also
gives
you
a
lot
of
peace
of
of
mind,
thinking
that
the
rollback
is
done
automatically.
You
don't
need
to
be
on
call.
The
system
is
self-sufficient,
it's
going
to
fix
itself
and
that'll.
Give
you
some
time
to
fix.
Whatever
problem
is
on
your
pipeline
before
you
redeploy
it
again,
so
really
really
excited
to
see
this
happening.
It
kind
of
brings
in
a
whole
lot
of
different
sections
into
this
deployment
flow.
B
A
I'm
also
super
excited
about
that
flow.
I
think
it's
going
to
be
a
really
cool
experience
for
our
users
that
I've
definitely
seen
them
ask
for
next
up,
I'm
going
to
walk
through
our
second
flow,
which
is
about
deployment
approvals
inside
of
git
lab
from
a
run
book.
So,
first
up,
let's
say
that
I'm
a
release
manager
named
jane
doe
and
I
have
an
email
notification
for
a
pre-production
deployment
in
this
three-year
vision.
A
We're
hoping
users
can
access
their
pre-production
deployments
from
an
email
notification
and
then,
when
they
approve
or
reject
those
notifications,
they're
brought
to
git
lab,
and
in
this
view,
there's
a
group
release
run
run
book
which
allows
them
to
view
all
the
steps
in
a
given
release
and
find
action
each
step.
What's
really
neat
about
this
run
books
view
is
that
you
can
see
there's
some
sequential
steps
here
that
are
both
manual
but
also
scripted
actions,
and
you
can
run
these
various
steps
in
order
as
needed,
and
conveniently
users
can
also
see
linked
issues.
A
Much
like
what
orit
was
mentioning
in
her
flow.
Connecting
connecting
incidents
and
connecting
issues
that
have
been
created
are
instrumental
for
when
you're
sequentially
following
steps
as
a
part
of
your
release,
this
will
be
a
very
handy
feature
to
show
the
connected
value
of
gitlab
together
in
one
few
additionally
leveraging
a
discussion.
Commenting
thread
allows
users
to
open
up
thoughts
on
a
run
book
and
potentially
document
changes
that
they're
wanting
to
make
to
their
template
as
they
move
forward.
A
So
let's
say
I
want
to
view
the
application
of
my
deployment
as
the
release
manager,
I'm
going
to
click
that
view
app
and
I'll
see
that
I'm
looking
at
this
pending
deployment
for
this
application
and
from
this
screen,
I
have
the
option
to
approve
or
reject
I'm
going
to
approve
this,
and
actually
everything
looks
really
good.
So
I'll
also
click
the
approve
screen,
it's
a
great
way
to
add
in
users
throughout
your
run,
books
steps
and
ensure
that
the
releases
you're
promoting
to
your
production
environment
are
satisfying
expectations.
A
This
review
app
experience
is
really
great,
because
what
we're
hoping
to
accomplish
is
aggregating
a
batch
of
changes
into
a
single
review,
app,
which
will
be
a
really
cool
way
for
people
to
view
their
deployments
before
they
actually
happen
and
interact
with
them.
What's
even
better
is
that
we're
taking
that
pre-deployment
approval
and
pulling
it
into
the
merge
request
where
your
developers
and
your
engineering
teams
are
working.
A
Bringing
all
of
your
teams
together
in
one
place
for
a
particular
release
and
even
more
interesting,
is
the
place
where
you
potentially
have
a
feature
behind
a
feature
flag
and
being
able
to
view
that
feature
prior
to
the
feature
flag
being
turned
on
in
a
particular
environment
in
the
review
app
and
the
ability
to
then
approve
or
reject
that,
based
on
you
testing
that
interaction.
So
let's
say
that
this
feature
actually
looks
really
good
and
I
want
to
approve
the
the
release
and
also
disable
a
feature
flag.
A
A
So
let's
say
that,
actually
the
feature
slide
didn't
perform
and
you
want
to
reject
this
deployment.
These
run
book
steps
also
allow
you
to
reject
the
pre-production
deployment
and
say
that
it's
not
ready,
if
I
click,
reject
it'll,
pull
me
to
the
merge
request
view
and
indicate
that
the
pre-deployment
has
been
rejected
and
it
adds
my
comment.
A
We're
also
expecting
to
allow
notifications
from
this
particular
view,
so
say
that
it
gets
rejected
by
me,
and
I
want
to
notify
all
of
the
people
on
this
thread
so
that
they
can
make
changes
prior
to
prior
to
us
getting
to
the
next
step
in
our
run
book.
This
flow
is
showcasing
where
we
want
to
take
review.