►
From YouTube: Design Pair Session - 09-03-2023
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
Hey
everyone:
this
is
the
design
pair
session
on
March
9th
and
the
topic
today
that
I
have
is
going
over
our
group
level
environments
proposal
before
I
jump
into
the
solution,
validation
for
it
next
month
or
next
Milestone.
As
like
a
kind
of
a
preamble
to
this
I
know
a
lot
of
people
on
the
release.
Team
have
already
reviewed
this
design,
I'm,
not
sure
if
everyone's
seen
the
most
recent
one
that
has
come
out.
Oh
hey,
Timo,.
A
Hello,
yeah
I'm,
not
sure
if
everyone
has
seen
the
most
recent
group
level,
environments
design,
but
I
wanted
to
use
this
meeting
as
kind
of
an
overview
of
what's
been
done
so
far.
How
we
got
there
and
kind
of
what
I'm
looking
for
in
the
solution,
validation
as
well
to
get
some
fresh
eyes
on
the
concept.
If
anyone
has
any
like
questions
or
feedback
before
I
kind
of
share
out
the
concepts
with
some
of
our
users
and
then
if
we
do
want
I've
dedicated
the
last
20
minutes.
If
there's
any
oh.
A
Sorry
Anna
just
needed
admittance
to
this
meeting
so.
A
A
Cool,
so
just
to
give
a
quick
overview.
We're
gonna
send
some
of
this
meeting
going
over
the
group
level,
environments,
design
that
I
had
proposed
and
that's
going
into
solution,
validation
and
then
I've
put
aside
sometime
at
the
end
for
anyone
who
might
have
questions
about
ongoing
issues
for
design
or
just
needs
kind
of
my
feedback
on
something.
So
I'll
put
the
last
20
minutes
of
this
meeting
kind
of
towards
that.
A
If
we
have
things
that
come
up
cool,
but
the
basic
thing
is
for
those
who
don't
know
the
group
level
environments
project
itself
has
come
out
of
the
fact
that
you
can
see
all
your
environments
at
the
project
level
by
viewing
the
environments
page.
But
if
you
have
multiple
projects
within
a
group,
we
don't
really
give
you
an
option
other
than
the
environments
dashboard.
To
really
see
your
environments
within
that
group
and
the
environments.
Dashboard
itself
has
a
bunch
of
visibility
problems.
A
It
can't
really
be
shared
some
environments,
just
don't
give
you
right,
information
on
it
or
the
information.
It
doesn't
load
properly,
there's
a
bunch
of
usability
issues
with
it.
So
this
this
issue
is
really
about
showing
production
environments
at
the
group
level,
giving
people
a
good
overview
of
what
is
happening
to
their
production
environments
without
having
to
dig
into
every
project.
So
does
anyone
have
any
questions
before
I
continue.
B
The
more
specific
I'd
say
you
told
us
one
user
problem
here,
that
is
that,
like
the
users
won't
have
to
need
to
open
specific
projects
to
to
get
some
overview
of
the
environment.
Do
you
have
more
specific
user
problems
that
you
can
share
with
us.
A
Yeah,
so
some
of
the
other,
so
the
main
user
problem
we're
trying
to
solve
for
here
is
we
want
an
area
that
kind
of
like
I,
guess,
team
leads
or
kind
of
people
at
that
level
can
go
and
just
view
all
their
production
environments
see
the
status,
see
if
there's
anything
wrong,
and
then
you
can
kind
of
dig
in
we're
also
having
an
area
to
show
metrics
across,
because
there
has
been
some
ask
to
understand
kind
of
like
the
metrics
going
on
at
this
level.
A
So
that's
why
in
The
Proposal
we
do
have
the
Dora
metrics
at
the
top
to
kind
of
give
an
overview
of
that
and
then
as
well.
There
is
the
user
problem
where
the
group
level
environments
dashboard
is
not
shared
across
users,
so
you
can
set
it
up
for
your
own
account,
but
this
is
solving
the
team
need
to
have
kind
of,
like
that
view
at
a
higher
level
that
not
everyone
on
the
team
has
to
set
up
their
own
dashboard.
So
those
are
kind
of
the
three
main
kind
of
user
needs.
B
A
I
know
Andre
raised
his
hand
as
well.
C
Yeah,
just
to
add
a
little
bit
of
perspective
here
is
basically
if,
for
example,
a
team
is
working
in
the
distributed
Services
application,
then
gitlab
actually
has
very
limited
capabilities
to
support
this
kind
of
setup.
One
of
the
use
cases
is
basically
okay.
C
You
want
to
see
what
is
deployed
to
your
production
environment,
from
different
projects
that
you
have
or
if
something
is
wrong,
just
like
Emily
said,
and
there
is
no
simple
way
to
do
it,
so
people
have
to
rely
on
third-party
tools,
so
it
would
be
great
if
we
could
actually
provide
something
like
another
video
for
this
case.
A
Yeah
and
to
add
one
more
thing:
we
had
this
as
a
attack
during
the
CMS,
the
category
maturity
scorecard
for
environment
management
and
it's
scored
pretty
low
on
monitoring
environments
across
a
group,
because
I
think
the
two
main
ways
people
did
this
is
they
either
tried
to
set
up
the
environment
dashboard
and
that
wasn't
successful
at
all
in
every
scenario
or
they
went
in
manually,
checked
every
single
project
within
the
group
which
also
took
forever.
They
were
able
to
get
the
task
done,
but
it
wasn't
a
very
great
way
of
doing
it.
A
So
this
is
kind
of
backing
the
CMS
and
we'll,
hopefully
up
our
score
there
as
well
cool.
A
A
We
were
able
to
get
a
score,
I
believe
the
score
we
got
was
in
like
the
C
range,
so
it
wasn't
like
we
passed,
we
went
up
a
level
to
minimal
I,
think
it
was
minimal,
but
I
can
share
that
out
after
as
well,
because
some
of
the
feedback
that
came
out
of
that
was
pretty
interesting,
especially
because
people
were
looking
for
a
way
to
see
this
on
the
group
Level
side
nav
and
they
couldn't
find
an
environments
area.
So
it's
interesting
that
they
went
there
first
before
kind
of
searching
elsewhere.
A
A
I
do
remember
someone
said
like
Oh
I
thought
there
was
an
environments
area
on
the
side
nav
and
then
they
looked
into
it.
They're
like
oh,
that's
only
at
the
project
level.
So
someone
had
remembered
that
you
could
get
to
an
environments
area
from
that
left,
nav
I
guess
they
didn't
realize
it
was
only
in
the
project
section.
A
I
guess
so
that
was
the
scenario
I
put
is
for
your
group.
You
want
to
kind
of
view
the
status
of
your
environments,
so
that
kind
of
I
guess
LED
them
into
the
group
level.
We
didn't
quite
ask,
but
that
would
be
an
interesting
question
if
you
weren't,
leading
them
into
that
scenario
from.
B
The
start,
the
reason
why
I'm
asking
that
to
me
it's
not
surprising
actually,
but
because
I
was
running
many
user
calls.
It
seems
to
be
pretty
a
typical
pattern
that,
like
what
Andrea
said
that,
like
a
a
group,
you
know
micro,
Services
setup.
For
example,
a
group
would
contain
all
the
microservices
that
compose
an
application,
or
sometimes
even
multiple
applications.
A
The
other
Insight
is
the
top
nav
environments,
dashboard
people,
the
only
people
that
opened
it
up,
knew
it
was
there.
The
people
who
manually
went
through
every
project.
They
weren't
aware
that
there
was
even
anything
up
there
on
a
dashboard
perspective,
so
that
was
an
interesting
Insight
too.
Is
people
weren't
going
up
there
to
see
if
there
was
anything
there.
B
A
Well,
okay,
so
I'll
share
my
screen
just
to
give
some
context.
So,
when
we're
looking
into
this,
it
was
kind
of
hard
to
organize
a
user
Journey
around
this,
because
it
was
really
you
were
coming
to
a
page
to
view
status.
So
what
I
kind
of
did
here
was
took
the
user
journey
and
kind
of
put
in
some
tasks.
People
may
be
doing
at
the
group
level,
so
checking
the
status
of
deployments
of
their
projects,
checking
the
health
of
their
environments,
checking
what
is
currently
deployed.
A
So
I
kind
of
put
this
together
as
like
a
base
of
how
I
would
Craft
this
page
up
and
then,
if
I
can
figure
out
where
my
mouse
went,
we
kind
of
landed
on
something
like
this,
so
what
we
did
is
we
took
out
a
lot
of
the
information
that
you
see
at
the
project
level,
because
we're
aware
that
this
page,
you
didn't
need
to
see
all
the
information
we
were
sharing
at
the
project
level.
A
A
This
just
makes
it
a
lot
easier
to
see
at
a
glance.
What's
going
on
versus
our
current
available
and
stopped,
which
doesn't
give
you
much
information,
you
can
kind
of
see
the
information
based
on
what
is
deployed,
but
we're
really
looking
into
how
do
we
share
the
environment
information,
so
you
can
dig
deeper
into
that
later.
A
Then
we
simplified
what
we're
showing
for
what's
recently
deployed.
So
we
show
the
most
recent
activity
as
well
as
what
is
coming
up,
so
it
has
successfully
been
deployed
and
if
there's
something
upcoming
as
well
as
the
commit
and
who
triggered
it,
and
then,
if
you
want
to
get
into
more,
you
can
just
click
the
environment
name,
and
that
brings
you
to
that
environment
Details
page,
so
you
can
dig
in
a
bit
more.
A
We
also
wanted
to
share
the
door
metrics
at
the
top,
because
these
are
things
that
people
would
want
to
see
at
a
glance.
It
gives
a
good
overview
of
what's
kind
of
happening
across
your
project
as
well
as
a
way
to
filter
and
search
through
these
environments
based
on
status,
name
and
like
sort
them
by
most
recently
deployed
in
all
of
that.
So
this
is
the
most
recent
version
of
it,
but
we
do
want
to
mock
up
a
version
that
uses
actual
real
data
to
test.
B
A
So
if
you
don't
have
production
tier
set
up,
we
kind
of
will
prompt
you
here
on
how
to
start
using
environment
tiers
as
well.
So
if
you
come
to
this
page,
you
don't
have
tiers,
set
up,
there's
a
prompt
into
using
that
too.
But
yes,
it's
automatically
populated,
so
we're
getting
rid
of
that
manual.
Setup
process
of
the
environment,
dashboard
that
we're
currently
running
into
problems
with
and.
B
A
It's
actually
a
good
question,
because
we
didn't
mock
up
a
version
of
this
of
what
it
would
look
like
with
subgroups,
because
I
assume
that
would
be
you'd
have
to
double
up
this
area
here,
because
this
is
currently
where
we're
showing
the
group
and
then
the
environment
or
a
project
and
environment,
but
within
groups
we'd
probably
have
to
design
up
that
top
bar
a
little
bit
different.
So
you
can
see
where
things
are
coming
in
or
potentially
this
we
adjust
this
page
yeah.
A
That's
a
good
question,
though,
because
we
haven't
actually
designed
this
for
subgroups.
So
that's
something
I
should
definitely
look
into
do
you
have
any
ideas
of
how
that
could
look.
E
Know
it
would
be,
it
would
be
interesting,
maybe
if
we
could
somehow
aggregate
like
a
subgroup
status
and
have
that
as
a
card
instead
of
having
because
I
think
like
if
you
have
a
lot
of
deepliness
of
groups,
you'll
end
up
in
a
position
where
it's
too
many
environments
to
manage
on
this
page.
B
A
This
is
my
group
yeah
I
know:
we've
gotten
some
pretty
feedback
about
the
collapsibles
in
the
environments
page
itself.
So
if
we
do
go
that
route,
we'd
have
to
look
into
it
because
I
know
people
do
not
like
the
collapsible.
A
So
I,
like
the
idea
of
aggregated
I,
think
I
could
probably
mock
up
a
version
of
this
too
that
we
could
test
to
be
like
you
have
imagine
you
have
a
group
with
a
bunch
of
subgroups
and
you
come
to
this
page.
Is
this
what
you
would
expect
and
kind
of
do
a
test
in
that
too?
B
Trick
is
that
then
you,
so
you
have
to
be
aware
of
that.
There
might
be
a
group
that
has
a
bunch
of
subgroups
that
can
have
sub
Loops
as
well,
but
it
might
at
the
same
time
it
might
have
direct
projects
too.
So
you
want
both
to
be
visualized
somehow
and
anyway
yeah.
We
likely
have
to
add
that
I
didn't
want
it
to
stop
the
discussion
with
this.
A
No
I
appreciate
bringing
it
up,
especially
if
we
scale
this
to
be
more
than
just
the
production
tier.
It's
going
to
start
getting
Messier
and
Messier,
so
something
I
think
we
could
think
about
right
at
the
beginning.
So
thanks
for
bringing
it
up
because
I
think
it's
something,
we
definitely
need
to
look
into
I.
B
Know
that
I
wrote
up
the
other
question
a
couple
of
months
ago,
which
is
that
simply
using
production
here
can
be
pretty
misleading,
because
what,
if
I,
have
one
production
deployment
in
us
another
one
in
Europe
and
it's
like
I,
basically
see
everything
twice.
A
Yeah,
so
that's,
if
you
have
multiple
production,
would
there
be
any
naming
conventions
that
would
differentiate
those?
Is
there
anything
that
we
could
use
to
kind
of
differentiate?
That
one
is
in
like
America
is
one
is
in
Europe
that
we
call
out,
or
is
it
like
the
name
that.
F
Maybe
I
think
a
lot
of
people
are
actually
using
slashes
in
environment
names,
to
kind
of
group
them
to
I,
don't
know,
regions
or
yeah.
That
was
my
guess.
I
mentioned.
A
Because
we
will
Port
over
the
environment
name
itself,
so
hopefully,
if
they
are
naming
them
differently,
you'd
be
able
to
see
the
difference
here,
but
I
think
this
is
also
where
we'll
be
able
to
see
problems
when
we
poured
in
actual
data
into
this
prototype.
Actually.
B
Sorry
I
I,
followed
on
with
team
of
thought
and
I
think
I
would
go
with
slashes,
because
I
would
do
slashes
as
well
would
be
that
I
would
have
a
production
top
level
segment.
Slash
Europe,
slash
us.
E
B
F
I
guess
it
depends
on
how
you
look
at
your
product
right.
If
you
have
like
completely
different,
maybe
I
don't
know
apps,
which
are
you
know
in
either
region
you
may
want
to
first
after
each
and
then
production,
but
if
it's
like
just
like
some
replica,
then
you
might
want
to
have
the
production
first.
E
No
yeah,
but
with
a
with
a
page
like
this,
the
production
tier
acts
as
a
tag
anyways.
So
it's
not
like
you
need
to
organize
by
folder
anymore,
like
you're.
Gonna,
pull
all
your
production
to
your
environments
into
this
page
right.
So
using
the
folder
as
an
organizing
scheme
is
less
necessary
to
organize
by
tier.
F
Yeah,
that's
also
the
question
like
what,
if
you
want
to
see
the
other
or
filter
on
the
other
dimension,
first,
for
example,
filter
for
your
app,
which
may
have
different
environments,
and
then
you
have
in
there
a
production
and
a
station.
But
this
way
you
won't
have
this
capability,
because
you
always
filter
by
the
production
tier
first.
C
Yeah
so,
for
example,
in
your
Relic,
you
have
an
overview
of
your
system
based
on
text
that
you
can
assign
right.
So
maybe
that
would
be
also
one
of
the
approaches
because
yeah,
if
the
more
the
more
kind
of
Dimensions
we
have
the
harder,
it
is
the
structure,
I
guess,
but
then
we
can
offload
it
to
the
user.
If
they
apply
the
correct
tax,
they
could
also
slice
by
those
tags
together
with
the
environment
name
or
whatever.
They
already
have.
B
E
B
Okay,
I
will
bring
in
a
different
topic
now
that
that
I
wanted
to
ask
for
a
while,
because
I
think
this
is
these
are
great
ideas
and
we
should
definitely
look
into
them,
but
it's
I
think
this
is
mostly
for
for
you
Amy,
but
the
other
topic
was
that
when
I
asked
the
user
problems,
what
you
said
that
to
show
the
metrics
and
so
on,
a
single
base
and
the
only
matter
that
I
see
here
are
Dura
metrics.
B
A
B
A
Yeah
no
worries
I'll,
give
some
background
too
on
why
we
decided
on
door
metrics
for
MVC,
and
it
was
mostly
because
they
were
already
available
and
easy
to
implement
for
the
first
iteration
of
this
I
know
we
wanted
to
look
into
more
metrics
going
forward,
but
we
were
kind
of
trying
to
cut
this
down
into
like
how
do
we
show
some
useful
metrics
that
we
could
do
for
the
first
iteration
that
wouldn't
be
a
massive
lift
on
the
engineering
side,
so
that's
kind
of
why
we
landed
on
the
door
metrics
for
this
version
of
it,
but
I
was
experimenting
with
like
what
other
metrics
we
could
share
up
here
like
and
that's
kind
of.
A
Why
I
wanted
to
break
this
into
tabs
here,
but,
like
you
could
see
your
requires.
Attention
requires
critical
right
off.
The
bat
Vlad
I
saw
raised
his
hand.
B
D
Know
where
a
pension
and
critical
are
coming
from
in
the
past
we
have-
and
maybe
we
still
have
but
I,
never
seen
it
use
the
picture.
We
had
a
picture
called
alerts
which
is
basically
like
a
separate
entity
in
the
GitHub
and
those
alerts
have
level
I,
don't
know
like
in
the
locks
warning,
critical
and
others.
D
So
in
the
first
version
of
the
environments
like
the
old
environments
that
work,
which
is
on
the
user
level,
we
actually
at
least
I,
don't
know
we
implemented
it,
but
we
definitely
had
it
in
the
designs
and
I
think
this
kind
of
goes
from
back
there.
It
kind
of
went
to
through
to
this
design
as
well.
Actually
but
I
I've,
never
seen
anybody
using
these
alerts
and
I'm
not
sure
if
they
are
still
there
if
they
are
not
deprecated
or
something
yeah.
E
I
know
when
we,
when
we
rebuilt
the
dashboard,
I'm
90,
sure
I
made
sure
the
the
alert
still
worked
if,
if
like
an
alert,
was
provided,
it
still
shows
up,
but
yeah
I'm
with
you
I,
don't
know
the
status
of
our
Prometheus
integration.
B
Yeah
I
have
been
deprecated.
It
I
know
that,
because
it's
based
on
the
third
base
integration
I
mean
not
not.
No,
we
didn't
sorry,
no,
we
deprecated
one
part
of
it,
but
not
all
of
it,
because
you
can
still
connect
an
external
Prometheus
instance
to
gitlab,
but
then
I
think
authentication
is
mostly
an
unsold
issue,
so
it's
only
for
sat
manager
if
I
remember
what
I
wanted
to
to
get
back
to,
but
I
understand
the
deterative
approach.
Emily
you
mentioned
here
that
this
seems
to
be
feasible
and
not
so
not
overly
far-fetched.
B
At
the
same
time,
I'm
very
I
like
to
follow
a
different
approach.
Typically,
what
I
said
on
on
Tuesday
at
the
team
called
it
like?
Let's
have
a
vision,
let's
know
where
we
want
to
end
and
let's
validate
that
first
and
then
say
that
this
is
the
smallest
step.
We
can
do
in
that
direction
now,
because
I'm
worried
in
when
we
do
the
other
way
around
in
terms
of
like
what's
feasible
today,
then
we
are
not
providing
the
the
most
valuable
thing,
even
in
the
midterm.
Actually.
A
B
Exactly
and
you
should
validate
that
as
well
and
I-
think
that's
why
ux
is
super
super
important,
because
without
bidding
anything
we
should.
We
should
do
that
and
get
the
feedback
and,
after
that,
have
a
very
a
good
validation
on
the
initial
steps
as
well,
if
they
make
sense,
and
typically
they
do,
but
that
would
be
a
kind
of
a
the
the
at
the
very
beginning,
deep
approach
level.
B
How
I
it's
a
bit
hard
for
me
to
imagine
where,
where
we
go
with
all
of
this
like
like
you
would
break
it
down
even
further
in
the
first
iteration
to
just
do
not
have
Dura,
metrics
initially
and
then
defending
on
user
feedback.
We
might
not
want
to
have
draw
a
metrics,
but
would
focus
on
the
filters
or
on
something
else,
but
I
have
no
idea
where
we
are
going
with
all
of
this
actually.
A
B
A
Well
and
I
think
actually
that's
some
of
the
stuff
we
might
get
out
of
this
like
solution
validation
as
well,
because
I
was
really
wanting
to
focus
on
like
what
is
this
page
missing?
What
information
do
would
you
need
to
see
to
make
this
page
the
most
valuable?
Are
you
able
to
understand
kind
of
like
what
these
statuses
mean
and
all
of
those
things
so
I
think
some
of
that
will
help
lead
us
to
like?
Where
do
we
eventually
want
to
get
to
with
this
page
I
know
too
for
the
first
iteration.
A
These
statuses
are
brand
new
as
well.
We
currently
just
have
that
stopping
available
status
for
environments,
so
I
don't
even
know
if
that
is
feasible
for
the
first
iteration
of
this
page
or
not
so
I
think
there's
a
lot
of
open
questions,
but
I
like
the
idea
of
kind
of
building
up
a
kind
of
North
Star
we
work
towards
and
then
working
it
down
and
I.
Think
we're
partially
there
with
this
I.
Think
there's
some
things,
though,
that
we
could
definitely
adjust
and
fix
up.
B
Yeah,
based
on
what
I've
heard,
I
think
that.
B
You
you
didn't
receive
the
necessary
information
from
the
problem.
Validation
step
as
well
like
I
I
asked
about
subgroups,
but
I
know
that
I
have
no
idea
whether
it's
really
a
requirement
on
that.
D
Yeah
I'm
super
bad,
the
kind
of
Designing
something
from
scratch
and
into
our
creatures.
Is
there
anything
any
product
from
where
we
can
draw
some
inspiration
and
see
how
people
actually
doing
those
kind
of
things
I
mean
the
obvious
thing
would
be
I,
don't
know
grafana
where
you
can
build
anything
from
scratch.
Probably
we
don't
need
something
that
flexible,
but
anything
else
which
comes
to
mind
to
anyone.
B
Argo
CD
has
some
kind
of
dashboarding
UI
as
well
I
I
plan
to
check
out
Spinnaker,
but
I
expect
them
to
have
something
similar
as
well
and
overall
I
think
so
it's
looking
at
all
up
cubes.
There
are
a
few
open
source
projects.
They
are
not
related
to
to
development
work,
but
just
to
data
slicing
and
dicing.
That
can
be
helpful
to
to
see
how
people
visualize
these
multi-dimensional
data.
C
Another
sorry
Victor
another
interesting
project
to
check
out
I
think
could
be
backstage
from
Spotify,
because
it
also
provides
another
review
or
environments
as
well
as
projects
and
so
on,
which
actually
my
personal
opinion.
We
should
really
take
closer
look
right
now.
It's
in
a
very
kind
of
early
stages,
I,
would
say,
but
I
think
it
has
huge
potential,
and
it
can
be
also
like
competing
with
us
in
this
area.
Backstage.
B
A
I
just
want
to
go
back
to
Victor
when
you
kind
of
mentioned
about
the
previous
research
done.
I
wanted
to
give
you
some
kind
of
background
on
this
project.
It
seemed
like
before
I
joined
release.
There
was
actually
a
version
of
this
that
was
completed
and
ready
to
go
into
production,
but
because
our
project
level,
environments
page
performed
so
poorly
the
redesign
there.
The
design
of
this
was
based
off
that
and
that's
kind
of
why
this
has
gone
back
to
the
drawing
board.
So
there
was
like
a
design
available.
B
A
Yeah-
and
that
was
actually
on
purpose,
because
the
environment
dashboard,
apart
from
the
usability
and
Engineering
problems
that
make
it
really
hard
to
build
on
top
of
it,
performed
well
like
the
design
worked
really
well
and
we're
kind
of
taking
inspiration
from
that,
because
it.
A
Yeah,
it
saved
a
lot
more
real
estate,
that's
kind
of
why
you're
seeing
these
in
Little
Boxes
and
not
the
lines
on
the
environments
page
people
liked
it.
It
was
just
we
can't
really
iterate
on
top
of
it
very
easily
and
there
were
some
usability
issues
with
it.
So
this
is
kind
of
an
iteration
of
the
environments,
dashboard.
If
you
can
think
on
it.
B
A
A
Awesome
and
I
think
the
main
thing
is
like
the
reason
we're
bringing
the
statuses
into
is
because
people
are
basing
it
off
the
deployment
status
in
that
one
as
well,
because
right
now
you
can
see
your
deployment
status
if
it's
success
failed
blocked,
but
that
doesn't
always
equate
environment
status.
A
So
breaking
this
down
a
bit
more
to
understand
that
because
they
don't
always,
they
don't
see
one
to
one
all
the
time.
So
that's
the
one
Improvement
we
want
to
do
here
is
just
making
it
a
lot
more
clear
what
the
environment
is
actually
doing,
not
just
the
deployment.
A
So
that
goes
back
to
some
of
the
research
that
production
was
the
one
that
was
asked
for
first.
So
again,
this
is
the
iterative
approach
that
I
think
we
want
more
tiers
involved
in
this
and
you're
able
to
kind
of
select
the
tiers
you
want
to
monitor.
But
in
the
issue
the
acceptance
criteria
for
the
first
iteration
was
just
focused
on
the
production
here.
D
Okay,
I
had
another
question
Emily.
You
just
mentioned
that
we
had
a
version
of
group
environments
based
on
the
product
project.
Page
I
agree
like
that.
The
current
project
page
isn't
ideal,
but
did
we
consider
actually
reusing
design
still
like
from,
but
we
haven't
basically
the
same
cars
on
the
group
level
and
the
project
level
and
maybe
improving
with
parts
of
this
design,
just
improving
the
project
level
parts
and
then
using
the
same
ones
and
basically
the
only
difference.
D
There
would
be
that
you
have
a
group
like
project
name
before
the
environment
name
and
everything
else
would
be
the
same
and
any
Improvement
we
do
what
it
will
be
immediately
visible
on
both
pages
and
so
on.
A
Yeah,
this
is
a
funny
question,
because
I
had
this
discussion
with
Chris
I
was
like:
do
we
improve
the
project
page
first,
or
do
we
introduce
group
level
and
like
how
do
we
align
them
later
on?
We
move
towards
improv
like
adding
in
the
group
level,
because
it
was
such
an
asked
for
feature.
People
really
wanted
it,
but
there
is
that
other
issue
open
about
kind
of
iteratively,
improving
the
project
level,
page
and
I.
A
Think
if
we
do
this
we'll
have
to
actually
go
back
and
kind
of
take
some
learnings
from
this
and
apply
it
to
that
page
too,
because
I
agree,
I
think
they
should
look
very
similar.
The
project
level
page
needs
improvements,
as
is
right
now
and
I
think
we
could
take
some
of
this
and
reuse
it
on
the
project
level.
So.
D
I'm
just
afraid
that
if
we
kind
of
go
and
implement
this
from
scratch,
then
we'll
basically
Implement
everything
twice
and
then
it
will
be
I
mean
content.
Folks
can
maybe
collaborate
more,
but
I
think
it
will
be
a
lot
of
reflector
in
joining
those
two
designs
together.
If
we
ever
want
to
do
that
like
as
opposed
to
just
improving
a
little
bit
on
the
current
page
and
then
just
releasing.
C
Well
from
I
said,
I,
agree
and
I
think
that,
ideally,
we
should
reuse
design
components
between
the
pages,
like
environments
and
deployments
and
so
on.
However,
right
now
I
think
it's
a
bit
complicated
because
as
analysis
we
want
kind
of
forward,
while
also
providing
the
good
solution
for
the
users.
I,
don't
know,
it's
basically
I
think
they're
pretty
hard
actually
to
decide.
What
is
the
best
thing
to
do
right
now,
but
eventually
definitely
we
should
unify
our
the
ux
across
all
these
pages.
E
Yeah
I,
my
my
opinion
is
that,
provided
this
page
gets
like
the
proper
research
and
validation
before
we
go
and
build
it
out.
The
result
will
be
the
same
as
if
we
improved
projects
first
and
then
built
this.
We
also
have
like
we
have
a
whole
page
still
using
the
old
environments.
Dashboard
that,
like
is
its
transition,
was
just
halted
because
the
main
environments
page
went
so
poorly,
so
we're
we're
in
a
tricky
spot
where
we
just
need
to
figure
out
something
and
then
whether
that's
building
and
then
like.
E
If
we
build
something
new
and
it
takes
off
at
least
it's
a
little
better
to
it's,
the
order
doesn't
matter
in
my
mind.
What
matters
is
is
this
is
the
validation
and
then,
and
then
it
all
it
all
falls
from
there.
Although
on
that
level,
one
thing
to
keep
in
mind
when
we,
if
we
do
start
trying
to
apply
this
to
the
projects
page,
is
that
we
have
that
whole
folder
mechanism
that
we
have
to
keep
in
mind.
That's
probably
gonna
be
bad,
but
future
problems.
B
Sorry
getting
specifically
to
this
design
back
I
I
would
have
two
more
minor,
and
this
is
a
change
of
topics.
So
if
anybody
has
anything
else
to
say
about
the
front-end
button,
please.
D
B
Okay,
okay,
well
I.
What
I
was
looking
at
is
the
waiting
and
running
lines,
and
especially
with
the
running
line
I
could
I
I
would
like
to
see
as
well
I'm
innovating
items
there
might
be
that
are
more
recent
than
the
current
running
ones,
for
example,
because
that
might
be
something
that,
like
okay,
that's
running,
that's
good,
but
it
started
yesterday
actually
not
10
minutes
ago
and.
B
Like
what
was
going
on
and
the
same
for
debating
that
like
I,
see
that
that
specific
commit
is
waiting
or
pipeline
is
waiting,
but
like
how
many
other
waiting
items
are
there.
These
were
my
first
and
of
missing
items
on
the
page
and
the
other,
and
the
last
one
which
is
really
minor,
is
just
the
recent
activity.
A
Yeah
I'll
start
with
the
second
one,
because
I
think
latest
activity
is
actually
a
much
better
word
for
this
because
it
doesn't
take
in
the
time
like
if
it
was
today
or
last
year.
Latest
is
definitely
I.
Think
a
Better
Label
there
I
know
when
talking
with
Chris
too
we're
like
that
label
is
a
little
awkwardly
placed.
A
So
I
think
there
has
to
be
a
bit
of
work
done
on
how
to
integrate
that
into
the
design
nicely
too,
because
it's
kind
of
sitting
weirdly
above
everything
and
then
for
your
second
comment,
I'm
glad
we
were
having
this
conversation
in
the
other
issue,
where
I
realized
that
this
waiting
block
to
running
there
can
like
be
multiple
of
these
and
I.
Think
it's
just
a
decision
of
like
how
many
do
we
show
here.
A
Do
we
show
like
waiting
and
then
a
plus,
like
four
more
that
they
can
click
into
and
learn
more
in
I
think
there's
a
way
to
kind
of
get
around
that
but
I
didn't
know.
That
was
even
a
problem
until
a
few
days
ago,
when
we
were
discussing
it
in
the
other
issue,
so
I'm
glad
that's
kind
of
tying
back
into
this.
A
A
No
thanks
to
everyone
for
the
feedback
here.
I
think
this
is
like
great
discussion.
I
did
want
to
ask
if
frontend
had
any
questions
they
wanted
to
add
for
the
Q
a
just
because
I
know
I
didn't
want
to
take
all
the
time
up
with
this,
but
if
not,
we
can
continue
discussion
here
too.
E
B
B
Those
who
don't
know
what
we
speak
about
there
is
this
issue
on
how
to
show
upcoming
and
past
deployments
on
a
page,
and
the
initial
idea
was
from
Andre
to
have
like
a
a
checkbox
if
I
remember,
that's
how
you
go
switch
switch
and
that
morphed
into
two
tabs
that
I
was
proposing
as
well,
and
then
we
realized
that
that's
like
not
the
best
study
and
that
had
a
big
summary
of
what
he
thinks
would
be
the
best
and
that's
the
topic
that
I
thought
might
we
might
Fast
Track,
as
all
of
us
are
here.
D
D
D
E
I
also,
historically,
we
just
show
the
most
recent
non-finished
deployment
and
there's
always
been
plans
to
show
more
of
those
in
the
main
page,
but
obviously,
we've
had
UI
scalability
issues
there.
So
just
dumping
a
list
of
blocked
block
deployments,
isn't
a
good
solution
and
I.
Think
approvals
really
made
this
harder
as
well.
E
Yeah
I
wonder
I
wonder
if,
like
we
should
start
rejecting
deployments
that
are
old,
that
are
waiting
for
approval.
C
C
E
As
long
as
anything
more
recent
has
been
deployed
because
you
can
always
rerun
them,
so
I,
don't
I,
don't
know.
If
there's
like
a
major
problem,
there.
D
We
already
have
a
mechanism
for
canceling
the
old
deployments,
like
not
up-to-date
ones,
it's
just
a
checkbox
in
the
settings
of
the
project.
I,
don't
know
so
I,
don't
know
how
it
works
with
the
manual
group.
Actually
does
anybody?
Have
anybody
tried
it
because,
like
what?
How
I
would
expect
it
to
work
is
that
you
can
run
any
manual
work,
but
as
soon
as
you
run
it
it
cancels
everything
which
is
older
than
it
and
it's
like.
D
C
Like
my
true
sense
about
the
whole
situation,
where
you
have
like
really
a
lot
of
painting
deployments,
waiting
for
approvals,
so
I
have
a
feeling
that,
for
example,
what
this
customer
has
like
this
kind
of
issue
is
really
a
misconfiguration,
and
we
maybe
should
provide
a
better
guidance
on
how
to
better
achieve
what
they
want,
because
I
think
they
could
have
totally
get
away
with
and
then
basically
just
real
deployments
that
they
want
to
deploy
pending
and
the
rest
would
like
never
be
created
because
that's
what
they
want
in
the
end
right.
C
D
I
can
again
okay
dive
into
history
here
with
historian
on
this
team.
I
guess
so.
In
the
past,
we
deployment
was
just
a
simple
database
model
which
was
showing,
which
was
created
only
when
you
were
running
the
job
in
the
CI
which
had
an
environment
keyword,
and
it
worked
exactly
like
I
guess.
Andre
you
just
described
like
there
was
nothing
in
the
deployment
page
anywhere
until
you
go
to
the
CI
pipeline,
find
the
manual
job
and
run
it
or
it
will
run
automatically.
Then
it
will
create
the
deployment
model.
D
Yeah
shiny
would
be
the
best
to
describe
why
we
changed
that
to
create
deployments
always
right.
Now
we
create
deployments
every
time
you
create
the
job
in
CI
does
even
if
it's
not
we're
running
yet.
Another
kind
of
like
I'll,
try
to
find
an
issue
and
again
it
would
be
best
to
discuss
it,
but
we
had
another
issue
about
only
creating
deployments
when
the
job
is
actually
actually
can
run.
D
For
example,
if
you
have
a
pipeline
I
guess
with
the
prerequisites
for
the
deployment
job
and
it's
not
runnable,
then
we
will
not
create
a
deployment,
but
it's
actually
a
big
topic
like
when
we
want
to
create
these
deployments.
But
my
concept
of
what
we
were
discussing
on
this
issue.
It
actually
assumes
that
you
create
deployments
all
the
time
and
then
you'll
have
this
nice
look
of
each
commit
and
you
can
execute
on
the
deployments.
D
You
need
yeah,
but
if
we
don't
do
it,
then
you
will
not
have
this
nice
button
to
run
the
deployment
from
the
environment
detail
page.
So
I
don't
know
it's
actually
a
good
question.
We
probably
should
one
day
brainstorm
on
when
and
how
to
create
the
words
and
what
do
they
mean
and
we
should
definitely
do
it
with
China,
because
we
changed
it
a
few
times.
E
D
But
personally,
I
like
how
it
works
now
with
randomly
create
deployment
and
makes
it
possible
to
do
like
to
make
this
deployment
too,
as
I
was
describing
on
that
issue.
D
A
I
know
in
regards
to
the
issue:
I
left
my
kind
of
like
design
opinion
on
it
yesterday,
I'm
sorry
that
it
took
me
so
long.
I
just
had
to
catch
up
with
all
the
discussions.
A
So
I
know
we're
running
close
to
time
now,
I'm,
not
sure,
if
we'll
have
time
to
kind
of
sort
through
everything
right
now,
but
just
wanted
to
give
a
heads
up
that
I've.
Given
my
update
to.
D
A
A
I
have
oh
voice
for
the
first
iteration
I
liked,
Victor's
idea
of
kind
of
just
having
messaging
around
and
then
for
a
second
iteration
I
think
we
could
have
like
an
ideation
session
on.
How
do
we
actually
solve
this
without
having
like
a
permanent
Banner
on
the
page.
A
C
E
There
was
a
there
was
a
specific
issue
where
we
wanted
the
not
started
deployments
at
the
top,
and
we
did
it
via
hacking,
like
the
fact
that
postgres
puts
nulls
at
the
top
when
sorting.
E
But
yeah
we're
really
running
into
like
scalability
issues
with
these
deployment,
jobs
I
think,
is
the
problem
right.
I'll
see
if
I
can
find
the
issue,
but
it
was
like
two
or
three
years
ago.
So
you
know
don't
don't
don't
hold
that
up.
A
Well,
thanks
all
for
the
first
good
design
pair
session,
I
think
this
was
really
really
productive,
so
I'm
excited
to
keep
posting
them
in
the
future.