►
From YouTube: Restructure Release JTBDs ยท Jan 2022
Description
An overview of the ongoing restructuring of Release stage jobs to be done on https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/95913
A
Hey
good
evening,
everyone,
this
is
daniel
frisco
senior
product
designer
on
the
release
group.
This
video
is
an
overview
of
all
the
changes
in
this
merge
request,
you're,
seeing
on
the
screen
the
restructure,
release,
orchestration
jobs
to
be
done
for
some
context.
This
merge
request
is
about
refining
our
jobs
to
be
done
in
release
orchestration
in
advance
of
some
working
q1
to
increase
the
maturity
for
this
category
at
first.
A
The
changes
that
were
being
proposed
in
this,
mr,
were
more
superficial,
but
based
on
a
lot
of
feedback
that
we
received,
I
decided
to
take
a
step
back
and
really
restructure
the
way
we
set
up
our
jobs
to
be
done
mainly
because
one
of
the
problems
was
we
had
too
many
of
them,
so
some
of
them
had
to
be
cut
off,
others
had
to
be
merged
together,
and
this
makes
for
a
really
complicated
set
of
changes
just
to
be
read
on
amr.
So
this
video
is
a
helper
to
navigate
these
changes.
A
So,
let's
start
with
this
map,
where
you
can
see
here
the
state
that
we
had
right
the
original
state
of
these
jobs
to
be
done,
so
we
had
two
sets
of
jobs.
One
main
job
create
a
release
and
update
it
with
subjobs
and
then
another
main
job
that
was
tracking
and
coordinating
deployments
that
also
had
a
few
sub
jobs.
A
A
So
essentially
it
meant
I
want
to
deploy
my
product
my
changes
and
get
customers
to
adopt
it.
So
the
way
I
rephrased
this
was
release
and
deploy
code
changes
when
code
changes
are
available.
I
want
to
release
these
changes
to
customers,
so
they
can
benefit
from
the
update
right.
The
idea
here
is
to
be
a
little
more
broad
in
the
sense
of
we
have
changes.
Let's
make
sure
customers
can
access
these
changes
while
still
including
both
release
and
deploy
in
the
language.
A
This
was
a
a
very
intentional
decision,
since
these
are
two
different
but
overlapping
concepts.
Right
now,
in
our
platform,
I
decided
to
have
both
here
to
make
sure
that
this
is
not
about
the
release
feature
on
git
lab
it's
about
releasing
or
deployment
deploying
whatever
verb.
You
want
to
use
it's
about
updating
our
code
base
into
the
customer's
hands.
A
This
one
is
all
about
making
sure
you
can
see
which
versions
of
code
are
being
released
and
track
those,
so
that
was
translated
into
track
code
being
released
when
releasing
changes.
I
want
to
track
different
versions
of
code
until
they
are
ready
to
production
for
production,
so
I
can
ensure
the
right
changes
reach
our
customers,
so
that
was
released
illustration
two
previously
and
then,
interestingly,
these
two
they
were
not
the
same,
but
they
were
closely
related
enough
that
it
made
sense
to
turn
them
into
one.
A
So
the
first
one
is
about
tracking
important
deliverables
in
my
project
and
easily
create
and
manage
all
the
information
necessary
for
release
right.
So
it's
about
easily
getting
all
the
information
together
to
make
sure
you
have
everything
ready
for
a
release
and
the
second
one.
It's
about
also
preparing
your
release,
but
making
sure
you
can
do
everything
from
one
place
right
from
one
interface.
A
So
since
this
was
about
quality
and
being
easy
to
do,
which
is
not
ideal
and
a
job
to
be
done-
and
this
was
about
centralizing
one
place,
I
thought
it
makes
sense
to
mix
them
together,
so
create
releases
in
one
place
when
releasing
changes.
I
want
to
manage
all
the
necessary
information
in
one
place,
so
I
can
provide
an
update
that
includes
all
the
informations.
My
users
need
without
switching
contexts,
which
was
part
of
the
text
for
one
of
them.
A
A
This
one
was
was:
some
of
them
were
worded
a
bit
weirdly.
So
this
one,
the
main
one
reads:
when
insurance
teams
are
coordinated
about
releases,
I
want
to
deploy
to
production
state
for
customer
consumption,
so
I
can
show
the
body
of
work
that
goes
into
the
point
of
production.
This
reads
a
lot
like
I
want
to
deploy
right,
so
I
want
to
deploy
to
production,
so
customers
can
consume
the
work.
A
So
this
reads
a
lot
like
what
we
already
have
here:
releasing
deploying
code
changes,
so
this
one,
the
text
for
this
one
was
scrapped,
although
tracking
and
coordination
coordinating
deployments
as
a
main
job
still
makes
a
lot
of
sense.
So
what
I
did
was
I
got
the
the
sub
job
that
made
more
sense
with
this
main
title
and
put
them
together.
So
what
we
ended
up
with
was
tracking
coordinate
deployments
when
preparing
to
deploy
changes.
A
Oh
high,
five,
one
of
them
about
planning
all
the
changes
to
production
in
one
place
to
reduce
failure,
points,
and
this
one
about
taking
action
on
deployments
from
across
my
organization,
also
in
one
place
so
again,
very
very
similar
goals.
Very
aligned
goes
between
these
two
jobs,
so
manage
deployments
in
one
place
when
managing
changes
to
production.
I
want
to
manage
and
take
actions
and
employments
from
a
single
two,
so
I
can
have
better
control
of
our
production
changes.
A
So
this
this
is
how
we
ended
up.
You
will
see
if
you
pay
attention
in
either
the
mr
changes
or
this
video,
that
I
ditched
the
release,
orchestration
names
for
the
jobs
and
that's
on
purpose
right
right
now,
we
have
no
place
here
on
the
way
the
jobs
are
displayed
to
list
which
categories
they
are
linked
to
and,
to
be
honest,
I
don't
think
we
should
jobs
should
be,
should
not
be
category
specific,
they're,
just
jobs
that
our
users
are
conducting
within
our
application
within
our
platform.
A
So
the
idea
here
is
that
this
is
about
releasing
and
deploying,
and
then
these
are
the
sub
jobs
for
release
and
deploy
and
same
here.
This
is
about
track
and
coordinate,
and
these
are
the
sub
jobs
for
it.
I
have
some
additional
thoughts,
I'll
leave
them
as
a
comment
in
an
mr,
because
this
video
is
long
enough
and
I
wanted
to
take
the
time
to
just
go
over
all
the
main
changes.