►
From YouTube: Release Management: Environments Dashboard Sync #3
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
I've
been
interviewing
customers
on
some
of
the
environments.
Dashboard
work
that
I've
created
from
like
a
future
facing
scope
and
people
are
very
excited
to
be
able
to
add
more
environments
and
projects.
The
dashboard
like
I
seriously,
had
somebody
they
were
in
their
co-working
space
and
they
leaned
over
to
another
person
and
they
said
they're
going
to
add
more
tiles
to
it.
So
they're
very
pumped
about
that.
That's
really
exciting,
but
I
did
also
learn
from
other
users
that
the
jobs
to
be
done,
they're
looking
to
accomplish
when
they
go
to
the
environments.
A
Dashboard
page
are
not
not
executable
and
there
actually
isn't
a
place
in
gitlab
that
they
can
easily
do
this.
So
here's
a
really
great
workflow.
I
have
12
projects
that
are
all
contributing
to
the
same
release
pipeline.
So
it's
like
a
really
heavily
micro-serviced
application,
and
each
of
these
are
sharing
the
same
target
environment
in
aws.
A
If
they
were
to
do
this
in
gitlab
today,
they
would
have
12
separate
production
tiles
on
the
dashboard,
and
we
have
a
couple
of
issues
that
are
going
to
be
about
feeding
into
the
same
project.
But
I
wanted
to
share
this
with
you
all,
because
I
was
actually
able
to
see
like
a
user
go
into.
I
was
unable
to
record
the
actual
meeting,
but
I
saw
a
user
go
into
the
aws
console
and
check
about.
A
So
I
think
that's
where
adding
the
heat
map
will
be
really
helpful
for
them,
because
they'll
just
be
able
to
see
at
a
glance
like
the
environments
available,
but
I
did
add
additional
features
about
annotations
of
the
environments
dashboard.
So
what
I
wanted
to
use
this
meeting
for
today
is
to
get
a
brief
update,
jake
from
you
on.
If
there's
any
questions
you
have
about
the
existing
scope
that
you're
working
on
and
for
hyon,
and
I
to
help
you
on
that.
A
If
you
need
it,
and
then
we
can
kind
of
talk
about
a
new
epic
that
I
created
and
discuss
more
of
a
redesign
effort
and
hopefully
have
hayana
and
you
partner
together
on
creating
some
prototypes
for
what
a
new
environments
dashboard
could
look
like
sound
good.
B
Well,
it's
that's
gonna,
be
short
on
my
end,
I
actually
don't
really
have
any
current
questions.
So
if
we
want
to
just
go
right
into
the
epic
and
then
maybe
if
anything
comes
along
I'll,
take
no-
and
we
can
address
that
later
on.
A
Perfect,
I
think
the
only
thing
that
we
have
currently
scheduled
is
this
idea
of
expanding
the
number
of
projects
that
you
can
add
to
the
dashboard.
So.
B
Yeah
and
that's
going
ahead-
that's
that's
kind
of
going
in
with
the
pagination
work
because
for
pagination
we
want
to.
We
want
to
increase
the
number
of
projects
to
20
on
the
dashboard,
so
that's
currently
ongoing,
but
pretty
straightforward
at
the
moment.
So
no
questions
on
that.
A
That's
what
I
like
to
hear.
I
always
want
the
ux
definition
of
done
to
be
so
explicit
that
you're,
just
like
I
can
just
do
my
job.
That
makes
me
happy
so
this
new
epic
that
I
created,
I
think,
probably
last
week,
was
taking
a
different
direction
from
our
other
epics
that
we
have
on
the
environments
dashboard.
The
other
epics
are
more
about
organizing
our
backlog
for
the
dashboard
and
kind
of
thinking
about
all
the
bugs
and
problems
and
features
that
people
have
requested.
A
This
is
more
about
new
features
that
I
have
received
from
customers
about
the
jobs
to
be
done,
that
they're
looking
for
so
in
this
epic.
I
have
like
a
purpose
that
just
gives
a
high
level
overview
of
the
gaps
that
the
environments
dashboard
has
today
and
then
a
goal
statement
and
to
spend
a
little
bit
on
the
goal.
Users
are
looking
at
production
environments,
which
forum
and
ops
perception
like
the
ops
personas
in
gitlab
typically
are
also
looking
at
production
environment.
A
But
here
the
biggest
difference
is
from
a
cicd
view
versus
like
an
operations.
Team
view
is
that
they
want
to
coordinate
and
triage
problems
across
multiple
projects
and
teams
versus
just
a
single
deployment
event,
so
that
action
of
wanting
to
see
like
a
portfolio
view
is
distinctly
different,
with
a
release
manager
than
like
an
ops
persona.
A
A
You
know
any
number
of
environments
at
all
times,
so
they
can
always
see.
What's
the
status
of
that
particular
production
environment
at
the
top
of
the
dashboard.
So
what's
interesting
about
this
interaction
is
that
there
would
be
a
pre-populated
view,
then
you
know
from
from
their
perspective,
like
the
operations.
Dashboard
would
always
have
like
that
particular
environment
at
the
top,
and
not
just
the
added
projects,
environments.
B
I
think
from
a
ux
perspective,
it's
a
it's
a
good
call
out
from
a
technical
perspective.
I
I
see
feasibility
in
there
so
right
now,
the
way
we
get
environments
onto
the
dashboard
is
by.
We
basically
just
generate
one
one
single
listing
of
environments
and
send
that
over
an
internal
api
to
the
dashboard
page.
B
So
to
build
this
out,
we
would
need
to
create
essentially
two
environments
listings,
one
for
pin
environments
that
doesn't
con,
that
is
independent
of
the
non-pinned
environments.
C
B
A
Another
feature
that
I
saw
come
up
time
and
time
again
after
I
started
like
evaluating
how
release
managers
particularly
or
development
team,
leads
like
the
contact
that
you
sent
over
jake.
He
is
definitely
like
the
persona
we're
building
these
features
for
and
watching
his
interactions
with
the
environments.
Dashboard
was
a
really
cool,
was
a
really
cool
thing,
because
he
came
back
and
said
well,
it'd,
be
really
great
to
see
like
failed
jobs
of
my
protected
environments,
already
bubbled
up
to
the
top
of
the
environment's
dashboard.
A
So
it's
more
like
a
gitlab
does
the
surfacing
for
you,
so
the
expectation
would
be
I
go
in
in
the
morning,
and
I
go
to
my
environment's
dashboard
as
a
release
manager-
and
I
have
maybe
my
pinned
environments
at
the
top
and
they're
color
coded
like
they
are
today
and
then
the
the
bar
below
that
the
the
window
below
that
or
the
swim
lane
below.
That
would
be
a
list
of
failed
environments
or
failed
jobs
on
an
environment,
so
I
can
triage
them
appropriately.
A
This
is
a
little
bit
trickier
for
me
to
like
think
about
how
we
want
how
we're
going
to
instrument
that,
because
any
time
that
I've
surfaced
problems
inside
of
an
application,
it
ends
up
being
like
a
performance
drain
on
the
system,
because
it's
constantly
like
pinging
and
looking
for
failed
events
and
like
pulling
them
in.
So
that
might
be
something
that
we'll
need
to
think
about.
But
the
intent
here
is
to
how
do
we
allow
them
to
triage
failed
production
issues
from
the
environments
dashboard?
B
B
I
think
it's
just
a
really.
I
think
it's
just
really
a
cool
idea
to
make
the
dashboard
smarter
so
that
when
you
go
to
the
dashboard
you're
already
seeing
the
things
that
you're
looking
for
and
you're,
not
digging
around
so
from
from
just
that
perspective
of
making
the
dashboard
smarter.
I
really
like
this
issue,
but
yeah
in
terms
of
the
technical
feasibility
of
it.
B
I
can
see
we're
constantly
having
to
check
every
job
of
every
project
constantly
and
then
update,
create
like
some
updated
data
so
that
when
you
load
the
dashboard
it's
there,
I
can
see
that
being
something
that
we
have
to
consider
from
a
from
a
performance
perspective
and
well.
I
wonder
because
I
know
we
have
like
this.
B
A
Yeah
that's
helpful.
We
recently
had
emerged
the
product
handbook,
mr,
that
product
managers
are
responsible
for
their
performance
of
their
pages
on.com,
and
this
is
a
really
interesting
like
concept,
because
I
don't
think
I
really
have
tools
to
see
how
my
features
are
impacting
performance
today.
A
So
this
is
one
of
the
issues
that
we'll
want
to
create
a
poc
for
and
test
and
kind
of
think
about.
How
is
the
data
being
retrieved,
and
maybe
a
part
of
this
is
that
we
only
surface
like
it's
a
really
small
subset
of
data
like
you
have
to
select
only
five
environments
that
you
want
to
watch
this
for
or
you
know
we
can
create
caps
like
that
too,
to
contain
performance.
But
I
also
think
it
is
important
to
think
about
the
tier
being
an
opportunity
to
contain
some
of
that
as
well.
A
Okay,
so
then,
another
issue
that
I
thought
about
that
wasn't
directly
ever
stated
by
a
customer,
but
it
was
something
that
I'm
pretty
familiar
with
inside
of
analytics
in
general
and
it's
this
idea
of
providing
a
pre-selected
curated
layout
for
the
environment's
dashboard
and
I'm
calling
them
environments,
dashboard
templates.
A
It's
like
it's
like
a
pre-populated,
just
view
that
people
can
select
from
and
maybe
having
three
of
those
template
views
that
people
can
toggle
between,
like
maybe
one's
production,
maybe
one
is
just
past
production,
so
it's
the
swim
lane
view
of
your
top
10
projects
going
through
dev
qa.
You
know
going
through
various
stages
that
you
get
to
specify.
A
This
is
a
common
expectation
from
other
tools,
like
the
visualization
of
weird
deployments
through
their
life
cycle
are
really
easy
to
see
in
xevia
labs
really
easy
to
see
in
an
electric
flow
electric
cloud
flow.
What
are
your?
What
are
your
thoughts
on
this
idea?
It
is
a
little
bit
like
half
fake,
so
don't
worry
about
being
like
jackie.
This
is
ridiculous
and
I
can
add
more
context
or
more
thoughts
on
it.
B
B
B
If
you
haven't
looked
at
any
documentation
or
anything
so
maybe
pre-populating
pre-populating
a
dashboard
or
having
a
template
to
to
pre-populate
the
dashboard
is
a
good
idea
and
yeah.
I
was
actually
just
thinking
like
what,
if
we
just
like,
showed
like
a
screenshot
of
of
like
a
populated
dashboard
as
like
an
mvc
at
first
and
see
if
that
changes
anything.
But
I
also
don't
think
that
showing
like
a
picture
is
that
great
of
an
experience
either
so
yeah.
I.
A
A
C
A
B
To
that,
starting
with
starting
with
an
image
and
linking
off
to
a
video
and
then
after
that,
iteration
going
into
making
pre-populated
templates.
D
We
had
a
proposal
from,
I
don't
remember
which
stage
group,
but
it
was
kevin
the
designer
where
he
had
the
design
proposal
for
with
the
empty
state
with
an
image,
because
right
now
we
do
have
like
this
illustration,
but
it
was
something
I
don't
think
it
got
implemented,
but
I
can
look
into
it.
D
There
is
already
some
investigation
and
another
thing
is
that
when
we,
when
we
talk
about
like
pre-selecting
things
for
the
dashboard
and
hearing
what
you're
saying,
I
found
very
odd
that
right
now
we
add
projects
to
the
environment,
and
while
I
was
prototyping
today,
the
grouping
of
group
environments
so
aggregating
everything
at
the
group
level.
I
think
it
makes
sense
and
correct
me
if
I'm
wrong
to
instead
of
adding
project
you
will
select,
which
environments
you
want
to
show
there.
D
The
production
is
it,
you
know,
review
whatever,
and
then
you
show
which
projects
have
those
shared
environments
rather
than
adding
groups,
because
that's
part
of
my
my
current
struggle
with
the
design
is
that
I
cannot
organize
things
at
the
project
level
on
you
know
a
higher
level
view
and
also
showing
how
these
environments
are
shared
across
different
groups.
So
it's
a
bit
of
a.
A
Statement
but
I
love
that
you
said
that
so
maybe
like
the
abstraction
here
is
that
we
allow
people
to
add
it
to
a
stage
in
their
pipeline.
So
maybe,
like
one
of
the
views,
is
a
swim
lane
view
where
it
has
like
dev
qa,
staging
development
or
production,
and
they
can
drag
particular
environment
tiles
into
each
one
of
those
swim
lanes.
And
that
would
be
a
really
great
view
from
a
deployment
plan
perspective
and
it
would
allow
people
to
see
like
their
environments
as
they
progress
through
those
views.
A
D
It
would
be
similar
to
what
we
briefly
discussed
that
proposal
fundamentally
of
changing
the
view
to
be
more
aligned
with
what
we
have
for
the
the
issues
board,
it's
difficult
to
talk
about
it.
Well,
I
think
we
need
some
visualization
for
for
that,
so
we
can.
You
can
see
how
this.
A
I
like
that
okay
good
thoughts
there,
the
other
kinds
of
things
that
I
heard
from
customers,
were
around
wanting
to
tie
back
to
performance
metrics
from
the
environments
dashboard,
so
adding
like
maybe
single
metric
tiles
to
the
environments,
dashboard.
C
A
Like
deployment
frequency
that
cross
links
into
cycle
time
analytics
and
gitlab,
so
you
can't
do
anything
with
the
data
there.
But
if
you
click
on
that
metric
and
pull
you
into
the
dashboard
analytics
view
inside
of
git
lab,
I
also
heard
dora
metrics
wanting
to
see
how
people
are
performing
on
dora
on
the
environments
dashboard,
because,
again
the
jobs
to
be
done
for
release
manager
is
to
see
how
are
we
deploying
to
production?
How
can
we
deploy
faster
or
problems
and
bottlenecks
that
I
need
to
resolve?
So
that's
what
this
issue
is
focused
on.
A
And
the
last
thing
I
added
to
this
epic
was
this
idea
of
creating
a
global
view
for
their
instance.
So
there
are
some
questions
about
using
the
environment's
dashboard
as
a
display
point
for
people
to
like
digital
signage,
so
they
would
want
to
display
the
environment's
dashboard
on
a
tv
screen
in
their
sre
teams.
A
You
know
space
and
today
you
really
can't
you
can't
populate
a
global
view,
so
some
customers
want
to
add
a
configuration
option
to
say
I
want
the
environment's
dashboard
to
only
have
this
view
for
every
user.
A
A
I
intend
to
present
the
non-kubernetes
deployments
opportunity
canvas,
probably
middle
of
next
month,
I'm
looking
for
one
more
customer
validation
of
a
team
lead
persona
in
a
small
business.
You
know
like
a
smb
customer
rather
than
an
enterprise
customer
just
so
that
I
have
like
the
right
we're.
We
have
the
right
personas
that
we're
addressing,
but
any
thoughts
or
questions
on.
B
A
Oh
sorry,
okay.
B
I
will
just
oh
okay,
I
am
back
in
my
own
world
here,
okay,
yeah.
What
a
sorry
would
you
be
willing
to
repeat
what
you
said
about
presenting
for
the
small
businesses.
A
A
You
know
a
small
media
site
business,
so
that's
just
resourcing
the
right
interview
and
once
we
get
that
we'll
be
able
to
move
through
solution,
validation
and
start
like
weighing
these
items
and
put
them
in
design,
because
what
I
don't
want
to
do
is
take
these
these
issues
and
prematurely
scope
them
from
a
design
perspective
if
it
doesn't
necessarily
meet
the
breadth
of
customers.
We're
expecting.
I.
A
I
would
love
that
right
now.
What
I'm
doing
is
just
kind
of
showing
my
environments,
dashboard
and
then
talking
through
like
oh,
this
would
have
a
a
pin
up
top
that
allows
you
to
drag
and
drop
ten
different
tiles,
filling
up
the
top
two
rows
of
the
screen:
yeah
imagination.
D
I'm
gonna
add
a
note
here
for
myself,
so
we
can
schedule
some
time
to
do
so.
I
can
do
some
ideation.
You
can
use
for
your
your
nice
interviews.
A
It
against
everything
else,
yeah,
yeah,
and
and
that's
where
like
why
this
isn't
in
design.
Yet
I
just
wanted
to
use
this
opportunity
to
to
inform
you
all
about
what
I'm
hearing,
because
we
do
have
a
lot
of
like
bugs
in
our
current
epics
for
the
environments
dashboard,
but
part
of
me
is
thinking
like
well.
Customers
aren't
even
using
it,
but
they're
reporting
these
bugs,
and
maybe
it
really
just
needs
like
a
whole
new
like
refactoring.
The
purpose.
A
D
I
wonder
if
I
think
we
mentioned
this
a
couple
of
months
back
if
this
view
would
in
a
way
work
the
same
way
as
what
we're
thinking
for
the
the
environments
at
the
group
level.
Or
do
you
think
it's
really
like
at
the
instance
where
you
know
it's
a
very
different
persona,
because
I'm
seeing
the
environments
at
the
group
level
as
a
list
view
of
most
of
you
know
this.
D
This
capabilities
like
seeing
your
last
deployment,
seeing
I
don't
know
what
was
the,
what
everything
that
is
happening
for
the
production
deployments
on
all
your
projects
in
the
same
group.
So
it's
kind
of
very
funny
here
on
how
these
two
capabilities
could
overlap.
A
A
super
good
call
out
group
environments
will
allow
us
to
remove
tiles
on
the
existing
environments
dashboard
right,
because
today,
each
project
gets
added
and
in
their
corresponding
environments,
gets
added.
If
we
shift
the
paradigm
of
the
environment's
dashboard
to
be
your
adding
environments,
individual
environments
rather
than
projects,
you
would
be
able
to
visualize
your
application
deployments
by
leveraging
the
sharing
of
production
environments
across
the
group.
A
So
that's
how
in
my
head,
I
see
them
overlapping
and
maybe
maybe
we
find
different
cueing
like
different
visual
cueing
for
a
shared
environment
like
maybe
it
has
like
a
little
linking
icon
or
has
some
sort
of
indicator
on
the
tile
that
this
is
something
that's
shared
across
multiple
projects
or
maybe
they're
in
their
own
little
swimlane
or
they
have
their
own
little
like
we
have
swim
lanes,
then
we
have
rows.
A
Maybe
the
there's
a
row
for
shared
environments
and
then
individual
project
environments
and
each
of
the
swim
lanes
are
the
stages
of
the
deployment
like.
We
can
think
through
that
that
layout,
but
in
my
head
they
overlap
because
we
reduce
the
amount
of
tiles
that
are
shown
on
the
environment's
dashboard.
We're
making
it
easier
for
users
to
see
their
application
deployment
does
that.
D
A
A
You
know
like
how
you
have
like
labels
and
labels
of
the
project
are
indicated
project
label,
but
I
don't
know
like
the
breadcrumbing
of
that
because,
like
if
I
was
to
click
project
labels,
if
labels
are
always
stored
at
the
group
and
then
they
indicate
project
level.
A
Maybe
this
is
a
case
where
we
also
have
environments
at
the
group
in
the
side
panel
and
that's
where
we
have
people
manage
environments
from
here
on
out
and
we
remove
the
index
page
at
the
project
level,
but
that's
kind
of
strange
if
it's
just
an
environment
in
the
project.
So
we
will
need
to
think
through
that
interaction
of
the
environment's
index
page.
D
Yeah,
I
have
a
couple
of
questions:
that's
in
the
from
the
prototyping
phase
that
when
I
look
at
the
environment,
project
environments
and
the
index,
and
then
you
go
to
the
detail
view
and
you
even
see
some
different
information
there.
It's
a
bit
tricky
to
kind
of
make
this
association
when
you're
only
seeing
one
item-
and
this
is-
I
don't
know
my
latest
deployment
or
my
latest
best
pipeline
for
production
whatever
so
it's
let's
see,
I
have
more.
A
Totally
not
totally
not
expecting
you
to.
I
did
see
your
updated
link
to
the
sharing
of
production
environments
across
the
group,
so
I
think
that
that
will
be
a
great,
a
great
thing
for
us
to
scope
and
think
about.
A
B
I
I
love
this
conversation
and
there's
prototypes
that
I
don't
want
to
share,
I'm
all
for
staying
and
checking
them
out.
D
D
I'm
sending
you
also
the
oh,
my
goodness
zoom.
Why
do
you
do
this
to
me?
I
just
want
to
share.
I
want
to
share
the
link
with
you
here,
so
you
can
also
leave
your
comments
because
I
actually
left
a
bunch
of
questions
in
this
file
anyway.
So
this
is
my
current
prototype
for
environments
at
the
group
level.
D
So
I
added
here
an
option
for
operations
on
the
sidebar,
so,
ideally,
or
at
least
in
my
head,
we
keep
the
same
consistency
with
the
navigation,
so
we
add
operation
and
then
you
go
operation
environments,
but
for
the
group,
if
you
don't
have
anything
for
some
reason,
you
see
an
empty
state
right
now,
even
on
project
environments,
we
don't
have
an
illustration
for
empty
state,
so
I
think
we
have.
We
can
be
creative
here
and
also
think
about
the
copy
for
this
text.
D
For
this
section
and
then
this
is
where
I
am
right
now,
when
I
look
at
how
the
shared
environments
will
work
in
the
issue
description,
we
say
that
we're
gonna,
we're
gonna,
consider
an
environment
shared
when
they
have
the
same
name
in
being
used
in
different
projects.
D
So
everything
that
is
production
on
in
this
example,
gitlab
or
pajamas,
will
show
here
or
review
and
then
in
this
view
I
just
I
pretty
much
just
added-
don't
look
at
it.
It's
still
low
fidelity,
don't
judge
me
so
pretty
much
the
same
information
from
the
project
level.
So
this
is
your
last
deployment
or
your
last
pass
pipeline
for
review
on
gitlab
and
same
for
pajamas.
D
A
Icon,
which
you,
I
think
the
only
thing
here
is
I'd
like
to
indicate
somewhere,
that
these
are
like
projects
like
under
the
review
having
some
sort
of
header
or
indicator
that,
like
these,
are
your
projects
that
you're
looking
at,
because
today
like
that
could
be.
That
could
look
like
a
subgroup
to
me.
You
know
like
looking
at
that
icon
and.
A
D
Yeah
and
then
this
is
like
super
low
fidelity,
because
I
was
playing
around
with
it,
and
it
took
me
so
long
to
put
this
together,
because
I
don't
have
all
the
components
on
figma,
but
I
have
some
questions
here.
For
example,
in
the
in
the
project
level,
we
have
some
sort
of
a
table
and
then
you
have
multiple
headers
right.
So
you
have
a
header
here.
That
says
this
is
the
job
or
this
is
the
pipeline.
D
This
is
when
it
expires,
and
I
did
not
hear
because
I
was
just
too
lazy,
but
I
was
wondering
if
this
exact
information
is
relevant
to
users
at
this
level
if
they
want
to
see
the
exact
same
info
in
the
ui
here
that
they
see
at
the
project
level,
and
it
would
be
interesting
to
show
like
the
pipeline.
This
is
fast
or
not,
because
there's
different
views
from
the
project
overview
environment,
graphical
review
and
environments,
detail
view
also
saying
different
action.
Buttons.
A
I
wonder
if
there's
a
way
to
simplify
this
here
and
not
have
so
much
information
like
maybe
we
can
just
add,
like
here's,
my
here's,
what
I
would
like
this
view
to
be
really
clean
and
that
we
give
people
the
opportunity
to
link
off
to
their
project
view,
but
I
I
also
think
that,
if
we're
allowing
people
to
create
new
environments
here
and
say,
I
want
to
share
this
environment
and
these
other
projects,
the
detailed
view
might
actually
be
warranted.
A
What
what
they're
actually
able
to
to
to
do
here,
like
would,
would
they
actually
be
able
to
stop
each
of
the
production
deployments
from
each
and
individual
projects?
At
this
view-
and
maybe
this
is
where,
like
you,
we
have
a
collapse
here
and
maybe
it
just
maybe.
This
is
just
like
a
grouping
mechanism.
A
The
intent,
though,
is
for
them
to
actually
share
these
environments
like
I
want
them
to
be
able
to
actually
say:
yes,
stop
all
deployments
to
this
environment
from
this
view,
but
I'm
worried
about
having
only
one
actioning
icon
when
really
there's
like
separate
projects
contributing
to
the
same
url
like
each
of
those
projects
are
going
to
have
their
own
pipelines,
and
this
is
just
the
mechanism
that
we're
like
visually,
indicating
that
these
are
related
inside
of
gitlab
like
we're,
not
aggregating
pipelines
from
all
the
projects
into
a
single
environment.
A
C
C
Right
quickly
how
it
works
here,
because
I
think
just
see
if
I
also
understand
oops,
not
this
actually.
D
I
want
operation
environments
because
in
a
way
what
we
will
be
showing
at
the
prototype,
the
group
level-
it's
really
like
just
the
latest
one
in
review.
C
D
Right,
so
what
you're
saying
is
that
these
this
here
would
apply
like
to
all
the
review
on
gitlab.
Not
only
this.
B
B
Is
this
the
view
where
we
want
to
be
able
to
stop
an
entire
environment,
or
do
we
want
to
be
able
to
just
add
some
more
friction
to
prevent
someone
from
mistakingly
stopping
all
deployments
or
stopping
all
pipelines
to
an
environment.
A
That's
a
good
question,
so
my
initial
thoughts
of
having
group
environments
was
allowing
people
to
aggregate
for
their
application
right
so
like
this
review
app,
and
maybe
it's
only
production
environment
sayana.
Maybe
that's
why,
like
I'm
getting
so
stuck
on
the
review
pieces,
because
review
apps
are
very,
very
kubernetes,
very
dynamic
environments.
A
Perspective
like
review
apps
particularly
are
are
dynamic
environments,
so
you'll
have
hundreds
of
thousands
of
those
environments
created
and
stopped
at
any
given
time.
So
I
think
that
this
could
be
like
part
of
why
I'm
getting
so
stuck
on
that.
But
let's
say
that
we're
only
looking
at
production
environments
for
each
of
these
projects
and
you
have
a
group
production
environment
and
under
that
group
production
environment
you
have
five
projects
that
contribute
to
that
application
experience.
A
So
in
this
view
this
doesn't
tell
me
that
gitlab
and
pajamas
are
contributing
to
my
application
environment.
C
So
you
will
have
so
this
would
be
like
the
tree
or
whatever
I'm
just
gonna
freestyle
here
like
here
and
then
you're
gonna
have
your
main
production,
like
your
umbrella.
A
A
C
C
I
think
we
care
about
deploy
boards.
A
B
If
we're
showing
like
a
top
level
environment
here,
would
it
be?
B
C
C
B
Would
even
maybe
get
rid
of
that
that
branch
name
yeah
so
doing
something
like
that.
C
A
Today,
in
gitlab,
customers
can
put
the
same
url
in
each
of
their
individual
projects.
It
just
shows
up
as
a
different
as
a
different
environment.
So
that's
what
we're
trying
to
solve
for
is
that
you
have
the
same
url
like
the
same
actual
physical
environment,
that
you're
deploying
to
and
visually
being
able
to
indicate
that
in
gitlab.
Does
that
make
sense-
and
I
think,
like
this,
gives
you
that
picture.