►
From YouTube: Think Big: Release Management - US/EMEA
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
By
the
way,
redirects
kind
of
got
merged
in
tests
option,
at
least
just
like
18
minutes
ago.
B
B
Oh
yeah
yeah
welcome
to
our
18th
think
big.
This
is
the
emea
u.s
time
zone,
I'm
here
with
vlad.
It's
just
us
two.
I
have
a
couple
of
topics
on
the
agenda.
B
One
of
them
sean
posted,
we'll
wait
to
see
if
he's
going
to
join,
but
the
other
one
I
wanted
to
talk
about
was
release
evidence
I'll,
go
ahead
and
drop
an
issue
in
the
chat
and
I'll
go
ahead
and
present
my
screen
and
we
can
talk
through
it
a
little
bit.
So
I
learned
recently
that
release
evidence
has
a
couple
of
limitations
around
performance,
one
of
them
being
when
we
used
to
include
issues
and
mrs,
it
was
a
really
big
file
and
has
the
opportunity
to
be
a
really
large
file.
B
And
then
I
learned
the
compliance
team.
Has
this
feature
called
a
chain
of
custody
report
which
is
all
of
the
merge
commit
merge,
commit
sha,
merge,
request
id
user
pipeline
id
project
all
of
the
details
that
we
would
want
for
release
evidence
inside
of
a
csv
file.
So,
instead
of
adding
merge,
request
data
to
the
release,
evidence,
I'm
wondering
if
there's
a
way
for
us
to
append
this
chain
of
custody
report
to
release
evidence.
A
Sorry,
having
trouble
on
youtube
myself,
yeah
yeah,
actually
a
good
idea.
I
like
it.
I
haven't
looked
much
at
this
compliance
report,
is
it
generated
by
the
pipeline
inside
gitlab
or
what.
B
Yeah,
I
think
it
is.
It
is
a
csv
file,
though
so
I'm
not
quite
sure,
if
they're,
just
if
they
export
it
as
a
like
if
they
generate
json
and
then
export
it
as
a
csv
to
the
front
end
first
or
like
I'm
not
sure
if
they
ever
populate
a
json
raw
file
to
the
front
end
or
if
it's
just
a
csv.
B
A
Yeah,
actually,
I
guess
I
need
to
spend
a
little
time
looking
at
what
it
is,
but
if
it's
generated
by
the
pipeline
and
it's
a
report,
then
it's
kind
of
already
included
in
the
evidence
by
the
issue.
We
worked
on
a
few
months
ago,
which
was
included
in
artifacts.
So
if
it
worked
the
same
way,
it's
kind
of
already
there,
but
only
a
link
to
the
this
compliance
report.
A
A
A
A
Actually,
if
it's
an
artifact
inside
the
pipeline,
there
will
be
a
small
limitation
that
it
should
be
created
before
release
is
created,
or
there
is
another
issue
about
waiting
for
the
pipeline
with
the
release.
To
finish
this
way,
we
can
work
around
this
also
yeah.
That's
some
initial
sets.
B
That's
awesome
that
gives
me
good
perspective
there.
I
see
that
one
of
the
items
you've
added
to
the
parking
lot
think
big
hierarchical
deploy
boards.
Do
you
want
to
talk
a
little
bit
about
that
item?.
B
A
Yeah
actually
kind
of
have
to
remember
it
was
something
about
this
group
environments,
something
like
you
have.
We
already
have
a
deploy
boards
right
for,
at
least
if
you
use
auto
devops,
for
example,
with
kubernetes
right,
and
we
were
speaking
about
environments
like
group
environments
right
to
see,
which
is
on
which
stage
different
jobs
in
different
projects,
different
pipelines
and
different
projects
for
the
same
environment.
If
you
have
front
end
and
back
end
in
different
projects,
then
you
have
a
production
environment
for
both
of
them
yeah
I
yeah.
A
So
I
like
the
idea
when
I
first
heard
about
this
group.
Environment
dashboard
was
that
maybe
we
can
use
these
deploy
boards
somehow
to
make
them
like
hierarchical,
so
basically
move
them
to
the
group
level
as
well.
But
that
was
just
an
idea
and,
to
be
honest,
I
touched
deploy
boards
more
than
a
year
ago
last
time,
so
I
don't
have
a
good
idea
how
they
even
work
right
now,
so
maybe
maybe
not
the
best
idea.
It
was
just
in
the
discussion.
B
That's
okay.
I
think
it
was
a
good
idea.
It's
something
that
we've
been
thinking
about
in
our
three-year
vision,
mocks
like
creating
a
swim
lane
view
of
our
environments,
so
that
you
can
transition
your
different
environments
through
those
production
to
pre
on
its
path
to
production.
I'm
trying
to
find
the
mocks
that
demetri
and
hayana
have
been
working
on
and
I'll
show
my
screen
in
just
a
little
bit.
B
Yeah,
so
this
is
kind
of
like
creating
a
deploy
board
for
non-kubernetes
environments,
because
the
deploy
board
we
do
have
works
really
great
when
you
have
cluster
management
and
you're
incrementally
rolling
out
to
clusters,
not
so
great,
if
you
just
have
a
series
of
aws
urls
right,
so
hopefully
we
can
build
something
more
like
this.
Inside
of
our
dashboard
view,
I
like
what
you're
thinking
there,
though
that
makes
a
lot
of
sense.
B
A
Oh
honest,
I'm
not
super
familiar
with
what
we've
done
about
the
run
books
feature
issue
type
yeah,
I
mean
it
kind
of
people
already
do
that
right.
We
do
that
for
pages.
We
do
that
for
our
own
releases,
including
security
releases,
so
it
kind
of
makes
sense,
I'm
not
sure
if
we
need
a
specific
issue
type.
One
thing
that
crossed
my
mind
like
what,
when
you
were
describing
just
a
minute
ago,
you
said
that
people
want
to
like
schedule
deployment
in
the
future.
B
A
As
far
as
I
know,
we
don't
have
this
capability
right
now.
You
can
create,
like
manual
jobs,
a
lot
of
them,
and
then
I
mean
you
can
have
like
automatic
pipeline
prefixed
by
one
manual
job
which
is
kind
of
the
same
right.
Maybe
that's,
maybe
that's
the
way
to
go
by
the
way.
A
So,
what's
like
what
I
see
like
a
super
small
hack,
is
that
just
having
some
kind
of
button
or
link
in
the
issue
on
maybe
checkbox,
which
will
just
run
this,
let's
say
just
build
in
the
pipeline?
So
if
you
create
a
pipeline
first
drop
in
which
will
be
manual,
so
it
won't
trigger
anything
when
you
create
it.
A
But
when
you
like
press
when
you
in
the
issue,
let's
say
check
the
check
box
or
something
and
it
has
a
specific
link
for
a
job
or
something,
then
this
job
will
be
started.
It
will
do
nothing,
but
it
will
unlock
the
whole
pipeline.
So
but
I
don't
know
at
the
same
time,
it
kind
of
sounds
crazy.
A
little
and.
B
Well
complicated
because
it's
creating
like
a
framework
for
for
steps
in
automation
that
people
are
already
building
into
pipelines,
but
it's
like
we're
asking
people
are
asking
for
a
manual
intervention
to
then
track
the
sequence
of
these
steps.
So
you're,
absolutely
right
like
it
does
seem
a
little
legacy.
It
doesn't
seem
a
little.
It
doesn't
seem
as
mature
in
continuous
delivery
as
it
could
be,
but
organizations
who
have
formal
release
managers
often
look
to
an
individual
to
pull
the
trigger
for
a
production
deployment.
B
I
like
this
idea
of,
and
why
I
thought
a
specific
kind
of
issue
type
for
a
runbook
is
so
that
we
could
tailor
like
issue
approvals
for
a
run
book,
so
we'd
create
like
an
approval
workflow
for
run
book
issue
types
I
think
inside
of
the
general
schema
the
the
team
would
like
to
defer
approvals
to
merge,
requests
and
not
have
like
an
approval
workflow
inside
of
issues,
but
if
it's
a
different
kind
of
issue
that
may
not
be
as
controversial,
because.
A
B
Book
a
burn
book
has
sequences
and
steps,
and
you
know
you'd
want
to
gain
different
ways
of
of
gating
various
activities.
Inside
of
this
pretty
much
big
pipeline
for
your
deployment
and
it's
tied
to
eventually
scheduling
your
your
deployment
at
the
end
or
multiple
deployments,
because
it
could
be
you're
wanting
to
tie
all
of
your
deployments
for
your
application
from
this
one.
Runbook.
A
A
Is
protected,
maybe
we
need
some
kind
of
just
like
currently
this
job
does
nothing
right.
It
just
is
there
to
press
a
button,
and
only
certain
people
can
do
that,
but
maybe
we
can
actually
enhance
this.
Some
some
somehow
just
create
a
virtual
virtual
step
in
the
pipeline
and
say
that
this,
like
I
don't
know
only
these
people
are
allowed
to
press
this
button.
B
I
think
we
support
today,
I
think
the
the
action
that
would
be
different
here
is
triggering
that
from
an
issue
or
triggering
that
like
pressing
that
button
from
a
different
place.
So
let's
say
that
your
pipeline
runs
and
your
application
has
built
you've
aggregated
all
these
changes
from
these
different
projects
and
now
they're
going
to
this
group,
and
this
group
is
going
to
release
to
a
production
deployment
like
we're
way
in
the
future.
We
already
support
shared
environments.
Like
that
kind
of
thing.
A
user
gets
an
email
notification
to
approve
a
production
deployment.
B
This
email
notification
would
allow
them
to
click
this
approve
button
and
it
would
bring
them
to
a
run
book
issue
which
would
then
enable
them
to
either
approve
or
reject
when
they
hit
approve.
That
would
press
the
play
button
today
on
the
manual
protected
job.
That's
in
that
pipeline
view
in
my
head,
that's
like
how
that
would
work.
A
Would
it
be
like
I
mean
currently,
if
we
look
at
the
merge
requests
approval
pattern?
What
we
have
there
is
that
we
have
approval
rules
for
specific
changes
for
code,
for,
like
specific
people
need
to
approve.
If
this
was
changed,
we
also
have
a
restriction
that,
like
only
certain
people,
can
approve-
and
we
have
restrictions
for
number
of
like,
like
you-
need
five
people
to
approve
this
before
it
gets
merged
right.
A
So
when
we
speak
about
the
run
books,
probably
like
it's
okay
for
you
to
deploy
to
your
dev
environment
without
any
approval
rate,
and
maybe
you
need
some
kind
of
approval
to
deploy
the
staging,
and
maybe
you
need
a
very
different
kind
of
approval
to
deploy
the
final
production
right
and
something
in
the
middle
like
a
partial
production,
or
something
like
that
so,
like
our
current
pattern
for
approvals,
doesn't
really
fit
because,
like
different
people
need
to
approve
different
steps,
it's
not
just
like
five
people
need
to
approve
them,
maybe
like
for
the
first
step.
A
So
like
what
we
basically
can
do
today,
like
just
trying
to
implement
all
this
logic
on
what
we
already
have,
we
can
have
different
like
let's
say
we
have
it:
let's
start
with
one
pipeline
right
and
so
let's
say
staging
and
production
and
two
different
approvals,
and
we
can
use
the
same
pattern.
We
currently
have
for
these
empty
jobs
which,
with
protected
environments
from
them
and
then
in
in
the
issue.
We
can
just
have
links
to
these
jobs
right
and
then
the
run
book
will
be
just
an
issue
template.
A
I
don't
like.
We
don't
have
a
good
idea
how
to
populate
these
links
automatically.
But
basically
you
need
to
create
a
pipeline,
create
an
issue
from
the
template
and
put
a
couple
of
couple
links
there.
It
won't
work
as
like
what
you
described.
B
A
Totally
they
pings
or
something
I
don't
know,
sounds
actually
what
you
were
describing
sounds
very
complex
and
like
far
away
from
what
we
have
right
now,
which.
B
B
And
then,
of
course,
we
share,
like
the
runner
project,
release
checklist
as
an
example
of
people
using
issues
as
a
checklist
for
coordinating
releases,
but
the
actions
and
the
fit
and
finish
that
people
would
like
to
see.
In
order
for
us
to
be
competitive
against
the
current
tool
sets
in
the
market,
they
are
expecting
things
like
workflow
management
approvals
across
multiple
teams
being
able
to
coordinate
multi
repo
actions.
So
it's
you're
absolutely
right
like
this.
Isn't
this
isn't
just
a
milestone
worth
of
work?
B
This
is
probably
a
year's
worth
of
work
that
I'm
talking
about,
and
it
could
be
more
if
we
add
a
bunch
of
different
features,
but
it's
this
just
idea
of
being
competitive
in
the
run
book
space
that
that
people
are
asking
about,
but
you're,
absolutely
right
like
we
have.
We
have
a
paradigm
for
approvals
that
we
need
to
think
through
today.
How
do
we
want
to
leverage
things
like
merge,
request,
approval,
workflow
inside
of
run
books?
Is
that
something
that
we
want
to
leverage?
B
A
A
B
A
B
Though
that
makes
sense,
let's
see,
do
you
have
any
other
topics,
otherwise
I
can
give
you
time
back.