►
From YouTube: Release Management Think Big #4
Description
Welcome to our discussion on what's next in Release Management at GitLab
A
A
All
right
well
welcome
to
I
think
our
fish
think
big
release
manage
fourth
I.
Think
you're
right
high
on
a
four
I
think
the
accession
for
release
management,
I
have
a
couple
of
topics
on
the
agenda,
and
I
saw
that
Heine
you've
listed
a
bunch
of
items,
so
the
first
one
was
I'm
finishing
up
our
environments
survey.
A
So
the
focus
of
this
is
to
kind
of
give
a
big
understanding
of
what
people
are
using
environments
for
one
of
their
perceptions
of
get
lab
environments
and
then
we'll
probably
create
a
bunch
of
Forks
in
different
research
streams.
Once
we
understand
how
people
are
using
environments
and
then
kind
of
prioritize,
what
are
what
are?
What
are
the
next
steps
for
us
to
think
about
there?
B
I
was
reviewing
the
survey
and
also
the
issue
and
I
was
wondering
if
we
should
add
to
target
users
like
anyone
that
is
involved
with
you
know,
dealing
with
the
environment,
so
I
want
to
check
deployments
so,
for
example,
product
designers,
technical
writers,
QA.
So
not
necessarily
scuse
me
people
that
go
into
the
code
and
want
to
say.
A
A
D
My
point
of
view
like
I,
would
think
I
would
assume
that
those
users
would
be
like
a
like
a
quality
like
a
QA
person
or
like
a
UX
person
who,
like
maybe
a
developer,
made
a
review
environment
kind
of
like
how
we
use
it
here.
Someone
that's
involved
in
the
software
stage.
It's
not
directly
in
development,
just
to
kind
of
like
give
input
into
that
into
that
lifecycle,
yeah.
C
Sorry
in
previous
roles,
I've
had
along
those
lines
I've
seen
folks
I
was
trying
to
remember
the
turret.
The
term
delivery
lead
I,
think
was
a
term
I
think
it's
it's.
Basically,
someone
in
oversight,
role
of
the
project,
who's,
not
very
technical,
but
is
probably
involved
in
deploying
certain
versions
to
certain
environments.
That
might
be
a
little
bit
of
a
specific
example
but
I'm.
Just
remembering
from
like
my
last
role,
I
was
trying
to
think
of
what
that,
with
that,
what
that
role
was
yeah.
A
I,
like
that,
so
I've
updated
the
issue
to
include
those
different
personas,
so
we'll
definitely
be
scheduling
our
interviews
with
all
those
different
personas,
at
least
to
begin
with,
and
then,
as
we
start
to
get
into
solution
validation.
That
makes
sense,
but
it's
interesting
because
it
could
be
my
limitation
of
how
environments
were
meant
to
be
used
and
get
lab
is
when
I
look
at
them.
They're
like
a
proxy
for
your
stages
and
whether
or
not
you're
deploying
with
gitlab.
You
can
leverage
them.
A
So
it's
an
interesting
sort
of
how
do
we
expect
people
to
use
them?
What
do
we?
What
do
we
want
them
to
do
with
them
and
the
whole
other
persona
side
of
that?
The
ones
that
aren't
like
responsible
for
building
the
feature
but
are
rather
external
to
that
process,
whether
they're
doing
feature
assurance
or
ensuring
that
the
designs
make
sense,
I
think
it's
completely
relevant.
So
that's
good
yeah.
B
And
that
was
my
main
goal
really
to
focus
more
like
the
discoverability
of
environments
in
the
UI
because
hurts
and
very
few
apps
and
the
deployments
they
pop
up
so
often
on
the
interface
and
with
you
get
like
some
feedback
people
not
knowing
how
to
use
it
or
how
it
exists.
So
that
was
a
kind
of
rationale
behind
it.
B
A
Like
it
so
I
think
this
might
be
a
good
question
and
to
bring
up
two
or
read
your
second
one.
Given
that
review,
apps
is
really
on
her
side
of
the
the
camp.
It
kind
of
makes
sense
that
we
would
include
some
questions
around
her
view,
apps
and
other
feature
functionality.
That's
in
the
early
stage,
so
yeah
I,
think
that
makes
sense.
A
I
think
when
I
look
at
environments,
we
could
also
be
looking
at
how
people
administer
kubernetes
with
gitlab.
So
this
would
be
a
lot
of
the
configure
stage,
work
and
understanding
how
they
kind
of
do
their
work
within
that
was
actually
cool.
Learning
that
I
had
with
the
customer
last
night
that
I
was
interviewing.
They
are
in
the
telco
space.
A
Manage
we
run
into
the
compliance
and
auditing
view,
so
here
it's
like
if
we
have
an
environment,
making
sure
that,
if
it's
shared
across
multiple
groups
that
there's
a
separation
of
duties,
that's
there
so
like.
If
one
person
can
deploy
in
one
project
that
they're
not
able
to
beat
the
people
developing,
you
know
like
having
that
separation
of
duties
there.
That
could
be
an
interesting
thing
to
look
at
showing
at
the
environment
level.
D
Just
a
general
comment:
I
think
this
is
really
good
that
we're
doing
this
because
even
for
me,
like
I,
haven't
used
environments
myself
very
much,
and
it's
not
super
clear
to
me.
The
value
that
using
environments
through
gitlab
would
provide
just
thinking
back
to
other
roles
like
we
kind
of
deployed
to
an
environment,
and
then
it
was
like
it's
outside
of
get
laughs
at
that
point
in
time.
So
it's
not
super
clear
to
me.
How
is
like
managing
those
through
get
labs?
How
does
that
really
provide
value
to
me?
So
I
think?
That's!
D
A
That's
what
I'm
running
into
as
well
is
that
we
have
a
lot
of
people
that
are
leveraging
environments,
but
it's
unclear
if
they're
one
getting
the
value
that
we
intended
from
it
or
two,
if
they're,
just
using
it
for
things
unintended,
so
that'll
be
interesting
to
see
for
sure,
because
in
the
documentation
it
looks
like.
We
meant
this
to
be
a
place
where
you
tracked
appointments,
but
people
aren't
always
deploying
with
gitlab,
even
ones
that
are
using
environments.
They're,
not
always
deploying
with
you
lab.
B
A
A
Something
comes
back
with
an
error:
what's
their
next
step
to
debugging,
would
they
ever
go
into
the
UI
to
look
at
environments
and
perform
like
a
rollback
if
they
can't
do
a
rollback
from
the
command
line,
and
that
would
probably
be
like
a
workflow?
That
I
would
imagine
happening.
Is
that
oh
I
got
this
error?
A
I
can't
perform
a
rollback
from
the
command
line,
so
I'm
gonna
go
into
get
lab
and
see
where
my
code
is
stuck
or
where
my
commit
is
stuck
at
or
if
I'm,
a
maintainer
I
might
be
looking
at
the
UI
first
noticing
that
this
commit
just
ran
on
my
pipeline,
and
now
my
pipeline
failed.
So
I'll
need
to
look
at
this
environment
to
roll
it
back
to
the
last
verified
commit
and
by
last
verified
commit.
This
would
be
the
last
one
that
caused
the
pipeline
to
pass
because
that's
kind
of
how
it
works.
Yeah.
C
I'm,
looking
at
my
like
just
a
API
project
that
I
have
the
I
use,
get
lab
just
cuz
I
have
full
control
over
this,
so
I
wanted
to
go
looking
in
by
my
production
environments
and
it's
digging
in
a
little
bit.
It
is
kind
of
neat
because
I
use
tags
on
every
release,
so
I
can
see
like
Oh
version,
1.2
dot.
C
Six,
maybe
I
released
something
that
broke
something
right
and
so
I
wanted
to
roll
back
to
1.2.5,
and
then
I
can
just
there's
literally
a
rollback
environment
button
which
is
pretty
cool
so
just
to
just
to
say
that
and
there's
like
some
monitoring
stuff,
so
I
think
that's
how
I
would
use
this.
Just
pretending,
I'm
I'm
the
person
I,
would
use
this.
If
I
made
a
mistake
and
accidentally
deployed
something
that
I
that
broke
something
I
would
go
back,
go
in
here
and
and
roll
back
easily
super
fast
want
to
click
rollback
right.
A
A
Mean
we
have
a
lot
of
things
built
around
environments
right
now
that
we
would
potentially
have
to
like
strip
out
if
we
learn
that
environments
actually
aren't
being
used
as
intended
or
people
aren't
deploying.
Let's
get
lab,
because
environments
are
confusing,
like
we
kind
of
have
to
research
that.
A
Okay,
so
next
immediate
next
steps
are
to
finish
building
out
that
survey
in
Qualtrics
I
started
yesterday,
but
then
had
a
bunch
of
calls.
So
it
was
context.
Switching
left
and
rights.
I
didn't
ever
get
to
complete
the
Qualtrics
survey,
but
it's
like
that
tab
that
is
pinned
to
each
one
of
my
browsers
and,
of
course,
I
have
like
five
browsers
open
and
this
one
tab
is
pinned
to
so.
A
Hopefully,
I'll
get
done
with
that
this
week
and
then
post
and
we'll
start
collecting
the
information
on
it,
and
it
would
be
my
intent
that
we
would
start
scheduling,
work
in
13
to
start
executing
against
our
new
environments,
jobs
to
be
done.
So
we
have
a
couple
of
milestones
before
we
before
we
get
to
the
scoped
work.
There.
A
So
I
had
probably
about
11
or
so
interviews.
Over
the
past
week
with
customers,
we
talked
about
two
different
main
topics.
One
of
them
was
working
across
multiple
projects
or
repos
and
what
it
meant
for
testing
or
creating
releases
and
how
much
of
a
burden
or
a
problem
or
complicated,
that
is,
for
people
in
the
regulated
space
or
in
the
enterprise
space
and
I
can
say
that
we
have
validated
that
people,
one
who
use
get
lab,
really
want
to
see
more
things
at
the
group
level.
A
So
they
would
want
to
see
like
a
splash
page
of
key
metrics
for
how
their
things
are
going
like
at
the
beginning
of
their
day,
and
then
they
can
start
triaging
from
that
view,
rather
than
having
to
go
project-by-project.
My
project,
because
today,
people
who
are
managing
across
multiple
projects
are
having
to
go
in
the
interface
and
click
through
each
project
to
see
where
things
are
at,
rather
than
seeing
a
summary
at
the
top
level.
A
So
after
we
validated
that
we
look
at
the
prospect
view,
they're
using
Jenkins
most
commonly
and
Jenkins
allows
you
to
create
patterns
where,
in
the
view,
you
have
a
column
for
all
the
relevant
activity.
Scripts
queries
whatever
it
is
for
that
particular
pattern.
So,
for
example,
there
was
a
telco
customer
that
was
specific
to
this
company
orange
and
they
prefixed
all
of
the
jobs
pipeline
scripts.
A
But
if
we
were
to
offer
something
that
they
could
tailor
to
themselves
like,
where
am
I
deploying
code
as
a
dashboard
like
it's
my
dashboard,
all
the
things
that
I
have
in
progress
in
a
single
view?
That
was
something
of
interest
for
them,
so
still
needed.
Visibility
into
cross
repo
cross
project
cross
objects
things
and
get
lab,
but
it
wasn't
as
meaningful
for
people
who
are
individual
contributors
as
they
were.
Managers,
there's
also
a
general
consensus
that,
if
you're
trying
to
detect
a
bug,
that's
spun
out
of
a
different
repo
but
impacted
your
current
repo.
A
It's
virtually
impossible
to
do
that
in
github
and
other
like
code
code
management
systems
and
I
think
that's
probably
true
and
get
lab
to
like.
If
you
had
a
bug,
that's
spun
out
of
repo
a
that
ended
up
impacting
the
front
end
of
repo
B,
because
you
had
some
shared
component
or
a
library
or
a
micro
service
between
those
two
applications.
A
You
wouldn't
necessarily
be
able
to
diagnose
that
the
bug
you're
experiencing
and
repo
B
was
caused
by
a
but
oftentimes
there'll.
Be
bug
goes
in
repo,
a
related
to
that
to
that
same
bugs
that
they
would
then
fix,
but
sometimes
it
could
take
weeks
or
days
days
or
weeks
to
find
that
one
or
an
origin
bug
and
that's
what
James
just
kind
of
tackling
on
the
testing
side
when
it
comes
to
cross
repo
activity.
A
C
B
B
A
B
Cool
just
to
know
if
I
needed
to
bring
Mike
and
in
order
to
do
that
issue
into
the
comments.
That's
cool,
and
my
second
point
is
that
I
created
this
spreadsheet,
because
I
saw
what
the
folks
on
package
did
in
the
issue
and
I
was
like
super
nervous
because
it
has
like
I,
don't
200
comments
almost
and
that
and
I
just
created
this
sheet.
B
And
my
third
comment:
it's
that
the
current
job
should
be
done,
that
we
have
there.
We
have
a
few
ideas,
but
they're
very
task
is
specific,
so
we
tweak
them
a
little
bit
and
I
wanted
to
know
it's
nice.
That
Lori
is
here
as
well.
How
we
can
do
that
I
mean
we
know,
or
we
have
an
idea
of
what
jobs
we
need
to
tackle
there.
But
Lori
are
you
able
to
kind
of
review
those
with
us
on
the
fly,
all
right
awesome?
B
Thank
you.
I
just
wanted
to
make
sure
that
we're
putting
in
the
right
way
it
might
find
a
comment
that
just
to
clarify
just
that's
quite
fine
but
I,
think
it's
safe
to
say
that
we're
going
to
continue
or
focus
on
that
right
or
the
releases
page
and
a
job
to
be
done,
but
from
a
UX
point
of
view,
our
only
risk
or
it
on
q2.
B
A
E
One
of
the
things
is
rewrite
jobs
to
be
done.
We
have
to
remember
to
write
them
tool
agnostic,
so
we
don't
mention
get
labs.
We
don't
mention
any
specific
tool
that
they
wanted
to
use
it's
a
job
and
it's
part
of
their
job.
It's
like
we
need
to
take
notes.
Whatever
gonna
take
notes
on
something
that
can
be
easily
shared.
It's
not
like.
We
say
we
have
to
use
Google
Docs
to
take
notes,
so
it's
important
to
remove
the
tool
for
the
job
to
be
done
piece,
because
that
also
removes
any
sort
of.
A
E
Okay,
Oh
No
can
you
let
me
know
yeah
my
iPod
okay,
earpods
are
deciding
to
take
a
vacation,
so
what
I'm
saying
it
was
jobs
to
be
done,
need
to
be
tool
agnostic.
So
the
thing
is
that
you're
focusing
on
the
job,
not
the
tool
to
be
used.
So
what
is
the
thing
that
they
need
to
do
was
the
up
on
me
for
it
so
like
for
us.
If
it's
like,
we
need
to
take
notes
in
the
format
that
can
be
shared
easily.
Hey.
E
We
don't
work
in
the
same
office,
so
paper
is
not
gonna
cut
it
right.
We
need
to
have
some
sort
of
shareable
way
to
take
notes.
We've
decided
Google,
Docs
or
whatever
is
the
tool
to
do
that
with,
but
that's
not
in
the
jobs
to
be
jime.
The
jobs
to
be
done
is
I
need
to
take
notes
and
shareable
format
so
that
my
co-workers
understand
what
I've
gained
from
this
interview
and
then
we
as
like
say
we've
worked
at
Google.
B
E
B
I
also
wanted
to
know
how
much
we
should
look
now,
what
our
user
insights
and
the
data
that
we
have
collected
to
write
those
jobs
to
be
done,
because
what
I've
seen
that
I'm
gonna
use
the
packaging
as
an
example
cylinder,
is
that
there
are
lots
of
information,
a
lot
of
items
there,
but
I'm
not
sure
if
they're,
just
okay.
These
are
things
that
we
know.
You
know
that
those.
D
B
E
Okay,
can
you
hear
me
it's
where
the
guy
that
I'm
gonna
distich
using
your
ear
pods
out
than
that
so
I
think
that
that's
where
it
came
from?
It
came
from
the
data
that
they
had
done
research
on
as
well
as
issues
so
where
customers
said
that
they're
trying
to
do
a
task,
and
then
they
come
here
that
was
I,
dare
David
said.
Okay,
this
seems
like
it
seems
to
be
an
important
task.
Let's
put
it
in
there
the
list
so
yeah.
E
We
can
definitely
look
at
the
insights
repo
to
see
if
we
can
clean
jobs
to
be
done
from
there.
We
should
also
I
mean
I,
don't
know
how
much
overlap
there
is
with
this,
but
we
can
also
ask
the
other
groups
to
see
if
they
have
come
up
with
any
insights
that
deal
with
what
we're
focusing
on
as
well,
because
you
never
know
what
comes
up
in
me
in
interviews.
B
B
B
And
Jason
recommended
pages
right.
The
release
is
something
else
that
I
don't
remember,
so
we
had
three.
We
had
to
choose
two
of
those,
but
those
were
not
based
on
any
research
and
user
insights.
Any
data
I
think
was
just
like
Jason
and
he's
knowledge
from
the
product
at
that
point,
and
so
this
is
job
to
be
done
that
we
came
up
with
so
when
tracking
portal
deliverables
in
my
project,
I
want
to
easily
create
and
manage
release
entries
in
get
lab
so
that
I
can
provide
packaged
software
notes
and
files
for
people
to
use.
B
So
that's
super
broad
and
I.
Did
the
heuristic
analysis
documented
a
whole
flow
and
gave
it
the
score,
an
F
right,
and
this
quarter
re-evaluated
and
checked
if
the
score
change
or
not?
Let
me
see
if
this
is
the
yeah
and
it
didn't
change
its
to
before
I
think
my
questions
related
to
this,
you
asked
for
a
card
is
job
to
mean
or
not
our
answer
to
me.
B
It's
more
like
continue
with
this
effort
and
see
how
we
can
improve
the
the
grade,
but
with
the
new
ones,
I
feel
like
we
have
so
much
data
now,
and
so
many
insights
and
I
just
want
to
make
sure
that
we
don't
focus
on
specific
tasks.
For
example,
let
me
show
here
yeah
when
this
is
the
so,
when
I'm
ready
to
deploy
a
change,
I
want
to
deploy
production
using
get
lab
environments,
so
I
can
coat
the
so
they
code
deploy
and
sustainable
test
in
skin.
B
It
seemed
like
super
task,
oriented
and
also
super
bra
and
I
feel
that
also
can
make
the
job
to
be
done
to
become
very
big
right
and
then
we're
gonna
have
a
lot
of
different
deliverables
and
then
we're
gonna
have
to
look
at
them
again
and
see.
Okay
from
this
list
of
recommendations,
let's
say
that
we
have
28
recommendations
for
such
a
big
job
to
be
done.
How
do
we
even
reorganize
them
and
prioritize
them?
So
there's
a
little
bit
my
questions.
E
And
I
wondering
hang
on
up
for
that
one.
The
needs
to
play
a
change,
I,
wonder
if
it
is
so.
If
it
is
so
involved,
we
may
have
to
break
it
down
to
subsequent
jobs
to
be
done.
Mm-Hmm,
like
there's
different
steps
for
that
one.
Instead
of
taking
it
as
a
big
chunk
of
things,
then
maybe
we
might
have
to
break
it
down.
Just
depends
on
how
you
have
to
do
it,
how
you
have
to
go
through
the
process,
because.
B
E
A
E
Might
need
to,
depending
on
how
specific
that
one
two
statement
is
to
what
we
do,
because,
like
you're
saying
earlier,
Jackie
about
like
I'm,
not
sure
what
they
want
to
do
with
environments
I'm,
not
sure
if
our
thing
does
what
they
want
to
do.
That
might
require
us
to
do
some
more
interviews
to
understand
a
little
bit
more
about
what
they're
trying
to
accomplish
even
outside
virtual,
and
sometimes
it
doesn't.
You
know
just
moves
on
one
day:
okay,.
E
So
it
would
be
and
said:
I
want
to
I'm.
Sorry
I
was
just
I
was
thinking
maybe
like
instead,
that
one
is
like
I
want
to
deploy
and
then
click
something
in
there
that
doesn't
specifically
be
environments
and
get
labs
like
what
is
environment
supposed
to
be
doing.
Why
would
they
want
to
deploy
to
something
like
that?
That's
the
only
pair
I
feel
like
we
have
to
change.
However,
if
we
don't
know
why
so.
E
D
A
A
A
In
that
we
are
going
to
use
Hoshi
court
vault
as
our
de-facto
secrets
management
tool,
but
the
first
iteration
doesn't
have
to
be
about
Hoshi
Corp.
It
can
be
about
integrating
with
any
secrets
provider
and
creating
a
generic
tooling
for
that,
and
then
prescribing
that
vault
be
the
only
way
that
you
integrate
with
this,
and
that
was
interesting
because
the
job
to
be
done
is
I
want
to
deploy
to
a
production
state
with
a
token
so
that
I
can
be
secure
in
the
product.
A
I'm
producing
for
my
customers
so
like
when
we
take
when
we
distill
that
down
to
secrets
like
we
just
have
to
surface
that
token
to
that
right,
project
to
that
right
person,
and
it
can
be
done
in
a
variety
of
different
ways
and
the
way
that
the
verify
team
is
doing
it
is
by
having
rails
fetch
a
secret
from
vault
and
pass
that
over
to
you,
the
runner.
But
we
could
also
create
an
identity
API,
which
I
thought
that
we
had
to
create
an
identity
API
for
vault.
A
But
really
we
can
create
just
an
API
endpoint
that
can
take
any
sort
of
token
and
I'll
sent
it
back
back
to
authenticate
it
back
to
a
policy,
and
it
accomplishes
that
same
job
to
be
done.
But
it
doesn't
doesn't
require
us
to
be
so
focused
on
making
fault
happen.
It
enables
the
job
to
be
done
without
being
so
vendor
locked
in
so
that's
kind
of
an
interesting
thought
there
make.
B
Sense
and
I
think
kind
of
related,
but
not
that
those
you
just
need
to
be
a
bit
pay
attention
because,
like
what
you'll
always
say,
those
jobs
to
be
done
might
treat
your
problem,
validation
and
I.
Think
that's
that's
fine,
but
it
just
makes
you
just
need
to
be
clear
to
us.
That's
we
are
founded
in
a
problem
and
not
working
like
what
you're
saying
on
a
specific
solution
for
this.
For
this
task,
so
kind
of
be
clear
with
the
scope
is
all
for
the
this
quarter.
A
B
A
So
I'm
really
excited
about
this
one
because
we're
the
first
group
to
actually
be
proactively
working
outside
of
our
stage
to
create
a
comprehensive
story
with
get
lab,
which
is
a
very
cool
thing.
We're
not
only
doing
this
with
compliance,
but
we're
also
going
to
be
doing
this
upstream
in
issues.
So
we'll
have
releases
be
a
time
box
that
a
customer
can
select
and
therefore
making
releases
like
man
mandatory
like
it
becomes
a
time
box
for
somebody
to
then
leverage.
A
So
our
adoption
could
like
really
skyrocket
if
we
support
this
as
just
a
native
behavior
that
people
do
one
organizing
code
and
planning
releases.
So
that's
a
very
cool
prospect
for
us,
but
I'll
I'll
update
us
and
I'll
update
us
in
the
next
biweekly
meeting
to
talk
about
like
where
this
scope
is
going.
A
But
how
it'll
Nestle
furnish
is
that
you
can
select
the
tag
like
name
from
a
pre-populated
list
of
releases,
on
your
issues
and
on
your
mrs
and
that's
how
plan
is,
is
thinking
about
roping
and
releases
as
a
part
of
a
time
box.
So
if
you've
already
have
a
release
created-
and
you
want
to
assign
issues
to
it,
you
can,
if
you
don't
have
a
release
created
you'll,
have
the
ability
to
create
a
release
from
an
issue.
A
B
D
A
Yeah
and
I
think
like
jobs,
to
be
done
to
be
kind
of
hard
from
the
technical
implementation
side
anyways,
because
you're
just
gonna
get
like
a
a
user
story
that
defines
the
problem,
which
is
what
Hana
and
meister
my
job
is
and
then
from
your
side,
you
like
will
instrument
it.
But
now
you
understand
like
why.
Sometimes
the
problem
isn't
clear
in
these
instrumentation
issues
is
because
you
don't
really
understand
it
and
we're
just
trying
to
put
like
a
bandaid
on
it.
So
yeah.
D
A
Empowers
you
to
be
like
Jackie.
This
is
give
me
a
better
one,
all
right!
Well
we're
at
time.
Thank
you
guys.
So
much
I'll
move
the
next
topics
to
our
following
think,
big
and
appreciate,
if
you
have
any
other
feedback
how
to
make
this
better
for
us,
just
let
me
know
got
me
line
awesome
right,
bye,
all.