►
From YouTube: Environments Design Pair Session - 14/09/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
B
Right,
yeah
thanks
Amy
Lee,
so
yeah.
Let's
continue
discussing
the
blueprint
stuff
I
forgot
to
count,
but
this
would
be
Forza
fifth
time
but
anyways,
provided
that
everyone
has
already
read
bill.
Plains
stuff,
the
current
state
I
think
we
should
discuss
the
group
level
overview
ux
with
reviewing
the
diagram
recently
Victor
updated
the
diagram.
Thank
you
Victor.
So
I
wonder
if
you
can
walk
us
through
a
bit
like.
Let's
see,
you
know,
explain
the
diagram
a
bit.
Please.
C
D
D
C
C
C
Actually
there
are
free
release
artifacts.
This
is
the
part
that
I
don't
like
in
this
formulation,
because
so
I
imagine
that
you
have
a
history
of
versioned
release
artifact,
and
these
are
free
versions
like
the
one
behind.
C
C
This
is
the
current
version
here
and
if
this
would
be
version
1.0
here,
okay,
let's
not
do
that.
This
is
so,
let's
change
the
versions,
please.
This
is
version
1.0,
that's
in
this
production
environment,
let's
say
and
then
2.0
that's
in
staging
already.
So
this
is
kind
of
a
history
how
the
versions
will
be
rolled
out.
C
D
B
I,
have
a
I
have
a
question.
So
what
you're
saying
release
artifact
it's?
B
It
might
be
just
just
an
artifact
or
has
already
sorry
sorry,
I'm
gonna,
replace
so
let's
say
version
1
version,
2
version,
303,
artifacts
and
then
version
2
might
not
be
deployed
at
all,
like
let's
say,
like
operator
skipped
it.
In
this
case
there
are
three
really
side
effects
and
the
two
deployments
is
it
correct.
C
Yes,
it
could
be,
it
could
be
correct.
The
question
is
yes,
so
it
could
be
totally
correct.
So
let's
say
that
you
have
version
1.0,
1.2
and
2.0.
Okay
version
1.0
was
deployed
first
to
staging
everything
was
good.
It
was
deployed
to
production.
Now
it's
running
in
production
version,
1.2
is
deployed
to
staging
already,
but
not
to
production
yet
and
version
2.2
was
just
built,
it's
not
deployed
yet
anywhere.
C
So
this
is
one
option
to
get
set
up.
Another
option
is
that
yeah
there
was
a
version
1.21,
that's
for
whatever
reason
never
got
to
production,
but
it's
already
skipped
in
staging.
B
D
C
B
C
And
then
there's
one
more
property
of
this
deployed
release
artifact,
slash
deployment,
which
will
be
the
rollout
status.
We
never
spoke
about
it
and
it's
not
on
the
on
the
diagram.
I
just
wanted
to
highlight
that
to
stay
there
they
might
be
already
deployed,
but
not
in
front
of
the
users,
and
this
way
you
can
actually
have
multiple
deployments
at
once
in
a
single
environment
of
the
same
service.
As
you
are
rolling
out
from
one
person,
ten
percent
Etc,
you
have
the
old
and
the
new
deployment
as
well.
B
Sorry,
do
you
understand
correctly
that
deployment
has
a
state
of
rollout
or
not.
C
Good
yeah
and
basically,
what
I,
what
I
mentioned
before
and
and
could
be
fixed
here,
is
that
the
the
release
artifact
could
have
a
deployment
in
a
different
environment
as
well,
because
you
deploy
version
1.1,
you
deploy
it
to
staging,
and
then
you
deploy
it
to
production,
but
it's
the
same
release
artifact
that
you
deployed
to
staging
and
to
production.
E
No
I
I,
don't
I,
didn't
want
to
at
least
at
this
point.
It
makes
sense
and
conceptually
I
think
it's
also
right
and
very
important
that
the
release
artifacts
are
shared
between
environments
that
because
I
I
think
many
companies
got
it
wrong
and
that
only
that
leads
to
all
kind
of
issues.
So
this
is
a.
D
E
B
C
C
That's
that's
what
I
wanted
to
mention
exactly
I,
don't
know
how
it
would
be
the
best
to
represent
it
actually.
C
That's
that's
why
and
I
I
didn't
knew
how
to
best
represent
that
that
it's
it's
basically,
you
can
say
that
what's
the
word
that
this
deployment
is
the
projection
of
this
deployment
into
gitlab,
but
in
a
different
way,
it's
at
the
projection,
because
it's
the
output
of
deploying
this
release
artifact
into
this
environment,
it's
the
same
just
from
different
angles.
B
B
E
C
Each
service
in
each
environment
has
its
own
metrics
and
then,
if
you
look
at
the
timeline
on
that
timeline,
you
likely
you
likely
want
to
be
able
to
prove
by
deployment.
So
at
least,
if
it's
a
timeline,
you
want
to
show
that
this
is
where
it
got
deployed
and
so
on,
but
actually
more
than
that,
you
want
to
see
for
a
canary
rollout.
For
example,
you
would
like
to
see
that
like
did
the
metrics
improve
in
the
canary
version
compared
to
the
old
version,
and
then
you
have
to
have
the
metrics
per
deployment.
C
Actually,
so
that's
a
very
good
question.
I
think
I
would
say
that
you
define
the
metrics.
You
define
what
you
want
to
measure
at
the
intersection
of
actually
at
this
service
level,
it's
not
even
the
intersection,
but
at
the
at
the
service
level.
That's
where
you
find
that
this
is
the
prompt
QR
query
that
I
want
to
run,
but
the
metrics
should
show
up
per
deployment.
C
B
Think
that
aligns
with
the
design
Sprint.
What
do
we
design
right.
A
Just
jumping
in
here
to
answer
your
one
question
is:
this
is
a
good
visualization
of
how
a
deployment
is
kind
of
shown.
What,
if
you
just
made
the
one
at
the
bottom,
a
straight
like
not
a
dotted
line,
the
one
at
the
top
dotted
and
that
kind
of
shows
it's.
C
F
C
So
definitely,
yes
to
the
first
part,
and
you
asked
I,
think
one
of
the
very
difficult
questions
that
we
we
still
have
understood
just
yesterday,
I
posted
a
comment,
one
of
Emily's
issues.
If
I
remember,
that
was
exactly
about
this-
that,
like
how
do
we
Define?
C
What
shows
up
is
as
the
as
the
status
of
a
service
as
the
as
the
metrics
of
a
service
like
you
can
Define
it
with
a
prompt,
QR
query.
But
like
is
there
any
other
way
like
for
half,
for
example,
so
I
I
don't
know
what
would
be
the
best
to
to
Define
it
like
today.
What
we
have
that
similar
to
that
is
the
in
the
environment,
cluster
UI,
when
you
select
a
ham,
release
or
a
customization,
and
then
basically
we
say
that
the
status
of
that
hammer
is
is
the
status
of
your.
C
If
I'm
not
mistaken,
then
most
monitoring
tools
have
their
own
agent
and
then
have
a
configuration
that
you
have
to
provide
them
for
each
like
a
long
time
ago,
when
I
used
New
Relic
that
you
had
to
provide
a
new
really
key
and
all
the
stuff,
that's
how
it
showed
them
that
this
is
I
am
reporting
back
for
that
service.
Basically,.
C
F
I
mean
I,
think
I
think
if
we
build
our
own
agent,
we
have
more
control
over
what
the
API
looks
like
right
like
ultimately,
it's
less
work
means
we
don't
have
to
Target
each
individual
providers,
apis
or
or
whatever
I
just
more
mean
like
do
we
need
do
we
need
something
something
in
the
record
of
the
deployment
that
is
like
this.
This
deployment
on
gitlab
is
this
deployment
on
Google
cloud,
and
you
can
click
here
and
you
can
go
see
it
on
Google
cloud
and
like
that
kind
of
a
thing.
C
I
I
would
say
not
yet
so
I
don't
know
if
you
will
get
such
requests.
It
makes
sense
at
least
a
certain
point
like
what
but
I
have
a
question
that
that
really
moderator
is
like.
Would
you
consider
a
situation
where
that
this
deployment
here
means
these
kubernetes
pod,
and
you
want
to
show
it
in
the
dashboard
in
the
kubernetes
dashboard
or
it's
it's
not
in
that
sense.
C
F
B
C
D
B
B
Yeah
that
totally
makes
sense
all
right.
My
question
was
that,
for
example,
like
a
last
demo,
you
demonstrated
as
the
put
at
the
head
project-
and
you
said
that,
like
it
is
an
entry
point,
this
is
artifact
and
there's
a
you
know,
cyber
artifact
and
and
then
there's
a
Hermit
chart
and
there's
a
the
subject.
Yeah
and
then
you
said
all
of
these
are
artifacts
and
then,
if
these,
like,
let's
say
there
are
five
bad
facts
are
deployed
at
once,
then
does
it
mean
one
deployment
has
five
artifacts.
C
C
So
now
here
you
see
all
the
artifacts,
because
all
the
artifacts
are
containers
and
I
would
say
that
the
and
now
there's
no
hundred
percent
connection
between
how
I
think
things
should
work
and
how
they
work
today.
But
what
I
would
say
that
the
release
artifacts
is
where.
D
C
C
C
A
C
A
A
C
D
F
A
And
then
another
question:
when
you
mention
the
release:
artifact
is
connected
to
the
deployment.
Are
you
what
was
the
word
you
were
using
for
that
deployment
with
the
dotted
line?
It's
like
skipping
my
mind
right
now,
projection
yeah.
Is
it
related
to
the
projection
or
the
one
in
the
Target
infrastructure.
C
C
What
shinya
is,
after
that
do
the
metrics
relates
to
to
deployment
and
the
metrics
are
actually
generated
here,
like
you
have
the
error
rates
in
here,
but
we
show
that
in
gitlab
and
that's
how
that's
what
I
mean
by
projection.
So
it.
A
A
My
comment
came
in
where
this
is
I.
Think
I
really
can
a
really
hard
diagram
to
build
up,
so
I
think
it's
okay
to
be
a
bit
confusing,
as
we
make
it
more
clear.
D
D
B
B
Our
final
goal
is
to
replace
this
really
really
Satisfied
by
deployment.
Is
it
that
what
you're
trying
to
say
at
the
right
diagram.
B
I
I
mean
like
a
yeah
the.
When
we
look
at
the
left,
one
left
the
project,
we
don't
see
any
deployment
word
right.
Oh.
C
Yeah,
no,
what
I
wanted
to
yeah?
That's,
why
I
realized
that
it's
needed
as
well
a
deployment
but
yeah.
It's.
B
C
Think
or
I
think
yes,
I
think
that's
correct,
yes,
and-
and
we
should
show
it
as
a
status
of
the
release,
version
that
this
version
was
already
deployed
to
this
environment,
or
it's
waiting
to
be
deployed
to
that
environment.
Yes,
and
the
deployment
itself
is
a
is
a
secondary
thing
for
gitlab.
In
that
sense,
yes,.
C
Yeah,
what
I,
what
I
changed?
Just
for
all
of
you
to
make
it
clear
is
that
I
made
it
so
that
they?
What
I
said
before
that
a
single
release?
Artifact
has
different
deployments
in
each
environment
and.
D
I
just
made
it
sure
that
we
have
different
deployments
when
needed.
Yeah.
A
A
C
And
the
original
topic
was
to
discuss
group
level
things
as
well.
If
I'm
not
mistaken,.
D
C
It's
more
I,
think
I,
don't
know,
I
mean
if
you
had
a
chance
to
to
read
through
the
discussion
we
had
with
shinya
and
Andrew
on
on
that
group
level
stuff
and
it's
a
the
question
is
really
what's
the
best
from
a
ux
perspective
and
what's
feasible
from
a
performance
perspective.
I
think,
because.
C
My
and
as
I
wrote
their
intuition
and
I'm
totally
happy
to
be
questioned
on
that
is
that,
from
a
ux
perspective,
it
would
be
better
to
aggregate
by
the
human
provided
names,
because
then
it's
automatic
we
can
just
yeah
immediately.
Here
you
have
your
group
level
views
and
if
you
were
prudent
enough
to
not
have
any
typos
in
your
environment
names
or
just
automate
that,
then
you
are
done.
You
have
group
overviews.
D
That's
that
was
my
idea
there,
but
I
don't
know.
A
Yeah
I
was
briefly
reading
through
that
before
we
jumped
on
this
and
I
think
that
makes
sense.
I
I
do
agree
with
Andrew's
comment.
We
just
have
to
make
sure
that
people
are
aware
if
they
make
typos,
that
they
can
go
back
and
adjust
for
that,
but
just
opening
this
up
to
anyone
else.
Do
you
see
any
concerns
with
going
by
the
names
users
give
or
major
problems
with
that.
F
I
did
I
did
write
more
kind
of,
as
this
meeting
was
starting,
but
basically
we
can't
rename
environments
today.
So
that
is
going
to
be
a
big
hurdle
and
I
think
we
can
probably
combine
both
approaches
to
save
on
performance
by
doing
some
name-based
matching
at
like
setup
time,
but
still
provide
users,
the
flexibility
to
name
their
environments.
However,
they
like.
A
D
F
B
Why
so
so,
like
the
one
over?
The
reason
is
that
users
can
change
the
implication
of
the
environment.
Like
you
know,
the
staging
environment
has
been
deployed
for
a
year
and
then
suddenly
it
becomes
production
environment
like
a
relative
to
it
and
then
like
it's
totally
different
like
there's
a
whole
deployment
history.
But
now
it
all
looks
like
a
production
deployment
and
then
this
also
affects
the
draw
metrics.
B
It's
really
confusing.
For
that
part,
so
yeah
we
concluded
that
we
better
to
disable
the
renaming
it's
easier
like
if
you
want
to
rename
you
get
a
recollected
because,
like
the
previous
history,
is
completely
different
irrelevant
to
the
new
name.
So
this
make
a
situation
that
make
a
bit
opposition
like,
for
example,
let's
say:
there's
a
typo
in
the
environment.
Name,
that's
yeah!
That
sucks
because,
like
they
have
to
regulate.
F
C
I
think
that's
a
very
good
question
if
we
want
to
do
to
have
any
kind
of
migrations
here,
because
I'm
not
sure
about
that
I
might
I
might
leave
environments
as
they
are
and
try
to
to
build
it
on
top
of
it.
Because
environments,
as
we
discussed
last
week
or
two
weeks
ago,
is
just
such
a
flexible
concept,
and
it
was
so
lightweight
that
it's
it's
created
to
be
misused
in
all
kinds
of
creative
ways
as
a
result.
C
C
C
F
C
And
if
it
turns
out
in
five
years
time
that,
like
this
is
just
so
successful
that
everybody
uses
it
and
people
stopped
using
environments
in
all
kinds
of
weird
ways,
then
people
someone
will
be
able
to
deprecate
it,
but
that
should
be
their
problem.
Not
ours.
I
think.
A
A
I
think
from
a
ux
standpoint,
I've
been
chatting
with
Victor
about
our
first
MVC
about
what
we
have
to
get
designed
out
for
this
to
work,
including
probably
not
a
design
of
the
configuration,
but
some
sort
of
like
idea
of
how
it
is
configured
laid
out
in
a
user
Journey.
So
I'll
be
focusing
kind
of
on
that.
B
I
think
we
need
to
continue
group
level
how
we
address
that
right.
So,
according
to
ubiquita's
comment,
this
is
need
to
be.
This
needs
to
be
inside
a
scope,
so
yeah
we're
gonna
have
an
answer
for
that.
So
let's
continue
the
async
discussion.
C
Like
right,
what
I'm,
what
I'm
in
there
is
that
what
actually
Andrew
wrote
that
we
don't
have
to
make
sure
that
we
don't
have
to
refine
the
group
level
scope
immediately,
but
we
have
to
design
a
setup
that
we
know.
We
have
at
least
a
rough
idea
how
we
can
support
the
group
level.
A
And
to
add
on
to
this
I
met
with
a
customer
yesterday
and
they
reiterated
the
importance
of
group
level
when
they
saw
this.
They
commented
and
said
they'd
like
to
be
able
to
see
it
at
the
group
level
for
monitoring.
So
I
think
it
is
import,
something
important
that
we
look
towards
supporting.
C
I
think
I
can
actually
describe
you.
The
the
happy
The
Golden
path.
I.
Would
it's
more
than
gold,
it's
more
than
this
happy
golden
path
that
that
is
something
like
you
are
a
microservices.
C
C
So
you,
when
you
open
your
group
level
environments,
you,
you
will
see
a
list
of
your
projects
presented
by
environment,
that
you
have
to
pick
and
the
environments
come
from
a
the
project
level
or
if
we
come
up
with
a
group
level
concepts
for
that
group
level
concept.
C
But
the
basic
idea
is
that
you
don't
really
need
to
set
up
many
things
in
in
this
micro
Services
world,
because
the
service
comes
from
the
project
name
and
basically
existing
users
or
the
environments
features
would
just
automatically
benefit
from
it.
That's
the
that's!
The
best
I
could
imagine
up
to
this
point.
A
That
kind
of
did
something
like
this,
so
they
said
if
they
could
see
it
in
gitlab.
That
would
be
incredibly
helpful,
but
they
were
doing
the
same
thing.
They
were
naming
their
projects
as
microservices.
C
And
Andrew's
chat
deployment,
approvals
or
metata
on
the
release.
Artifacts.
D
D
C
Thing
here,
I
I
would
primarily
agree
with
Andrew
here,
I
think,
but
not
hundred
percent.
So
there's
two
things
what
Andrea
says
as
well,
that
mostly
everything
is
part,
and
this
is
not
deployment.
This
is
more
like
a
release
Here,
but
so
everything
is
what
you
see
here
is
the
property
of
the
release
artifact,
except
what
you
see
in
the
yellow
boxes,
because
that's
the
property
of
the
deployment.
C
So
it's
it's
really
outdated,
but
the
sorry
now
it's
getting
more
confusing
than
I
I
wanted
to
actually
make
it
more
like
in
anything
I.
Think
most
things
are
metadata
and
and
data
on
the
release
artifact,
except
for
the
rollout
information,
because
what
we
call
deployment
approvers
are
actually
really
approvals.
Am
I
allowed
to
to
deploy
this
stuff
or
or
roll
it
out
in
front
of
this.
It
might
be
both
actually
both
release
and
and
rollout
approval,
but
but
definitely
deployment
specific
is
the
rollout
that
now
it's
really
good
10
of
customers
or.
C
I
think
this,
the
the
glossary,
really
helps
here
a
lot
and
it's
just
very
hard
to
stick
to
it,
but
like
having
these
specific
things
that
we
have
a
release
artifact,
we
have
a
deployment,
we
have
a
rollout
and
then
you
can
see
that
you
likely
want
to
have
approvals
before
the
deployment
and
you
might
want
to
have
approvals
after
deployment
or
not
really
approvals,
but
more
like
a
mechanism
to
automate
data
or
loud.
It's
more
like
that.
At
that
stage,
I
think.
D
A
Thanks
again
shinya
for
bringing
this
topic
here
and
helping
Victor
and
Shania
helping
lead
the
conversation
because
I'm
completely
brain
foggy
this
week.
But
if
we
don't
have
anything
else,
we
can
get
some
time
back.