►
From YouTube: Think Big: Release Management - APAC
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
So
we
are
here
for
our
19th
think
big.
We
have
the
apac
edition,
so
I
think
this
is
our
second
think
big
and
in
the
apac
meeting
I
have
two
topics
that
are
slightly
related.
One
of
them
is
easily
visualizing
applications
in
gitlab.
A
So
they
are
saying
I
have
an
environment,
that's
for
my
production
state,
that's
in
one
project
and
then
I
have
an
environment
and
a
second
project,
that's
for
the
same
customer
application,
but
I
have
no
idea
that
those
two
are
related
and
I
can't
sync
deployments.
I
can't
create
dependencies
so
they're
wanting
tools
that
help
them
visualize
the
structure
of
that
application
and
manage
deployments
of
that
application.
A
Electric
cloud
flow
in
that
you're
able
to
use
like
the
uml
visualizations
to
structure
your
application.
So
if
you'd
like
a
database
layer
or
a
front
end
or
a
end,
repository
and
you're
able
to
structure
all
of
those
and
identify
the
environment
that
populates
those
that's
that's
just
a
gap
that
people
have
cited
inside
of
our
application.
A
A
It's
one
of
our
competitors
in
the
release
orchestration
space
so
say
that
we
are
an
e-commerce
application
and
we
have
five
teams
working
on
the
e-commerce
application.
One
of
them
is
the
ops
team
that
is
responsible
for
curating
the
customer-facing
production
application.
We
have
a
front-end
team,
a
back-end
team.
We
have
a
data
based
team,
that's
responsible
for
all
of
the
data
transformations
and
anything
that
changes
as
we
upgrade
or
migrate
customers.
A
And
let's
say
that
this
environment
is
hosted
in
aws
or
this
application
is
hosted
in
aws.
So
it
isn't
on
kubernetes
or
it's
just
a
straight
deployment
to
an
aws
environment,
not
using
containers,
and
then
let's
say
that
we
have
a
separate
backend
team.
A
So
all
of
those
different
teams
are
working
in
their
own
repositories
and
they
are
making
changes
to
the
database
layer.
The
front
end
the
back
end
that
isn't
tied
together
until
it
gets
to
the
ops
team
and
the
ops
team
is
responsible
for
putting
together
all
of
these
changes
and
making
sure
that
they
get
compiled
and
sequenced
in
the
right
order,
so
that
when
they
make
their
deployment
on
the
end
of
the
month
to
their
production
application
hosted
in
aws,
the
experience
makes
sense.
A
An
electric
flow
allows
you
to
specify
all
these
different
containers
or
visualizations
of
this
front.
End
lives
in
this
repository
and
is
deploying
to
the
server,
and
this
back
end
is
deploying
to
this
server
and
the
database
lives.
Here
and
today
we
don't
have
that
sort
of
assignment.
It's
it's
just
it's
very
much
a
microservices
sort
of
tool,
we're
really
great
at
supporting
kubernetes
and
individual
microservices
and
projects
and
setting
up
those
sort
of
targets.
A
B
B
A
Yeah,
so
I
could
see
we
have
a
reporter
access
level.
That's
been
given
deployer
permissions
to
12
different
projects
across
five
different
groups
and
their
dashboard
would
be
all
the
con
all
the
environments
and
all
of
the
components
that
are
living
in
that
world
that
they
would
be
able
to
assign
to
these
various
objects.
B
Is
this
this
dashboard,
this
special
dashboard,
like
you,
see
a
drop
down
of
all
your
projects,
and
then
you
drag
them
all
to,
I
don't
know,
connect
them
somehow,
and
but
I'm
guessing
the
this
is
from
my
guess:
I'm
not
sure
the
api
how
it
is,
but
if,
if
you
have
access
as
a
person
or
with
to
all
these
projects,
you
should
be
able
to
just
call
the
api
and
pull
the
data
that
you
need
from
from
them
and
then
just
link
it
all
together.
B
A
I
don't
I
don't
really
know
if
we
can
group
artifacts
and
packages
across
projects
that
are
not
in
the
same
group,
so
that
would
be
like
a
tech
evaluation.
Can
we
look
at
environments
in
today's
state?
The
reason
why
we
are
creating
the
group
level
environment
view
is
to
at
least
help
people
see
into
all
the
things
that
are
related
in
their
group,
but
going
further
out.
A
There's
no
visibility,
and
I
don't
even
I
don't
even
know
if
you
I'm
sure
you
could
build
a
query
that
says,
get
id
from
this
project
get
id
from
this
project
but
say
that
you're
in
a
company
that
has
2
000
projects
and
you're
a
member
you're,
a
reporter
that
can
deploy
to
500
of
those
2000
projects,
even
even
with
the
api
like.
How
would
you
go
about
connecting
those
different
resources.
C
B
A
Recent
version
or
release
tag,
or
whatever
is
my
front
end
and
my
back
end,
and
you
know
it's
the
problem
of
being
able
to
visualize
all
these
related
components
in
gitlab
in
one
spot
is
today.
A
If
we
were
to
ask
this
e-commerce
application
show
us
your
production
app
in
gitlab,
they
would
have
to
walk
us
through
those
five
different
projects
from
their
five
different
teams
and
they'd.
Be
able
to
show
us
the
last
production
deployment
on
the
environments
dashboard,
but
they
wouldn't
be
able
to
show
us
the
source
code
or
the
release
tags
related
to
each
of
the
individual
repositories
in
a
single
place,
because
they're
across
different
projects
and
groups.
B
A
And
there's
there's
like
some.
I
originally
told
the
analyst
that
I'm
not
interested
in
this
and
we're
not
going
to
do
it,
but
but
we're
getting
some
feedback
from
enterprise
accounts
that
this.
This
is
actually
missing
for
them
that
they
have
such
distributed.
Legacy
teams
that
they're
not
ready
to
adopt
continuous
deployment
or
continuous
delivery
practices
in
a
way
where
they're
empowering
each
of
these
microservices
teams
to
orchestrate
independently.
A
But
they
really
want
this
governance
of
an
ops
team
shepherding
their
deployment,
and
that's
that
shepherding
process
is
super
manual
for
somebody,
because
you'd
have
to
add,
like
a
star
to
a
project
and
make
sure
you're
like
subscribe
to
notifications,
just
to
make
sure
that
you're
aware
and
sometimes
I
feel
like
a
little
bit
of
a
release,
manager
between
release,
cli,
get
lab
pages,
get
lab.org
and
the
handbook
and
keeping
up
to
date
on
all
of
those
changes
and
tracking
work
and
effort
across
those.
A
So
if
there's
a
way
to
like
merge
the
board
functionality
like
issue
board
functionality
with
this
visualization,
I
think
there's
like
maybe
using
labels
on
projects
or
something
it's
kind
of
like.
How
do
we?
How
do
we
aggregate
these
different,
disparate
information
pieces
so
that
it's
scoped
to
things
that
are
relevant
for
the
operations
team
or
the
release
manager.
B
It
sounds
to
me,
like
you,
require
some
sort
of
manual
process
to
say,
hey
put
this
project
and
you
know
initialize
this
dashboard
with
this
x
number
of
projects
and
then
once
you
have
access
to
that,
then
you
can
kind
of
help
visualize
them,
even
if
you
have
to
fetch
data
piece,
a
project
by
project,
but
you
need
this
sort
of
glue
to
start
these
things
together.
I
don't
know
it
sounds
to
me
like
that.
B
A
A
A
And
labels
might
not
be
right,
there
could
be
another
object
that
we
create,
but
that's
a
problem
that
people
are
telling
me
they
have
with
git
lab.
B
A
And
on
that
same
like
double-edged
sword,
we
are
using
them
so
heavily
other
users
are
using
so
heavily
because
it's
a
way
of
organizing
information,
so
it
might
might
be
a
natural
way
to
categorize,
but
it
could
also
be
there's
not
a
lot
of
locking
down
of
it
either.
So
anybody
can
change
it
and
wouldn't
that
be
awful.
If
your
ops
dashboard
tag
got
deleted
by
somebody
and
all
of
a
sudden,
you
can't
orchestrate
any
of
your
releases,
like
that
seems
very
high
risk.
A
What
are
you?
What
are
you
thinking
about
these
days?
What
are
you
all
interested
in?
Is
there
a
think,
big
that
you
feel
like
you
would
like
to
explore
from
a
release
management.
A
B
Yeah,
I
was
gonna
say
that,
like
with
the
pages
work
kind
of,
like
you
know,
my
head
is
just
there.
I
did
see
sean's
proposal
to
building
like
a
page,
a
releases
page
that
is
hosted
on
pages
per
project.
There
was
some
interesting
conversations
going
on
there.
A
So
I'm
sort
of
torn
on
this
feature
because
I'm
driving
traffic
to
the
in
product
releases
page
this
would
divert
people
away
from
it.
So
I'm
a
little
quiet
on
that
issue,
because
it
would
directly
negatively
impact
my
gmail,
which
is
what
I'm
incentivized
to
drive
as
a
product
manager,
gmail
being
group
monthly,
active
users.
A
So
if
we
implement
this
feature,
we
would
definitely
want
to
instrument
a
user
tracking
so
that
we
can
watch
how
many
users
are
being
diverted
from
the
in
product
releases
page.
But
I
love
the
idea
of
like
dynamically,
generating
a
releases
notes
page
on
a
static
site,
that's
kind
of
weird
automatically,
generating
a
release
page
from
your
pipeline
on
aesthetic
site
that
that
could
be
really
cool.
What
are
your
thoughts.
A
C
A
That's
my
thought
too.
Initially,
I
just
dropped
it
in
the
agenda
and
I
can
I
can
share
my
screen
and
kind
of
talk
through
the
proposal.
A
A
It
would
be
really
cool
if
we
could
have
pages,
be
the
engine
behind
the
releases
page
and
not
impact
the
flow
that
we
currently
have
working.
You
know
like
how
tags
are
populated
onto
the
releases
page,
because
I
think
that
that's
my
part,
my
my
fear
is
that
we
disconnect
that
refracture
that
and
then
we
we
break
a
bunch
of
other
things
on
our
customers.
Configuration
right.
B
Yeah,
it
makes
sense.
Your
concerns
make
a
lot
of
sense
and
I
think
the
idea
of
if
I,
if
I
get
what
sean
is
trying
to
to
say,
is
the
the
releases
notes
from
fedora.
For
example,
they're
very,
like
you
know,
very
well
structured.
You
have
a
lot
of
links.
You
can
just
click
on
things
and
see
what's
happening
and
but
yeah
I
can
see
how
this
is
a
separate,
completely
separate
page,
and
then
you
wouldn't
have
all
the
tracking
that
you
have
right
now.
A
I
would
love
it
if
we
could
embed
pages
on
the
releases
page
and
have
it
pull
in
with
all
of
the
tags,
functionality
that
we
have
and,
of
course
like
there
might
be
a
world
where
we
deprecate
the
release
versus
tags
relationship
and
that
becomes
less
important.
We
just
have
to
hydrate
the
releases
tag,
information
onto
the
releases
page
wherever
that
may
live.
B
A
B
A
Run
books
are
still
going
to
be
a
friction
point
for
customers
who
are
using
zba
labs
and
really
they're
like
deployment
plans.
So
we
have
some
mocks
out
there
that
we're
working
on,
but
some
of
the
more
nuanced
features
are
like
allowing
people
to
trigger
scripts
and
commands
from
the
run
books
so
like
clicking
a
play
button
and
having
that
script
run
on
their
behalf.
B
C
C
So
if
we
have
an
option
for
pages
to
support
multiple
versions
of
the
same
site
or
something
like
this
like
in
in
your
in
your
pipeline,
you
can
generate
whatever
you
want,
put
it
on
pages
and
then
knowing
the
link
to
to
that
static
site,
just
use
it
in
your
in
the
release,
api
or
the
release
or
diy.
In
the
description
there
to
to
point
people
that
that
will
kind
of
solve
this
problem
right.
B
Yeah,
it
was
one
of
vlad's
comment
like
once.
We
have
this
zip
work
done.
It's
probably
gonna
be
much
easier
and
the
new
deployments
that
we
will
have
on
the
rail
side.
It's
probably
going
to
be
it's.
C
Similar,
like
the
use
case,
that
was
like
the
same
feature,
was
requested
before
from
the
docks
team,
because
now
every
time
they
generate
dogs,
they
have
to
generate
dogs
for
all
the
old
versions,
and
they
have
some
hacks
and
workarounds
and
doing
this
in
containers.
So
they
eventually
they
have
all
all
the
files
together
and
can
they
push
them
two
pages
and
they
do
this
for
every
version,
even
if
the
the
only
the
last
one
is
changed.
C
C
C
Like
if
we
have
our,
if
we
have
it
done
our
way,
it
will
be
like
one
way
for
all,
and
then
probably
people
will
be
complaining
that
it's
not
treating
you
so
sometimes
I
think
it's
better
to
leave
the
this
season
to
the
user.
So
even
if
it's
more
work
for
them
at
least
they
they
have
the
flexibility
to
do
whatever
they
want.
C
C
C
Saying
is
basically,
what's
common,
that,
ideally,
we
need
to
be
able
to
deploy
multiple
sites
from
the
same
project
and
then
we
can
use
them
for
anything,
including
releases
or
dogs,
or
whatever
people
want.
So
that
feature
will
solve
many
other
use
cases,
unlike
what's
the
proposal
here,
which
is
very
specific
and
coupled
to
releases.
B
A
I
love
it.
I
love
it.
I'm
really
looking
forward
to
the
object,
storage
work
to
being
completed
so
that
we
can
start
investing
in
like
better
redirects
wild
card
dns,
some
of
the
other.
I'm
all
I'm
on
calls
with
these
enterprise
customers
who
are
using
pages
and
those
are
like
the
top
two
features
that
get
brought
up
every
single
time.
So
there'd
be
a
way
to
to
monetize
that
kind
of
feature
set
that
would
be
really
attractive
for
for
us
as
a
product.