►
From YouTube: Release Management Think Big #11
Description
Welcome to the 11th Think Big For Release Management
- https://gitlab.com/gitlab-org/gitlab/-/issues/26411
A
B
A
I
would
say:
I've
seen,
customers,
leverage
releases
and
other
products
like
github,
for
example,
to
track
the
state
of
a
production
deployment,
but
also
they
attach
things
like
assets
and
other
objects
or
binaries
to
that
release,
object
to
be
downloaded
by
other
people.
So
it
really
is
like
a
snapshot
of
what
would
be
a
production
environment
for
somebody
else
to
consume.
A
So
that's
definitely
a
valid
use
case
when
we
go
up
against
tools
like
zbo
labs
or
pluto
ax,
there's
an
expectation
and
the
deployment
space
that
there's
a
way
to
trace
the
current
state
of
their
production
code
or
the
version
that's
in
production.
While
they
have
another
work-in-progress
version.
This
way
they
can
have
like
production,
SAS
code,
that's
live
on.
A
mobile
device
might
lag
behind
the
web
application,
so
they
would
want
to
be
able
to
display
on
the
page
that
the
web
application
has
this
version,
and
the
mobile
has
this
version
of
the
code.
B
Okay,
I'm
wondering
if
that
almost
sounds
like
a
better
fit
for
the
environments
page
like
we
should
be
building
that
into
the
environments,
because
that's
really
what
that
page
is
about
is
about.
What's
like.
What's
live
so
I'm
wondering
if,
if
we
shouldn't
be,
if
we
could
almost
be
discouraging
the
releases
page
for
that
purpose,
so.
A
That's
why
I
added
my
second
bullet
point.
My
first
bullet
point
here,
third
bullet
point
in
the
list
about
environments,
overview
and
problems
that
customers
are
looking
to
solve
because
he
started
jogging
like
some
of
the
things
that
we're
digging
into
with
the
environments
page
today
at
scale,
customers
are
unable
to
wrangle
the
environments.
There
isn't
really
a
great
way
to
consume
that,
and
they
end
up
having
to
you
navigate
from
the
environment
page
or
via
list
into
the
pipeline
for
the
deployment
to
see
their
production
State.
A
And
if
we
look
at
a
company
that
has
1,300
developers
pushing
to
that
production
environment
multiple
times
a
day,
it
would
be
virtually
impossible
to
see
what
is
the
state
of
their
production
code.
So
that's
why
they're
leveraging
the
release
object
as
a
container
for
all
of
these
changes
that
this
is
a
representative
production
State
with
this
attached
binary
that
we
compiled
in
a
docker
and
is
now
living
in
in
a
different
environment
somewhere
else
right.
C
A
Our
ethics
that
PI
and
I
are
working
on
right
now,
we're
grouping
together
all
of
the
features
and
the
redesign
issues
and
the
environments,
dashboard
problems
and
validating
with
customers
like
how
are
they
using
these
things
today?
Is
that
even
the
right
and
that
they're
doing
and
what
I
found
is
that
the
environments
are
representative
of
the
deployment
meaning.
This
is
something
that
is
live,
whether
that's
in
a
testing
State
or
in
a
production.
State
and
customers
are
very
interested
in
all
the
contributions
to
those
states
and
perspectives.
A
So
having
a
release,
tag
on
the
environment
could
be
misleading
if
developers
are
tagging
each
of
their
changes
to
a
master
branch,
for
example,
with
the
release
tag.
So
it
depends
on.
If,
if
we
break
the
connection
between
tag
and
release
and
people
aren't
auto-generating
releases
for
every
sort
of
production
change,
then
I
could
see
that
being
really
usable.
Otherwise,
it
really
would
just
be
currently
what
we
have
is
to
commit
back
to
that
that
last.
C
A
But
I
could
see
a
use
case
for
the
customers
that
are,
for
example,
using
get
love
for
inter
sourcing
or
embedded
software,
where
the
release
tag
is
the
last
commit
about
pushing
all
of
these
changes
to
a
particular
location
or
environment.
And
it's
like
it's
a
it's
almost
like
representative
of
the
final
reduction
deployment.
That
would
be
a
use
case
where
they
would
want
to
see
the
release
tag
on
the
environment,
but
sometimes
that's
not.
C
B
See
yes,
I
can
imagine
a
lot
of
cool
ways
to
kind
of
tie.
The
two
together
like
you
could
almost
in
that.
If
we
somehow
could
associate
the
two
like
gonna
say
this
release
it
running
in
this
environment
like
on
the
releases
page
we
could
show
currently
and
deployed
to,
or
you
could
even
do
things
like
somehow
like
drag
and
drop
a
release
onto
another
like.
A
Think
showing
showing
the
quicken
BC
would
be
connecting
the
last
environment
for
that
release.
So,
for
example,
if
we
have
an
upcoming
release-
and
this
would
require
us
to
have
the
fracture
between
tag
and
release
because
you'd
have
an
upcoming
or
at
least
out
of
tag,
and
if
they
were
to
do
a
commit
it
could
show.
This
is
now
in
the
review
app
stage
and
that
could
be
like
a
whole
approval
workflow
that
we
could
build
out
for
customers
who
are
wanting
people
to
approve
a
review
out
prior
to
deployment
to
production.
B
A
You're
not
not
at
all,
it
is
it's
it's
challenging,
though,
because
we're
seeing
that
customers
are
merging
several
of
the
tools
that
used
to
be
in
their
toolkit
in
certain
and
they're
kind
of
shoehorning.
Certain
functionality,
for
their
use
case
so
like
releases,
are
not
only
being
used
to
distribute
binaries
as
asset
links,
but
they're
being
used
to
snapshot
the
production
code,
they're
being
used
to
create
that
traceability
between
an
issue
and
and
the
release
via
the
connection
with
milestones
so
eventually,
we'll
have
to
see
where
things
like
release.
A
Evidence
takes
us
because
release
evidence
is
something
that's
showing
a
change
from
a
release
tag
and
it's
supposed
to
contain
the
artifacts
as
a
snapshot
of
the
deployment
of
the
change
that's
been
made
of
the
release
rather
and
customers
are
going
to
use
that
as
evidence
to
an
auditor
for
what
what's
changed
in
their
environment
or
in
their
production
state.
So
it's
like
the
eventually
we'll
be
merging
sort
of
those
two
points
of
release,
deployment
and
environment
in
that
sort
of
context.
A
B
Thank
you
you
mentioned
like
the
auditing,
so
is
that
kind
of
where
release
evidence
comes
from?
Is
they
want
to
know
the
difference?
I
haven't
worked
with
that
feature.
Much
I,
don't
have
a
great
understanding
of
it,
but
is
that
just
to
understand
in
a
deployed
environment,
what's
changed
between
the
two?
Exactly
so.
A
A
That'll
make
people
who
are
using
like
deploy
boards
and
kubernetes
clusters
and
multiple
environments
for
Bluegreen
deployments
and
advanced
deployments,
really
challenging.
I
think
that
that
was
one
thing
that
Ori
started
going
down.
The
road
of
where
should
release
evidence
live,
and
this
is
where,
if
we
have
a
release
tag
associated
with
a
particular
job
that
that
kind
of
refines,
the
point
of
which
you're
wanting
evidence
we
captured.
Otherwise,
we
could
have,
like
millions
of
evidence,
is
captured
for
each
deployment
to
a
kubernetes
cluster.
A
C
C
A
B
One
as
I
typed,
it
out
I
think
I
I
kind
of
clarified
it
myself,
but
we
have
right
now
we
have
we're
adding
a
lot
of
links,
so
different
types
of
links
and
I
I'm,
just
trying
to
think
through
we
kind
of
have
things
that
could
be
directly
associated
with
release
or
they
could
be
released
assets
or
we
could
have
asset
links.
And
now
we
have
like
different
types
of
links,
I'm
wondering
if,
instead
we
should
simplify
it
all
just
two
assets
and
say
like
instead
of
having.
B
Yeah
I
guess
I
was
trying
to
think
through
what
what
should
be
an
asset,
what
should
be
an
asset
link
but
then
I
realized.
These
are
all
links
that
we're
adding
they're
like
they're
all
URLs,
so
it
it
does
make
sense
that
they're
links
and
then
eventually,
if
we
have
like
a
internal
connection,
maybe
that's
when
it's
no
longer
a
link
and
that's
rather
just
an
asset
yeah.
A
So
I
think
when
we
extend
the
release,
Co
I,
to
be
able
to
actually
upload
objects
to
a
release
and
store
those
in
a
package,
a
generic
package
registry.
We
support
this
idea
of
an
actual
asset
being
a
fixed
and
stored
on
a
release.
Today
we
don't
have
storage
on
a
release,
so
we're
relying
on
this
concept
of
an
asset
link
to
represent
that
this
is
something
that's
it
attached
to
their
release,
but
we
don't
have
storage
for
it.
A
A
Asset
links
will
probably
go
away,
like
people
will
start
just
uploading
things
directly
to
a
release
object,
but
we
would
support
asset
links
forever
because
there's
probably
other
objects
there
wanting
to
link,
for
example,
they
may
cross
link
releases
in
different
groups
until
they'd
be
like
here
is
an
asset
linked
from
one
release
to
another,
really
kind
of
going
back
to
my
mobile
app
deployment.
Where
it's
a
lagging
reversion
to
a
web
app,
so
that's
something
to
to
be
mindful
of
this
I
think
this
is
kind
of
something
that
we
are.
C
Right
can
I
just
add
something
to
that.
Looking
from
the
side
that,
if
you
perspective
so
just
just
say,
yeah
so
assets
source
code,
so
they're
they're
actually
they're
a
link,
but
you
know
they're
generated
from
from
the
commune
right.
So
so,
yes,
we
are
storing
them,
but
we're
still
family
now
git
repository
and
then
with
the
other
four
that
we've
just
kind
of
added.
C
You
know
today
the
asset
links
you
know
so
that
so
there
are
kind
of
see
them
as
their
alma
tree
things
that
get
matted
too,
like
we
always
have
the
source
code
and
it's
always
more
less
code
changes.
But
these
these
other
links.
They
could
be
anything
you
know
and
they
could
be
arbitrary
and
they
could
differ
between
different
releases.
The
only
thing
I
didn't
kind
of
get
in
your
paragraph
Nitin
was
ripped
links.
The
milestones.
B
B
C
B
A
Yeah,
so
updating
a
release,
note
from
a
user
that
in
I
think
exclusively
in
the
CLI,
was
something
that
they
just
weren't,
that
it
was
a
behavior
that
they
weren't
doing
so
they
were
just.
They
were
curling
the
release
API
and
found
it
easier
to
append
an
asset
link
than
to
create
a
release.
Note
as
a
string.
C
C
A
They
started
to
like
look
at
how
the
delivery
team
is
doing
the
changelog
today,
and
it
currently
is
like
an
aggregation
from
this
section
on
the
mr
for
the
for
each
of
your
developers,
where
you
have
like
your
title
and
then
the
mr
link
and
a
brief
description
and
that's
aggregated
and
bashed,
and
then
scripted
into
their
release.
Notes
I
mean
they're
in
their
own
job,
and
what
we
want
to
do
is
build
that
kind
of
functionality
inside
of
get
lab,
but
we
realized
I
get
side
our
product.
A
We
realize
that
a
lot
of
customers
aren't
necessarily
leveraging
that
sort
of
functionality
where
they
have
like
a
markdown
file.
That's
describing
this,
mr,
but
instead
they
you're
they're
using
message
commit
messages
to
indicate
that
this
chain,
what
this
change
is
so
giving
customers
the
flexibility
to
append
back
information
to
their
release.
Object
is
broader.
It's
a
broader
use
case
than
what
we're
doing.
A
What
value
is
release
links
providing
versus
updating
that
release
notes?
So
today
people
are
using
releases
in
some
cases
as
a
container
for
productions
current
state,
so
we
have
three
users:
I've
talked
to
directly
about
embedded
software,
so
they're
linking
their
binaries
to
that
release
and
then
publishing
that
release
to
their
internal
customers
to
download
and
then
deploy
to
a
radio
to
an
RV
to
a
different.
A
You
know
smart
machine,
so
in
that
use
case,
asset
links
are
super
fundamental,
because
that
is
the
declared
version
that
people
are
allowed
to
then
download
into
all
of
these
other
machines
and
hardware
for
inter
sourcing
people
have
images
that
they
are
setting
up
for
all
of
their
developers
to
use,
and
they
have
different
security
patches
on
it.
They
have
improvements
that
they're
making
from
their
infrastructures
code
use
case
and
they
publish
that
each
month
for
each
quarter,
for
developers
to
then
pull
down
and
use
as
their
duplication
for
like
testing
environments,
for
example.
A
So
it
has
all
the
seed
data
in
it.
It
has
all
of
the
the
relevant
information
for
developers
to
locally
test
code
that
they're
deploying.
So
that's
the
second
use
case
that
I've
seen
releases
be
for
like
the
declaration
that
this
is
stuff
you
can
consume.
An
asset
links
are
then
linking
to
artifactory
or
linking
to
another
container
registry.
B
A
E
A
A
C
Just
because
we
had
to
cut
the
zones
it
I
was
so
I
wasn't
sure
whether
we
had
all
four
asset
link
types
and
so
I
caught
so
as
I
put
it
in
the
in
the
notes,
I
call
it
I
started
was
tight,
but
even
picked.
I
hid
a
very
few
problems
with
the
word
type,
so
I
switched
to
one
time
but
yeah,
so
I
added
all
four
initially
and
so
I
guess.
The
only
thing
to
really
discuss
is
this.
C
This
concept
of
you
know
the
heuristics
of
trying
to
determine
what
the
link
is
and
I
think
we've
more
less
decided
that
we
we
will
do
this
going
forward
right
and
I.
Imagine
the
place
to
do.
That
would
actually
be
the
UI
as
you
entered
it.
As
you
put
in
the
link.
The
only
thing
is
in
the
current
Drive.
C
B
It'd
be
a
little
weird
if
you
first
came
to
type
and
it
paid
something
and
then
it
flips
it
does
anything
else.
Yeah,
maybe
I,
knowing
that
the
type
drop-down
is
later
in
the
form,
so
I
think
most
people
would
probably
kind
of
fill
it
out
sequentially.
But
yes,
that
would
totally
be
at
risk
or
we
I
mean
we
could
get
really
fancy
and
say
only
automatically
flip.
The
type
if
you
haven't
already
touched
it.
C
A
More
just
like
how
are
we
expecting
users
to
you,
interface
with
assigning
a
link
type
going
forward
if
we
do
have
heuristics?
Okay,
so
let's
say
when
we
when
we
talked
with
our
customers
and
we
were
reviewed,
the
release
prototypes.
There
was
two
internal
ones
and
three
external
ones.
When
they
were
looking
at
assets
and
adding
links,
one
of
the
things
they
did
call
out
was
being
able
to
organize
and
bucket
these
links
so
that
people
knew
what
they
were.
Not
just.
A
This
long
string
of
this
with
an
external
source,
parentheses
right,
so
I
think
the
problem
of
being
able
to
improve
the
discoverability
of
the
things
that
are
linked
to
a
release
will
be
solved
by
the
drop
down
menu.
Now,
whether
or
not
people
are
have
like
a
pre-populated
option,
whether
that's
already
other
and
then
they
have
to
manually
reassign
it
for
historical
releases,
I
think
that
that's
that's
acceptable,
but
going
forward.
A
It
would
be
really
crummy
for
them
to
be
in
the
UI
and
be
creating
their
asset
link,
save
it,
and
then
they
have
their
drop-down
menu
selected,
but
it
pre-populate
something
else
so
mm
I
would
say
that
is
there?
Is
there
a
way
to
avoid
that
workflow
like
I'm,
adding
an
NPM
package
and
I
actually
selected
package,
but
then
for
some
reason,
that
particular
link
didn't
recognize
the
package
URL
that
I
selected
and
then
it
pretty
popular
yeah.
C
A
E
A
E
I
think
also
in
the
future.
We
have
some
issues
about
like
allowing
drag-and-drop
and
allowing
other
ways
to
add
release
assets.
So
now
we're
talking
only
about
the
links
right,
so
people
might
be
one
who
I
want
to
categorize
those
as
well
so
with
the
application,
be
able
to
immediately
recognize
and
label
that
differently
in
the
interface
I.
Think
the
drop-down
yeah
it's
a
lot
different,
it's
an
easier
way,
but
I
wonder
if
it
will
be
more
prone
to
errors.
A
Like
I'm,
okay,
with
our
MVC
going
with
as
is
and
then
following
the
bugs
that
come
in
with
that
and
prioritizing
those
quickly
I
think
it's
low
risk.
It
will
be
annoying,
but
I,
don't
think
it
would
prevent
people
from
adding
asset
links
and
classifying
asset
links,
because
I
imagine
that
they
create
an
asset
link
say
that
they
populate
the
little
drop-down
menu
if
they
click
Save
and
then
holy
crap
holy
cow.
That's
actually
a
package,
and
it
says
it's
other
I
think
that
they
would.
The
page
would
refresh
they'd
go
to
the
releases
page.
A
They
would
see
that
that
is
actually
classified
as
other
and
then
they'd
click
edit
and
they
would
select
the
drop-down
menu.
So
it
would
probably
add
you
know,
like
four
clicks,
to
their
journey
of
saving
that
release
asset.
But
as
long
as
we
have
in
the
documentation
that
you
may
need
to
manually
reassign
it
after
you
create
an
asset
link
in
the
UI.
C
A
A
C
A
I'm
uncomfortable
absorbing
the
the
risk
that
we
have
with
an
irritation
if
they
eristic
overrides
what
a
user
initially
puts
in
during
the
API
during
the
EM
the
UI's
entry.
My
thoughts,
though,
would
be
most
people
who
are
using
asset
links
are
generating
them
via
machine,
so
I
would
imagine
that
they
would
assign
a
link
type
at
that
time.
B
Kind
of
a
related
note
is
this:
would
guessing
the
the
type
with
that
is
it
purely
for
the
convenience
of
the
user?
Is
that
what
be
the
purpose
of
that
so
I'm
not
sure
to
be
honest,
like
it's,
just
one
drop
down
I'm,
not
sure
that
it's
worth
doing
a
lot
of
heuristics
to
try
to
decide.
It
seems
like
we're
not
really
saving
that
much
time.
Yeah.
A
It
might
be,
it
would
be
nice
if
we
were
looking
historically
right
for
it
to
be
like
a
data
integrity
thing,
but
we
decided
that
there
might
be
a
lot
of
misclassifications.
So
that's
likely
not
the
best
way
to
go
to
the
heuristic
would
be
for
the
convenience
of
people,
as
they
add
asset
links,
because,
for
example,
say
that
they
curl
the
API
add
an
asset
link.
They
didn't
update
their
script
to
include
type
auto.
Recognizing
type
would
allow
them
to
render
the
benefit
of
having
a
type
selection.
D
A
C
Yeah
I
mean
we've
seen
this
with
production
in
data
integrity
issues
like
okay.
Yes,
we
can
look
in
good
local
and
we
can
see
what
the
problems
are.
You
know
when
it
comes
to
self
hosted.
We
have
no
visibility
and
if
we've
got
a
cleanup
script,
you
know
it
could
have
unforeseen
consequences
and-
and
that's
just
kind
of
routing
invisibly
in
the
background,
during
the
afraid
and
yeah
I,
think
it's
good
to
be
very
cautious
on
themselves.
Yeah.
A
So
for
this
MVC
for
the
one
that
we're
building
out
right
now,
I'm,
not
convinced
that
a
heuristic
is
completely
necessary.
Nathan,
going
back
to
your
point,
I,
don't
know
if
the
juice
is
worth
the
squeeze
and
if
it's
going
to
be
a
lot
of
complexity,
then
I
would
say
we
should
forego
and
just
implement
the
type
and
have
it
default
to
other,
and
then
people
often
you
know
if
we
find
that
users
are
like
asking
for
this
feature.
We
have
the
issue
created.
We
also
have
this
idea
of
creating
relationships
between
objects.
A
Their
gait,
lab
native
I
think
that
that
would
be
more
useful
down
the
road
like
the
whole
idea
of
a
direct
link
that
you
referenced
milestones
for
creating
those
direct
links
and
deep
linking
people
into
other
areas.
The
application
would
help
us
accomplish
a
more
unified
experience
and
get
lab
anyways
for
those
personas,
so
I
think
that's
I
think
we
can
solve
this
in
different
ways
without
having
to
go
through
heuristics.
C
A
We
have
three
minutes
left.
Let
me
give
you
a
little
bit
of
a
preview
for
what
we'll
talk
about
in
our
next
think.
Big
session.
Hi
and
I
are
working
through
our
user
stories,
around
environments
and
I'm
learning
a
lot
I'm
learning
a
lot
about
how
much
customers
want
to
connect
deployments
to
environments,
I'm
learning
a
lot
about
how
much
customers
are
doing
in
Jenkins,
for
pipeline
deployments
and
for
their
pipeline
management
and
environment
deployments,
and
how
they're
looking
to
organize
and
see
that
information.
A
In
the
environments
view
I
also
have
validated
with
customers
that
our
environments
dashboard
today
is
unusable,
because
it
only
allows
you
to
see
I
think
it's
three
environments
across
seven
projects
or
the
other
way
around.
It
has
such
a
limited
subset.
So
we
do
have
on
our
owner
build
board
right
now,
a
schedule
for
pagination
expanding
the
amount
of
environments.
You
can
at
least
see
on
the
environments
dashboard
and
then
that
will
help
customers
at
least
inch
toward
this
management
at
scale.
A
But
we
will
need
to
redesign
how
the
environments
dashboard
I,
have
this
idea
on
here
about
a
heat
map
and
adding
Geographic
that
static
of
all
the
environments
that
somebody
has
in
their
group
and
it
would
be
green,
red
and
gray,
or
what
kind
of
gradient
makes
sense
to
show
like.
What's
live
and
active,
what's
been
stopped
or,
what's
you
know,
inactive
or
not
not,
doesn't
have
a
deploy
MIT
to
it.
A
That
would
have
all
the
current
tiles
that
you
see
in
the
environments
dashboard
the
kinds
of
things
that
people
are
seeing
today
and
managing
their
environments
are
these
two
images
that
I
dropped
here:
people
this
is
from
Jenkins,
they
have
their,
they
have
a
matrix
and
they
have
the
environment
name
on
the
left-hand
column,
and
then
they
have
columns
for
the
different
builds
that
are
running,
that
that
are
running
on
that
environment
and
the
other
item
that
will
preview
that
I'm
previewing.
We
can
talk
more
about
it
in
our
next
thing,
fake.
A
D
Looking
at
digital,
AI
or
formal
exhibit
labs,
that's
like
a
release
calendar
over
there
and
I'm.
It's
not
necessarily
the
environment,
and
curiously,
we
probably
do
differentiate
those
two
like
what's
the
goal
here,
to
really
show
the
stages
of
the
environments
and
the
amounts
of
them
spin
up
or
really
like,
came
what
was
released
on
what
they
kind
of
I.
A
A
But
we
use
a
bunch
of
upstream
features
like
milestone,
views
to
give
us
the
calendar
view
today.
So
there
just
might
be
some
opportunity.
We
have
to
leverage
that
from
like
a
release
planning
standpoint,
but
this
is
more
like
if
you
have
an
active
deploy,
freeze
and
your
group
being
aware
that
that
deploy
freeze
is
there
so
you're,
not
scheduling
a
deployment.
I
see.