►
From YouTube: Environments Design Pair Session - 29/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
A
So
what
we're
looking
to
do
today
is
kind
of
Define.
What
a
service
is
and
how
a
service
interacts
with
other
areas
and
Concepts
in
gitlab.
So
I've
conceptual
models
are
a
thing
we
do
at
gitlab,
I.
Don't
think
we
do
them
very
often,
but
it
is
like
a
template.
We
follow
in
pajamas
and
I
think
this
will
be
really
helpful
for
removing
the
blueprint
forward
so
I
think
for
this
meeting.
A
We
can
kind
of
focus
on
like
what
attributes
go
into
a
service
as
well
as
like
any
actions
and
then
how
the
service
relates
to
everything
around
it,
like
environments,
release
artifacts
and
all
of
that,
so
before
we
get
started,
does
anyone
have
any
questions.
A
Book
diagnosed,
who
already
left
a
comment
so
I
think
we
can
zoom
in
on
the
service
portion
of
it
I've
kind
of
added
in
what
I
found
from
our
blue
hint
so
far
as
well
as
Victor
and
I's
discussion
around
how
backstage
does
the
yaml
registration
so
adding
in
the
kind
of
metadata
here
with
name
description
as
well
as
kubernetes,
namespace
and
flux
resource?
B
I
would
say
that
the
name
is
only
the
metadata.
The
rest
is
spec,
but
only
if
you
want
to
follow
the
kubernetes
API
typical
schema,
which
we
don't
have
to
it's
just
getting
more
and
more
Universal.
C
Well,
one
question:
the
description
mentions
that
there
can
be
links
to
external
pages
and
there's
like
links
to
pages
at
the
bottom
like
how
do
they
relate?
Maybe
that's
just
a
yeah.
A
A
That's
a
good
so
with
them.
We
have
like
the
object,
which
is
the
service,
the
attributes
and
then
the
actions
you
would
take
in
that
service.
I
think
the
actions
area
right
now
is
a
really
really
limited.
Links
is
the
only
kind
of
action
I
know
that
you
would
take
on
this
service,
but
we
should
add
into
that.
If
there
are
additional
things.
Okay,.
A
And
then
a
good
example
is
I've
copied
over
the
merge
request.
The
merger
Quest
conceptual
model,
which
you
can
see
is
really
really
detailed
and
kind
of
loan
out.
I.
Think
we'll
get
to
this
later
on
and
I.
Don't
think
service
should
be
this
complicated
for
the
first
release,
but
if
anyone
needs
like
an
example
of
like
an
existing
conceptual
model,
I've
put
it
to
the
left
of
our
service.
One.
B
So
I
came
up
with
the
read
some
of
these
properties
like
kubernetes
and
namespace
and
flux
resource
and
actually
I,
don't
know
where
the
right
place
for
those
could
be.
So
if
anyone
has
ideas,
basically
the
idea
there
is
to
to
configure
a
cluster
UI
like
we
do
it
today
within
the
environment,
but
it's
within
the
intersection
of
a
service
and
the
environment
and
at
first
my
idea
was.
B
This
is
a
good
idea
to
just
have
it
at
the
service
level,
but
now,
as
I
had
a
second
thought,
it's
like
if
I
have
a
Dev
environment,
I
might
have
a
user-based
namespace
or
something
like
that,
and
that's
why
it's
not
necessarily
part
of
the
service
or
you
can
overwrite
it
and
I,
don't
know
in
the
release,
artifacts
and
the
environment
or
somewhere,
and
that's
how
it
becomes
a
more
specific
to
that
deep
to
a
single
deployment.
Basically,
but
that's
that's.
B
Why
I
did
that
comment,
for
example,
about
kubernetes
that
we
might
want
to
leave
that
out
as
well
in
order
to
learn
more
of
how
these
cross
service
and
environment
interactions
should
play
out.
B
And
what
I
told
yesterday
to
Emily
is
that
I
think
we
should
keep
the
service
really
lightweight
at
first
and
I
expect
much
more
actions
related
to
release
artifacts,
because
there
might
be
actions
that,
like
deploy
to
an
environment,
then
a
deployment
might
have
actions
of
rollout.
B
The
artifact
itself
has
attributes
like
the
who,
who
created
that
artifact.
Then
there
might
be
signatures
as
an
attributes.
B
Merge
requests
so
kind
of
like
a
actually
a
description.
I
would
say,
like
changelog.
B
B
Status
and
rollout
status
and
actually
deployment,
could
have
even
a
status
in
itself
like
like
is
it?
Is
it
running
like,
like
you
know,
yeah,
if
I'm
thinking
more
about
the
future
than
I
could
add
to
Services
the
metrics
queries.
A
It's
in
like
figma,
somewhere,
okay.
B
C
I
wonder
about
the
metrics,
though,
because
if
you
release
a
new
thing
that
may
impact
the
query
right,
because
you
may
report
other
metrics
another
field
or
introduce
something
so
I
wonder
if
that's
not
coming
with
the
yeah
with
the
deployment
kind
of
or.
B
Yeah
I
understand
what
you
say
and
it's
like
the
so
I
I
think
in
a
if
I
look
at
it
from
a
time
lapse
perspective
so
like
like,
then
you
are
correct
that
you
introduce
a
certain
metric
at
a
given
version,
but
from
a
conceptual
point
of
view,
it's
you.
You
query
your
service
and
just
before
that
date
you
don't
have
data
for
that.
Metric
I.
Think.
B
Because
then
it
means
that,
like
you
introduce
a
service,
let's
say
in
version
two:
now
you
are
in
version
99
and
you
repeated
that
service
in
those
98
97
release
artifacts.
So
it's
it's
just
repeating
yourself
again
and
again
to
to
keep
the
metric
there.
B
B
It's
understanding
problem,
it's
just
that
it's
it's
like.
It
adds
extra
noise
everywhere
in
all
your
release,
artifacts.
Instead
of
saying
that
this
is
my
service,
this
is
this
I'm.
Looking
at
right
now,
I.
C
C
C
Yes
exactly,
but
there
it
was
about
the
metadata
and
there
we
came
to
the
conclusion
that
okay
they're
just
now
for
that
case,
which
is
fine
because
nothing
is
broken
per
se,
but
I
think
it's
different
for
the
metric.
Where
you
know
the
numbers
are
still
there
for
the
old
service.
You
could
still
query
the
metric.
C
A
podcast
I,
don't
I,
don't
know
like,
maybe
maybe
it's
like
a
composition,
kind
of
thing,
where
you
could
Define
metrics
for
your
service
and
you
would
basically
kind
of
drag
and
drop.
Okay,
this
this
release
or
this
deployment
can
actually
you
know
it
works
with
this
metric
thing
and
then
you
would
not
duplicate
it
for
every
or
ship
the
metric
query
with
every
release
artifact,
but
you
would
kind
of
tie
them
together
after
or
wait
there
may
be
a
default.
You
know
whatever
engagement
like.
C
Maybe,
actually,
maybe
the
service
should
contain,
like
a
metric
name.
Kind
of
you
know
that
it
says,
like
saturation
or
whatever,
and
the
release
archifact
must
provide
the
query
for
that
named
metric
kind
of
you
know.
Maybe
that's
because
I
agree
to
you
that
the
service
may
have
those
you
know
the
same
metrics
over
and
over
for
all
the
versions.
You
may
introduce
new
ones,
but
you
think
in
the
easiest
case
you
would
just
provide
the
query,
but
the
metric
conceptually
is
always
with
the
service.
B
It
does
I
I,
don't
know
how
complex
we
want
to
make
it
as
we
haven't
built
anything
yet.
B
So
it
makes
sense,
but
like
I,
think
it
will
take
us
many
many
months
for
us
to
introduce
any
kind
of
metrics,
Integrations
and
I'm
sure
that
we
will
know
much
more
by
that
time
about
whether
people
might
might
just
say
that,
like
I
just
want
the
metrics
queries
in
the
release,
artifacts
and
I
don't
want
a
name
in
the
service.
That's
got
populated
and
yeah
so,
but
it
makes
sense.
A
B
C
B
Would
leave
it
as
a
result
if
I
I
think
that
that
what
you
described
definitely
makes
sense,
I,
think
it's
and
and
how
we
do
it,
whether
it's
like
a
different
object
that
you
can
just
reference.
It's
a
different
question:
yeah,
yes,
but
in
the
first
iteration,
actually,
we
likely
won't
have
metrics
at
all.
So.
C
A
B
I
think
the
actions
are
really
not
not
that
this
I
I
can't
I
was
thinking
about
this
even
before,
but
I
just
can't
come
up
with
many
actions
for
for
a
service
like
we
can
have
something
like,
for
example,
when
we
had
to
go
with
Sam
visco.
He
said
that
for
him
primary
Services
about
finding
the
code
and
finding
the
team
who
owns
it,
so
you
might
have
an
action
to
notify
the
team,
which
is
might
be
a
manual
action.
But
you
have
the
details
there:
how
to
notify
the
team
who
owns
that
service.
A
A
And
then
I
think
another
thing
I
had
to
do
into
here
is
we
talked
about
this
yesterday
Richter
but
add
the
relation
so
like
the
one
to
one,
the
one-to-many
into
kind
of
like
service
to
release
artifact
service
to
environment.
All
that,
because
I
think
that's
currently
missing
in
this
and
that's
going
to
be
an
important
aspect.
A
A
Does
anyone
have
any
other
conts
or
questions
on
this,
because,
if
not
I
can
take
this
first
iteration
and
work
with
Pedro?
Who
is
a
designer
who's
done
multiple
conceptual
models
and
we
can
take
this
away
and
edit
it
a
bit
further
I
I.
B
Have
a
question
to
Andrew,
Andre
and
shinya
primarily-
and
you
want
me,
but
we
discussed
this
continuously-
is
that
what
I
see
here
that
we
are
changing
the
current
environments
deployments
and
release
approvals
to
to
this
New
Concept,
where
basically,
the
release
approvals
happens
mostly
in
the
release?
Artifact.
B
We
have
a
deployment,
that's
very
similar
to
the
deployment
today,
except
that
we
made
that
there
would
be
a
real
rollout
action
and
and
the
the
current
status
of
a
rollout
and
the
deployment
should
be
able
to.
Basically,
the
the
query
is
about
a
specific
deployment,
not
about
the
release
artifact
in
the
end
and
I'm
sure
that
you
worked
on
hundreds
of
issues
in
this
domain
likely
met
customers
and
so
on.
B
So
like
any
any
feedback
you
have
in
terms
of
yes,
this
is
something
that
might
fit
better
our
users
or
it's
too
much
structure.
E
Think,
overall,
it
looks
good
and
definitely
towards
what
the
customers
that
do
have
service
oriented
architecture
actually
needs
I
just
wanted
to
add
or
like
resurface
again
that
in
the
long
run,
I
think
it
would
be
beneficial
to
have
a
separate
entity
for
deployment
or
release
approvals.
E
D
B
No
no
I
I,
just
like
I
just
want
to
ask
for
more
details
from
from
both
of
you
on
this
I,
actually
moved
my
my
own
screen
to
the
Mr
conceptual
model,
because
that's
where
Andre
said
that,
like
like
Mrs,
do
you
mean
the
approver
Rule,
approver
Rule
and
co-down
Rule
parts,
or
it's
not
in
this
conceptual
model?
B
E
Okay,
I
think
I
just
add
a
couple
of
notes
here
and
then
pass
over
to
Andrew
it's
just
a
few
months
ago
we
were
discussing
how
we
can
basically
make
the
deployment
approval
process
more
like
useful
for
the
users
who
wanted
and
then,
after
a
few
discussions,
we
realized
that
actually
the
whole
idea
behind
uploading
a
deployment
to
a
certain
environment.
It's
very
close
to
how
we
approve
the
piece
of
code
to
be
merged
into
a
branch,
and
then
we
checked
and
actually
what
we.
E
What
we
have
like
the
process
that
we
have
with
merge
requests
is
actually
very
close
to
what
many
users
also
wants
to
or
like
it
feels
intuitive
for
users
to
to
have
more
or
less
the
same
process,
and
from
this
perspective,
I
think
the
the
conceptual
model
can
be
resembling,
the
one
that
we
have
with
merge
request.
E
It
will
probably
be
much
simpler
because
Mrs
have
a
lot
of
stuff
in
there,
at
least
for
the
beginning,
I
think
it
can
be
way
simpler
than
what
we
currently
have
for
merge
requests,
but
the
whole
idea
that
you
have
a
specific
entity
that
basically
is
in
charge
for
this
gated
Andrew
said
it.
It
just
makes
the
whole
thing
easier
to
reason
about
and
in
the
end
kind
of
closer
representing
the
domain.
I
think.
E
B
D
D
So
in
in
harness,
you
have
like
a
general
purpose:
approval
like
special
job
I
would
say
where
you
put
these
approval
blocks
in
your
pipeline,
and
the
pipeline
cannot
proceed
until
the
approvals
have
been
gathered.
So,
instead
of
being
tied
specifically
to
the
deployment
itself,
it's
it's
more
get
more
access
like
Interrupters
within
the
pipeline
so
like.
If
your
pipeline
creates
a
release,
you
can
have
an
approval
before
the
release
and
then,
if
it
has
a
deployment,
you
can
have
an
approval
for
the
deployment
and
so
on
and
so
forth.
D
Like
way
more
flexible
and
I
think
something
like
that
would
be
interesting
to
explore,
but
I
also
remember
you
talking
about
how
maybe
like
pipeline's,
long-term
or
dead
code,
so.
D
I'm
not
sure
if
we
want
to
add
more
to
that,
but
it
would
yeah,
but
we
gotta.
We
have
to
think
about
how
that
would
work
in,
like
the
flux,
sync
kind
of
environment
as
well,
where
we
don't
have
Pipelines.
B
F
F
So
yeah
a
general
algorithm
is.
F
Creating
architecture
from
scratch,
instead
of
reusing
what
we
have
today
like,
for
example,
environments
and
deployments
typical,
specifically
impairments,
it
has
a
in
a
weird
State
model,
and
then
we
almost
we
are
have
already
agreed
up
on
that.
It's
not
working
in
this
new
architecture,
so
my
guest
telling
me
that
we
should
create
introduce
whole
new
entities
instead
of
using
yeah
the
existing
ones.
F
So,
at
any
rate,
when
user
adapts
this
new
model,
they
have
to
do
something
right
like,
for
example,
introduce
a
service
demo
into
their
Repository.
So
in
that
sense
like
yeah,
it's
not
like.
F
I
I
don't
see
that
I
don't
see
a
value
to
use
the
existing
models,
just
like
start
from
the
service
yaml
and
then
creating
the
appropriate
entities
and
entries
through
there
yeah.
That's
that
would
work
in
a
long
run.
B
B
Up
to
this
minute,
I
thought
that
the
best
iteration
might
be
to
create
some
very
lightweight
service
and
then
move
on
to
this
release.
Artifact
deployment,
environment
interaction,
but
I
can
even
imagine
that
we
actually
start
with
the
release.
B
Artifact
deployment,
environment,
interaction
without
a
service,
or
something
like
that,
especially
now
as
I
see
that
basically,
a
lot
of
the
actions
are
with
the
release
artifact,
but
we,
this
is
for
future
discussion,
but
I
I
I,
hear
what
you
say:
I
hope
that
we
will
be
able
to
come
up
with
ideas
that
we
require
minimal
work
for
existing
users.
B
F
B
F
The
migration
should
work
as
long
as
I
see
the
current
models
because,
like,
for
example,
environmental
deployments
it's
these
are
pretty
much
read-only
entries.
They
would
relatively
easy
to
migrate
away
yeah.
The
important
thing
is
like
we
have
the
right
bucket.
B
A
The
other
thing
I
went
and
did
while
we
were
talking,
is
I
added.
I
was
working
on
the
idea
of
registering
a
service
yesterday,
I
shared
it
with
shinya
and
Victor
already,
but
this
is
something
I've
now
pasted
in
the
bottom
corner
here
that
I
think
might
help
that
we
might
want
to
chat
through
as
well.
B
I
asked
in
the
product
slack
if
the
gitlab
CLI
and
according
to
vs
code
extension,
includes
the
gitlab,
cimo
validation
and
the
answer
is
yes
and
they
just
use
the
same
API.
Actually
so
gitlab
provides
an
API
that
receives
a
yaml
if
I'm
not
mistaken,
and
these
tools
just
send
data
to
that
API.
So
yeah,
I
I,
certainly
agree
with
you.
D
But
it
would
be,
it
would
also
be
nice
to
provide
a
schema
I
think
because
it
gives
not
just
validation
functionality
but
auto
complete
functionality
within
the
editor.
B
F
So
I
see
one
limitation
in
the
Asian,
isn't
a
config
file
that
we
don't
have
a
validation
at
the
interface.
The
code
editor
right
that
because,
like
like
I
said
the
schema
is
defined
in
agent
and
then
we
get
a
poke
that
the
agent
has
to
expose
the
API,
or
at
least
like
a.
F
We
have
to
expose
API
in
rails,
which
communicate
with
agent
to
buy
the
schemer
or
something
like
that,
which
is
a
it
requires
a
bit
of
effort
to
introduce,
on
the
other
hand,
for
example,
like
a
pipeline,
GitHub,
say
yaml
file,
we
have
a
whole
body
that
is
on
Rails
side
so
like.
If
you
want
to
do
something
similar
at
real
site,
you'll
be
really
easy.
F
So,
for
example
like
when
use
a
commits
are
broken
cyber
saml
file,
we
can
show
an
error
message
to
editor
page
like
a.
This.
Is
a
this
key
or
this
value
is
invalid,
or
something
like
that,
whatever
just
similar
to
the
CIA
leader.
B
B
That's
that's
what
I'm
in
there,
but
I
agree
that
it's
slightly
better
to
have
some
random
rupee
I
added
one
more
thing
to
the
Service
as
a
comment
there
yeah
that
one
I
think
then
this
is
based
on
what
Andrew
said
about
about
the
harness
pipeline,
that
it
has
these
steps
and
it's
a
it's
basically
a
well-defined
pipeline
instead
of
a
pre-configured
set
of
functionalities,
and
we
might
have
something
similar
for
for
the
service
definition
or
Timo
might
say
that
they
should
be
part
of
the
release.
B
Artifact
and
I
don't
have
a
strong
opinion
yet
where
it
should
actually
live,
but
basically
a
pipeline
definition
that
that
has
these
things
defined.
As
as
this
thing
steps
and-
and
it
might
be
actually
a
much
better
approach
than
than
coming
up
with
all
the
features
ourselves
and
and
deciding
how
the
user
should
put
them
one
after
the
other.
A
A
Does
anyone
else
have
any
comments
or
feedback
around
this
conceptual
model
so
far,
things
I
should
take
into
account
as
I
build.
C
One
question:
did
the
user
is
only
referenced
there,
because
it's
the
one
that
creates
the
service
but
other
than
that?
There's
no
conceptual
like
relationship
between
the
user
and
the
service.
A
User
already
exists,
I
added
it
in
because
I
think,
based
on,
like
awareness
of
the
owner,
awareness
of
who
owns
this,
we
needed
some
form
of
like
user
connection,
but
usually.
C
The
problem
with
these
kind
of
things
is
you
create
this
with
your
user,
the
user
leaves
the
Org
the
user's
block
deleted
whatever,
and
then
what
happens
to
the
service.
I
think
that
there
is
this
problem
in
several
parts
of
gitlab.
Like
you
know,
pipeline
triggers
is
one
that
comes
to
my
mind
immediately,
but
there's
probably
others
so
yeah
conceptually
I,
don't
think
it.
This
service
relates
to
any
user.
C
A
A
B
D
A
F
Actually,
I
have
a
question
that
really
satisfactory
in
this
case
could
be
different
project
right.
F
C
F
Actually,
we
see
that
sorry,
it's
not
really
sad
Factor
connected,
but
the
this
could
be
in
different
projects.
B
Yeah,
actually,
how
I
see
it
is,
is
really
that
the
release
artifact
is
an
input
to
a
delivery
pipeline
and
and
where
is
that
input
coming
from?
B
F
So,
typically,
a
release
pipeline.
You
mean
that
the
artifact
are
going
through
from
a
lower
environment
to
higher
environment.
Yes,
including
approvals
and
everything.
Okay.
Is
it
necessary
to
be
pipeline,
or
are
you
thinking
about
something
completely
different
thing?
F
B
I'm
saying
that
I
hope
is
that
we
are
discussing
with
some
visco
better
gitlab
pipelines
can
support
CD
use
cases
and
what
are
the
limitations
of
CD
of
pipelines
for
CD,
but
I
hope
that
we
will
be
able
to
lift
those
limitations
and-
and
we
don't
have
to
come
up
with
a
totally
new
automation.
Engine.
F
B
Do
you
have
any
ideas
how
you
like,
how
you
imagine
it
like
like?
Would
you
specifically
imagine
if
it's
something
as
or
that
you
think
it
might
be
easier
to
do
first
or
it
just.
F
I,
don't
know
like
it
could
be
like,
for
example
like
if
you
use,
if
he
heavily
depend
on
flux,
the
it
more
makes
sense
to
style
right,
there's
a
reconciler
and
periodically
checking
the
updates.
F
So,
like
there's
no
points
to
and
then
like
in
this
case,
we
can
fully
use
unleash
the
major
request
approvals.
Like
all
of
the
you
know,
Dev
Futures,
which
is
good
thing
like
if
we
stick
with
cicd
pipeline,
you
give
up
pipelines.
They're
always
like
might
be
a
limitation,
so
at
this
moment
I'm
not
sure
what
the
right
answer
better
yeah,
it's
just
yeah.
It
makes
sense
to
stick
with
flux
or
githubs
in
in
the
terraform.
In.
B
English
because
so
basically.
B
B
That
is
not
public,
yet
they
just
shared
it
with
me,
and
but
we
could
actually
have
a
controller
kind
of
like
a
git
lab
delivery,
controller
or
or
whatever,
and
that
checks
continuously
with
gitlab
whether
it
can
move
on
to
to
do
its
job
and
and
it
has
conditions
that
I
can
deploy
to
this
environment.
When
these
things
are
checked
in
in
the
gitlab
side
and
then
at
the
next
environment,
it
requires
more
things
to
be
checked
and,
for
example,
something
like
that.
Could
work
as
well.
F
Yeah
yeah,
so
I
was
in
the
runway
meeting
and
then
actually
they
were
trying
to
and
switch
to
something
very
different
from
Global
CSD
pipeline.
Just
for
URL
in
this,
maybe
I
can
explain
in
a
different
time
but
yeah
they're
thinking
to
introduce
crd
for.
F
Like
having
a
reconcile
inside
kubernetes
so
like
they
don't
use
pipelines
at
all
yeah,
it's
still
like
a
just
ideal
phase,
but
it's
always
thinking
about
this
way
too.
D
B
D
F
But
so
I
just
want
to
make
sure
that
I
get
back
to
this
diagram
service
environment
deployment
are
all
under
the
same
project
right,
but.
F
Just
wanted
to
point
out
that,
did
you
see
because
diagram
yeah,
I
think
yeah?
That's
explains
all
of
that
entity
relationship
like
one
to
one.
Many
too
many
and
then
I
checked
that
it
looks
good
to
me.
So
yeah
just
wanted
to
shout
out
that.
Thank
you.
Victor
thanks.
A
The
other
thing
I
wanted
to
call
it
is
I'll,
be
at
the
product
get
together
next
Thursday,
so
I
can't
attend
the
design
pairing.
So
if
you
find
use
in
having
another
APAC
version
next
week
would
probably
be
a
good
week
to
do
that.
F
Yeah
I
think
that's
a
good
idea
to
to
have
a
one
more
thing.
Meeting
in
APAC,
all
right
I
was
thinking
that
really
slim
down
the
current
Billow
plane,
somehow
move
forward
even
a
little
little
by
little
yeah
as
a
blueprint.
F
Actually
you
suggest
that
don't
include
too
much
stuff
just
like
go
baby
steps,
so
yeah
like
I,
already
put
the
metadata
into
Adobe
scope
as
Victor
State
and
then
probably
I'll
cut
more
down
to
somehow,
hopefully
like
we
undraft
this
week
or
next
week,
and
then
we
have
a
oh,
probably
can
I
say
about
goal
and
then
maybe
one
more
ux
goal
here
and
the
margin
I,
don't
know,
there's
some
sort
of
this
line
that
I
hope.
F
Hopefully
we
can
merge
the
first
version
in
I.
Don't
know
like
two
weeks
or
three
weeks.
D
A
Well,
thanks
for
the
great
conversation
everyone
I
will
take,
this
conceptual
model
away,
fix
it
up
a
little
bit
more
with
Pedro,
and
we
can
kind
of
go
from
there.