►
From YouTube: Release Management Think Big #1
Description
Welcome to Release Management's Think Big Session 1 - here we discuss the opportunity in Release see our direction at https://about.gitlab.com/direction/cicd/#release.
A
So
and
present
my
screen,
so
this
meeting
is
called
think
big
and
we're
gonna
be
thinking
big
about
release
management
as
an
offering
for
gitlab
and
a
couple
of
different
thoughts
on
this
actually
I.
Like
that
view,
better,
okay,
think
big
is
intended
for
us
to
brainstorm
as
a
technical
design
and
product
team
about
our
vision,
roadmap
and
all
the
components
that
go
into
creating
a
positive
experience
for
our
gate.
Lab
customers,
we're
going
to
focus
on
the
release
management
solution.
A
But
we
can
do
on
the
product
and
design
side
is
try
to
provide
the
best
benchmark
that
we
can
to
help
move
our
product
toward
and
hopefully,
capture
the
market
that
were
that.
We're
going
after
does
that
make
sense.
Okay.
So
then,
in
this
meeting
we
hopefully
will
have
this
on
a
bi-weekly,
cadence
or
we'll
revisit
our
future
vision
of
release
management
and
look
at
our
planned
epics,
so
that
we
can
back
into
the
timing
of
those
issues
they
can
be
from.
Do
we
need
to
do
user
research?
A
I
also
want
this
to
be
a
frank
and
honest
opportunity
for
us
to
either
push
back
on
the
vision
or
question
the
vision
I'm
by
no
means
the
only
expert
here,
I
feel
all
of
us
bring
different
perspectives
to
the
table
and
are
all
equally
valid,
so
we
should
feel
comfortable
as
a
team
confronting
those
assumptions
that
we've
baked
into
the
issues
or
something
isn't
clear,
raising
your
hand
and
being
like
this
has
to
be
clear.
Okay,
perfect!
A
So
in
this
meeting,
I
wanted
just
to
talk
through
some
of
the
epochs
that
we
have
planned,
meaning
we
created
them
most
of
the
issues
are
either
in
validation
or
in
the
backlog
of
those
epics,
and
they
are
very
relevant
for
our
vision.
I
split
it
by
UX.
So
since
we
just
have
hi
ani
here
will
probably
just
talk
through
these
top
top
five
as
a
high-level
overview.
B
A
A
A
Most
of
them
are
source
code
management,
customers
across
various
tiers
across
various
offerings,
but
we
can-
and
we
can
say
that
all
gate
lab
users
would
have
a
better
experience
within
get
lab
if
they
manage
their
deployments
in
our
offering.
So
this
suggests
that
release
can
be
a
compelling
and
motivating
solution
for
our
customers,
so
the
vision
that
would
help
motivate
that
would
be
having
get
lab
releases
be
the
place
to
manage
multi
cloud
deployments
across
all
aspects
of
get
lab,
which
would
be
projects,
groups
and
environments.
A
When
we
look
at
all
of
those
various
aspects
of
get
lab,
this
means
we
have
to
think
of
the
customer
and
users
experience
as
they
navigate
through
those
three
different
places
and,
if
they're
orchestrating
releases
across
those
different
kinds
of
things,
where
do
they
go
to
see
how
releases
are
happening
in
all
of
the
projects
that
they
manage
or
they're
a
part
of,
or
all
the
groups
that
they
belong
to?
So
from
a
mission?
Very
tactical
like
what
do
we
want
to
accomplish
and
drive
to
you
when
I?
A
A
These
features,
these
collections
of
features
are
going
to
contribute
to
moving
people
off
of
just
their
source
code
management.
We
need
to
be
able
to
do
a
couple
of
things
in
the
existing
functionality
of
release
in
the
UI,
not
just
the
API.
We
also
need
to
be
able
to
do
all
the
things
that
we
can
do
in
the
API
in
the
UI,
which
is
exactly
the
epoch
that
you
created
Nathan.
A
Thank
you
and
then
we
also
need
to
support
some
of
the
governance
functionality
in
order
to
tap
into
the
regulated
industry
and
I
and
I
put
a
little
graph
here
and
it
links
out
to
a
report
on
our
on
our
market
and
I
have
some
notes
in
here.
So
if
you
guys
are
curious,
you
can
dive
in,
but
I
just
wanted
to
show
you
looking
at
our
entire
opportunity
or
white
space
about
a
quarter
of
it
is
nested
across
ten
different
industries.
A
That's
yeah!
We
have
like
100
industries
and
ten
of
those
comprise
25%
of
our
opportunity.
The
way
that
we're
gonna
activate
that
opportunity
is
by
delivering
on
very
focused
features
that
activate
reliefs
governance
and
the
ability
to
see
across
projects,
groups
and
environments,
especially
if
they're
in
different
cloud
deployments.
C
Hey
Jackie's,
quick
question
for
the
everything
you're
saying
makes
a
lot
of
sense
for
the
for
the
SCM,
the
the
folks
that
are
only
using
it
lab
for
for
SEM
RS
SC
M
offering
do
we
have
any
insight
into
what
they're
using
and
why,
like,
in
any
hurdles
we
would
need
to
overcome
like?
Is
it
because
you
know
there
I'm
not
sure
how
to
how
to
word
this?
Are
they
using
our
competitors?
Are
they
using?
You
know
some
sort
of
like
on-prem.
C
Do
we
have
any
insight
into
why
or
into
what
they're
why
they're
not
using
Gilliam
and
what
we
could
do
to
help
change?
That
like
is
it
you
know?
Is
it
just
our
maturity
level,
our
love
ability
level
in
certain
areas?
Is
it
you
know
they're
already
ingrained
with
other.
You
know
competitors
things
like
that.
Yeah.
A
A
You
know,
they're
all
leveraging
our
core
offering
and
the
general
theme
that
I'm
hearing
is
yeah.
You
know
I
used
it
as
a
startup
about
five
years
ago,
because
it
was
the
cheap
open-source
option
on
the
market
and
I
loved
it
as
that
kind
of
solution,
and
now
that
you're
offering
all
these
other
things
it's
hard
for
me
to
jump
over
when
I'm
so
ingrained
with
my
current
provider
of
XY
and
Z.
That
extreme
is
what
I
really
need
to
dig
into.
A
D
A
My
immediate
priority
right
now
is
to
start
validating
these
hypotheses
and
mission
vision
with
customers,
and
my
goal
would
be
in
our
next
meeting
for
think
big
to
start
presenting
some
of
those
findings,
but
I'm
also
wanting
to
hear.
Are
there
other
things
that
aren't
captured
in
these
kinds
of
epics,
or
even
that
are
on
your
mind,
as
you
hear
these
goals
that
I'm
setting
up
for
us
to
start
executing
against.
E
When
idea
that
I
had
is
I
know,
we
don't
do
we're
kind
of
in
our
own
silo
at
the
moment,
but
we
could
there's
a
lot
of
room
I
think
to
integrate
with
some
of
the
other
stages
and
the
one
I
I'm
thinking
I'm
now
is
packaged.
For
example,
if
we
have
a
release
that
might
you
know,
have
a
an
NPM
package
associated
with
it.
It
might
be
a
nice
way
to
tie
a
release
of
an
NPM
package
to
our
actual
MPM
package,
offering
somebody
some
ways
to
tie
things
data
there.
That's.
A
E
A
E
That's
awesome
yeah.
He
kind
of
already
had
this,
but
I
think
if
we
want
to
be
able
to
get
to
that
fifty
percent
level
of
people
using
release
the
we
have
a
story
somewhere
about
making
being
able
to
create
releases
through
the
gate,
lab
CI
mo
file.
I
think
that's
really
important,
because
at
the
moment
it's
kind
of
a
pain
to
make
releases.
You
have
to
like
hit
the
API
and
it's
not
super
easy,
so
I
think
we
need
to
make
it
super
easy
to
make
releases
and
that
will
help
adoption
quite
a
bit.
A
A
It
you
keep
from
like
feeling
really
down
in
the
dumps
when
I
get
off
calls
that
are
like
I,
don't
know
where
going
I
feel
lost
and
yeah
definitely
that
one's
a
hard
one
to
solve
for
sure
I'm
making
it
easy.
It
should
be
the
priority
and
focus
I
agree
with
that
Ayana
in
your
baseline
experience
of
creating
a
release.
Do
you
think
there
were
things
that
were
not
thinking
of
about
releases
and
release
management
that
are
super
far
down
the
road
like,
for
example?
A
B
That's
a
good
point,
I
think
in
the
experience
baseline,
we
did
really
work
with
the
bare
minimum,
which
was
to
be
able
to
create
a
release
through
the
UI,
and
we
didn't
really
focus
on
this.
Any
specific
personas
was
just
really
on
completing
the
task,
so
we
didn't
really
dive
into
this,
like
the
bigger
opportunity
of
what
this
functionality
could
look
like,
and
it's
kind
of
relate
it
to
the
point.
I
I
have
about
the
maturity
level,
so
I'm,
just
not
based
here.
B
To
them
is
your
two
level
page
but
I
wonder
how
can
we
measure
the
maturity
of
our
functionalities
from
a
user
experience?
Point
of
view
right
now
we
have
the
category
of
maturity,
types
right
mostly
focus
on
the
product
offering.
But
how
can
we
look
ahead
and
say:
ok,
maybe
if
we
move
the
experience
from
X
to
Z
this
will
you
know,
increase
the
the
or
improve
the
maturity
I.
Don't
move
from
viable
to
loveable
because
of
a
specific
user
experience.
B
I,
don't
have
any
any
examples
right
now,
but
I
think
there's
a
lot
of
small
things
as
more
improvements.
We
can
do
to
see
overall
release
management
process,
especially
in
the
UI
like
what
Nathan
say
that
it's
correlated
to
other
areas
in
the
product,
and
we
definitely
need
to
be
able
to
measure
that
from
from
a
UX
point
of
view,
so
that's
kind
of
like
an
open
question
from
my
mind.
So
how
do
we
do
that?
What
is
the
baseline,
for
you
know
a
lovable
user
experience.
A
But
I
also
feel
like
we're
kind
of
biased
to
this
developer,
centric
view
and
very
focused
on
supporting,
like
AWS
cuber
Nettie's
bias
and
as
a
result,
we
have
to
provide
the
sexiest
most
technical,
offering
out
the
door
and
then
think
of
the
more
UI
components.
Second
hand.
At
least
that's
what
I've
seen
yeah
across
the
entire
stock
is
that
we
prioritize
that
dev
centric
view
and
release
management
might
be
our
opportunity
to
go
against
that
grain.
A
B
Yeah
I
would
love
for
us
to
experiment
a
bit
more
there
and
then
really.
Looking
to
you
know,
how
can
we
make
things
a
bit
more
seamless
right
for
these
management?
We
have
to
connect
the
dots
and
COSO
connect
distinctly,
especially
where
are
those
things
live
in
the
product
see
you
know,
talk
about
the
workflow
and
talk
about
like
what
you
say
and
understanding
its
personas
and
their
jobs
and
seeing
what
makes
sense
for
them
not
only
from
a
technical
point
of
view
like
not
only
through
the
API
is,
but
also
the
UI.
A
Conversation
is
a
governance
conversation,
but
it's
also
an
orchestration
conversation,
so
that
will
span
both
you
and
Mike,
but
the
priority
for
release
governance
is
to
to
really
get
it
to
a
viable
state
by
the
end
of
the
ninth
month
from
today
and
right
now,
it's
like
it's.
It's
planned
right.
We
need
to
deliver
a
complete
story
on
evidence,
collection
and
have
this
be
a
continuous,
evolving
audit
conversation
with
the
market?
Then
we
also
need
to
investigate
better
management
of
our
environment
experience
and
that
can
span
both
orchestration
and
governance.
A
A
A
A
A
It's
a
whole,
it's
just
lies.
It's
just
tell
you
what
we
could
do,
but
I
think
that
this
is
where
our
conversation
of
think
big
is
more
meaningful
is,
after
we
get
to
this
next
nine
months
of
getting
us
off
the
ground.
What
really
will
make
us
propel,
get
lab
release
into
the
future
and
help
us
get
this
goal
of
those
SEM
users
that
are
currently
only
leveraging
get
lab
for
source
code
management
to
deploying
with
Gila.
D
A
D
E
D
A
This
would
be
like
the
starting
questions
that,
when
I
have
a
call
with
somebody
that
either
says
hey
I'm
using
gitlab
or
a
portion
of
it,
typically
all
like
weave
in
to
understand
like
are
they
automated?
Are
they
not
automated?
We
we
need
to
kind
of
see
on
the
continuum
of
regulated
industries,
how
much
automation
are
they
currently
supporting
in
their
in
their
pipeline
and
their
environments
and
their
projects
and
groups?
A
Are
there
different
permissions
that
we
have
to
think
about,
and
after
we
get
that
it's
like
a
double
click
into
our
personas,
because
right
now
we
have
a
lot
of
information
about
how
personas
are
managing
their
day
to
day
and
releases
or
relationship
to
releases.
But
it's
the
task
pieces
that
are
going
to
influence
the
instrumentation
of
release
management
for
their
organization.
We.
D
A
Also,
what
I
don't
want
to
do
is
come
in
hot,
with
a
customer
or
a
user
and
exclude
their
entire
experience,
because
I
think
that
understanding
their
journey
into
release
will
be
the
key
to
how
we
improve
and
where
we
choose
to
improve
our
offering.
So
if
the
user
experiences
hey
I,
currently
manage
source
code
today
and
I'm
super
familiar
with
tags
and
the
mo
file.