►
From YouTube: 2023-07-12 Delivery team weekly APAC/EMEA
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
A
B
Yeah,
so
I'll
try
and
be
pretty
quick
I
just
wanted
to
give
a
brief
overview
of
where
I've
been
and
what
I've
been
doing,
because
I've
been
pretty
absent
from
a
lot
of
deliberately
related
work
recently.
So
I
think
everyone
kind
of
already
knows
this,
but
for
those
who
don't
I've
been
over
working
on
a
kind
of
incubation
project
called
Project
Runway,
which
is
basically
putting
together.
B
The
skeleton
of
a
internal
developer
platform
for
deploying
Services
inside
of
gitlab
I've
been
working
on
it
with
Igor
and
chance
and
a
few
other
people
around
from
platforms.
B
We
have
basically
gotten
to
the
point
where
we
are
more
or
less
able
to
run
services
within
staging.
We
are
able
to
automatically
onboard
Services
very
easily
and
we
give
end
users
a
very
easy
ability
to
just
drop
in
a
CI
configuration.
Basically,
they
just
include
a
CI
file,
and
then
they
get
this
nice
deployment
process
that
run
deploys
basically
a
container
of
their
choosing.
On
top
of
Google
Cloud
run,
which
is
basically
Google's
managed
container
service.
B
We've
just
kind
of
you
know
getting
things
together
at
the
moment.
We
do
have
a
you
know.
We
do
have
two
customers
now
and
hoping
to
onboard
more
soon.
We
have
a
lot
of
feature
requests.
We've
had
a
lot
of
positive
feedback,
and
it
looks
like
that
this.
So
there
was
always
question
about
you
know
in
terms
of
priorities
for
the
company.
Where
does
this
project
sit?
You
know.
Are
we
going
to
invest
a
lot?
I'll,
invest
a
little
I
think
it's
still
open
to
discussion.
B
What's
going
to
to
happen
exactly,
however,
from
what
I'm
seeing
so
far
definitely
looks
like
that
the
project
is
going
to
keep
going
forward,
it's
not
going
to
stop
and
I
think
there
will
be
continued
investment
for
the
future.
B
So
when
we
kind
of
first
looked
into
this,
you
know
I
said
we
had
a
few
options.
If
we
wanted
something
quick
that
was
competent,
well,
not
competent,
I
guess
complete
out
of
the
box
very
very
quickly,
then
the
best
solution
for
for
us
would
be
to
basically
take
something
off.
The
shelf.
Take
a
credit
card
go
to
one
of
the
many
managed
services
that
two
internal
developer
platforms,
and
that
would
give
us
something
that
would
basically
be
everything
end
to
end
very
quickly.
B
However,
obviously
we
decided
not
to
go
in
that
direction,
which
I'm
really
thankful
for
the
way
we
are
building.
This
is
at
the
heart.
It
is
gitlab.
Basically,
so
we
are
working
on
making
the
git
lab
the
heart
of
the
platform.
B
That's
something
I've
always
been
very
passionate
about,
and
anyone
who's
worked
with
me
and
delivering
those
I've
always
talked
about
that
at
dog
food
in
enhancing
the
products
making
it
the
you
know,
basically
elevating
the
products
to
our
needs
rather
than
just
going
off
and
and
and
trying
to
do
other
things,
and
so
we're
managing
to
do
that
quite
successfully
with
Runway,
and
we
will
probably
continue
to
do
that.
Well,
we
will
continue
to
do
that.
B
Basically,
you
know
showing
the
parts
of
the
product
that
we
need
improved
or
we
need
help
with
and
they've
been
very
receptive
and
it's
actually
really
going
to
kind
of
flow.
The
other
way
as
well
they're,
very
interested
in
helping
have
internal
develop
a
platform
like
features
as
part
of
the
product,
but
we're
actually
moving
quicker
than
they
are
so
I
foresee
in
the
future
that
basically
we'll
be
taking
what
we're
doing
for
Runway
and
putting
it
back
in
the
product
as
well,
and
that's
basically
also
core
to
everything.
B
We
do
we're
trying
to
minimize
the
amount
we're
building
outside
of
gitlab,
where
it
makes
sense
and
try
and
push
as
much
in
the
product
as
possible
in
the
future.
I
think
whatever
happens
to
Runway
and
how
it
develops
and
grows
I
think
it's
going
to
have
considerable
impact,
for.com
and
delivery,
even
if
it
is
say
a
more
isolated
platforms
team
that
works
on
it.
B
That's
not
scalability
or
delivery,
for
example,
because
what
we're
seeing
now
is
a
lot
of
interest
in
you
know
using
Runway
and
the
kind
of
philosophy
it
provides.
Where
you
build
it,
you
run
it
developers
use
it.
They
get
nice
kind
of
smooth
path
for
deployments
and
and
safety
and
everything,
and
so
what
that
means
for
us
in
delivery
is
two
things.
B
It
gives
people
an
option
to
production
that
is
outside
the
monolith,
which
has
massive
ramifications,
and
the
second
part
that
has
even
bigger
ramifications
is
I
see
a
future
where
people
will
be
deploying
and
running
services
in
Runway
and
a
decision
may
be
made
that
they
want
to
actually
ship
that
service
as
part
of
self-managed
releases,
and
that
will
have
very,
very
big
implications,
and
you
know
for
for
I
guess
our
team
right
for
How
We,
Do
self-managed
releases.
What
that
looks
like
how?
What
are
the
rules
around
all
this?
B
It's
still
very
open
to
debate,
I'm,
just
trying
to
think
ahead
in
the
future
of
like,
where
I
see
this
going,
and
what
some
of
the
challenges
that
delivery,
especially
might
see
coming
in
coming
down
the
line,
for
example,
if
for
a
service
is
deployed
in
Runway
and
they
decided
to
go
on
self-manage
release,
do
they
get
kicked
out
of
Runway?
Did
they
have
to
go
back
into
Auto,
deploy?
Probably
not
you
know,
we
have
teams
that,
like
registry
and
Kaz,
who
would
quite
happily
go
into
Runway
as
well.
B
You
know,
even
though
they're
already
in
the
monolith,
and
what
does
that
mean?
Do
we
gate
keep
the
people
out
of
that
we
don't
want
to.
But
you
know
at
the
same
time,
do
we
part
of
the
runway
software
suite?
Do
we
do
something
like
work
with
developers
on
automation
so
that
they
can
define
a
release
that
goes
into
a
self-managed
release
right
and
whether
that's
just
dropping
version
files
so
that
you
know
our
our
package
process
can
pick
it
up,
and
what
does
that
mean?
Where
does
distribution
fit
into
that?
B
So
these
are
all
big
questions,
so
I
do
think
the
project
in
the
future
as
it
as
it
moves
on
is
going
to
have
obviously
quite
a
big
impact
on
delivery,
which
is
why
I'm
I
feel
very
lucky
to
be
involved
and
I.
Think
that's
why
they
did
want
someone
from
delivery
involved.
B
Yeah,
that's
pretty
much.
It.
B
Sure
sure
so
the
goal
is
that
once
we
kind
of
fully
develop
Runway
and
we're
still
still
got
a
bit
to
go,
but
once
we
have
the
the
platform
kind
of
at
a
point
where
well
not
fully
developed,
but
you
know
we
will
put
the
platform
itself
through
a
Readiness
review
and
that
Readiness
review
will
not
only
cover
the
platform
itself,
but
also
like
services
that
are
going
through
it.
B
And
the
idea
is
if
you're
deploying
a
service
through
Runway,
then
you
don't
need
a
Readiness
review
or
probably
just
a
very
much
more
cut
down.
Readiness
review
right,
like
the
idea
of
these
kind
of
tools
and
processes
is,
is
I'm
not
going
to
say
the
word
speed,
but
it's
smoothness
right
and
it's
a
two-way
street.
This
isn't
just
like
you
can
do
whatever
you
want.
We
have
a
very
strict
set
of
rules,
boundaries.
B
B
The
platform
in
the
future
may
expand
to
support
that
probably
will
but
yeah
what
that
means
is
that
when
you're
on
boarded
into
Runway
within
a
couple
of
minutes,
you
get
a
staging
and
production
environment
and
from
the
time
you
commit
your
first
piece
of
code
and
you've
included
the
runway
stuff
that
you
need
to
do.
You're
up
you're
running
you're
in
you've
got
a
a
deployment
in
staging
the
deployment
and
production
you're
getting
metrics
you're
getting
you
know,
safe
rollouts
rollbacks.
B
You
get
traffic
control
yourself,
all
of
that
kind
of
good
stuff.
We
kind
of
give
we're
looking
at
as
an
example
as
well
like
this
week,
I'm
looking
at
geographically
distributed
deployments
so,
for
example,
deploying
the
same
service
across
three
different
geographic
regions
and
then
using
you
know:
Google's
global
global
load,
balancer
to
Route
traffic
intelligently
to
the
closest
location
that,
for
example,
had
huge
ramifications
for
some
services,
and
it's
not
very
important
to
others.
B
The
one
the
service
that
we
are
running
at
the
moment
is
the
AI
Gateway,
so
the
code
suggestion
stuff
where
we
are.
You
know
working
with
that
team
on
running
that
at
the
moment,
so
having
containers
or
services
that
run
very
close
to
you
and
is
someone
from
Australia
I
noticed
this
very
much
helps
the
user
experience
right.
So
something
like
that
where
you're
typing
and
you're
trying
to
get
you
know
some
responses
back
in
your
IDE
quickly.
You
know
every
little
bit
helps.
B
B
So
the
last
thing
I'll
close
off
down
with
is
so
the
other
kind
of
implication
it
will
have
for
delivery
should
be
in
the
back
of
our
minds.
Is
I
mentioned
this
to
Marin,
to
mention
up
to
the
management
chain,
people
like
York
and
so
forth,
which
I
think
at
that
level,
they're
starting
to
kind
of
understand
and
I.
Think
everyone
here
understands
this.
This
premise
I'm
about
to
say
right
for
so
long,
gitlab.com
like
we,
we
everything
we
do
is
based
off
the
premise
that
we
run
gitlab.com
like
our
customers
run.
B
Gitlab
just
did
a
bigger
scale
right.
You
know
we
deploy.
We
say
it's
on.com,
it's
good.
We
cut
that
release
and
we
change
it.
Self-Managed
customers,
as
the
company
has
had
this
appetite
for
things
outside
the
monolith
and
to
be
fair.
A
lot
of
these
services
will
not
go
to
customers.
The
goal
is
for
services
not
to
go
to
customers,
but
as
we
start
to
change
that
model,
that
has
huge
ramifications
on
a
lot
of
assumptions.
B
We
make
right
like
a
lot
of
the
assumptions
we
make
around
our
tooling
and
our
processes
based
off
that.
So
we
need
to
be
careful,
and
we
need
to
be
aware
that
we
are
changing
some
foundational
assumptions
that
gitlab
runs
on
and
and
delivery
runs
on.
It's
not
mean
we
can't
do
it,
but
it
does
mean
that
so
things
that
it
become
more
important
testing
our
environments,
management
release.
Environments
is
a
you
know.
The
project
I
was
working
on
which,
unfortunately,
now
is
just
kind
of
left.
B
Get
the
gitlab
environment,
toolkit
right
and
those
reference
architecture
stuff,
making
that
more
automatable,
which
is
like
what
the
the
dedicated
team
is
doing
like
all
of
that
work
becomes
more
and
more
important
right,
because
we
need
to
build
off
the
we
need
to
expand
the
ways
we're
looking
at
deploying
and
testing
gitlab
in
ways
that
are
close
to
customers.
If
gitlab.com
no
longer
matches
that
100.
B
Exactly
I
mean
yeah,
but
that's
you're
right,
that's
an
absolute
another
Pro,
that's
the
same
problem
right
once
we
introduce
cells,
I,
don't
see
any
self-managed
customer
installing
and
like
spinning
up
multiple.
Maybe
they
do
I,
don't
know,
but
sales
is
another
thing
where
we're
going
to
start
to
see,
gitlab.com
break
away
from
that
model
and
and
what
I
said
I
think
it's
fine.
Everyone
agrees
it's
time,
but
for
us
here
our
own
delivery.
I
know
we
rely
a
lot
on
that
idea.
B
B
C
Yeah,
just
I
saw
that
message
in
slack
and
thought
might
be
worth
just
having
the
conversation
since
everyone's
in
the
room
on
the
istio
free
stuff.
B
A
A
Green,
do
you
wanna
give
us
a
view
of
we
think
about
pre
needed
to
be
reverted
before
Oh.
B
Basically,
pre
is
kind
of
like
our
first
stop
right
when
we
need
to
make
changes
to
staging
on
production
so
like,
for
example,
I
got
a
merch
request.
No,
we
got
a
merge
request
today
to
change
the
the
scaling
of
sidekick
to
to
keeda
or
something
right
like
we.
We
need
to
do
that
in
Pre
first,
so
we
can
do
that
and
validate
that
before
we
do
staging
in
production.
It's
just
kind
of
like
a
it's,
an
extra
validation
environment
that
is
separate
from
the
ones
that
are
touched
by
by
Auto
deploy.
B
So
it's
important
that
environment
matches
power,
staging
and
production
are
deployed
because
there's
a
lot
of
changes
that
people
do
like
like
a
good
one
was,
you
know,
I
I
saw
come
recently,
was
like
changing
object.
Storage
configuration
like
it's
stuff,
related
to
changing
the
tooling
or
automation,
or
the
setup
that
we
have
for
our
environment.
So
we
can't
just
kind
of
like
if
we
take
that
away.
B
I
like
on
Monday
I,
have
to
do
the
chart
bump
and
I
need
to
be
able
to
do
that
in
Pre
and
run
QA
against
pre,
and
that's
the
important
thing
as
well
right.
All
of
the
automation
we've
built
in
gitlab
com
is
there
for
a
reason.
I
haven't
been
following
the
the
work
going
on
with
system
closely
but
from
where
I've
looked
I've.
Seen
no
addressing
of
that
problem
like
the
fact
that
the
workflow
we
have
and
get
takes
workloads
gitlab.com
needs
to
be
preserved.
B
It
can't
just
be
thrown
away
like
so
well
I'm,
so
I
I,
don't
know
what
what
we're
trying
to
do
with
this
pre-to
or
anything
I
have
no
idea,
but
pre
needs
to
stay,
and
we
need
to
keep
it
in
like
the
workflow.
So
we
can
make
changes
to
all
environments
and
their
QA
and
they're
rolled
out
like
cluster
by
cluster
I.
Guess.
D
I
I
can
comment
on
that.
If
you
hear
me
so
the
reason
why
we
switched
spree
to
P2
cluster
is
that
the
the
currently
we
have
an
instance
that
it's
like
the
traffic
managed
by
istio
and
we
have
instance
running
on
pre-to
cluster
as
well
and
in
order
to
configure
the
instance
properly
like
all
routine
rules
and
etc,
etc.
D
We
need
to
have
this
instance
to
respond
to
the
proper
URL,
not
like
a
cluster
long
y
to
URL
and
since
spinning
up
new
and
and
this
and
this
pre-to
cluster
is
also
connected
to
pre-data
plane
so
like
stuff
that
it's
running
on
on
the
cluster
is
stateless
and
it's
connected
to
the
radius
and
and
postgres
instances
of
pre-cluster.
D
So
therefore,
like
splitting
and
separating
this
might
and
creating
a
new
data
plane
for
new
cluster,
we
didn't
know
how
much
time
it
would
take
to
do
that.
And
that's
why
I
just
like?
Okay,
let's
temporarily,
switch
a
record
to
points
to
new
cluster
in
order
to
make
it
working.
But
since
yesterday
we
kind
of
expanded
the
scope
little
bit
I
and
and
wait
wait
a
second
like
and
another
like
the
trigger.
D
Why
I
did
that
I
I
synced
with
systems
team,
and
we
decided
that
we
are
using
pre-environment
only
when
we
have
release
right
and
and
Amy
suggested,
to
contact
quality
team
and
ask
them
how
they
do
they
use
pre,
they
I
think
with
them.
They
told
me
that
they
are
using
pre
a
week
before
release
and
the
rest
of
the
time.
Pre
is
kind
of
calculating
loops
and
doing
nothing.
E
Sorry
I
said
this
is
only
off
of
the
story,
because
the
other
purpose
so
quality
can't
know
and
but
basically
infrastructure.
This
is
what
Graeme
was
telling
that
that
environment
is
done
is
made
also
for
testing
configuration
management
changes
in
general.
So
it's
something
that
is
close
to
production,
and
so,
when
someone
wants
to
test
configuration
change,
they
do
this
on
pre
so
that
they
can
test
it
without
affecting
staging
or
any
other
thing
that
is
in
the
critical
part,
to
the
release.
E
D
That
was
not
communicated
with
me
properly
and
I,
going
to
switch
again
like
I'm,
going
to
switch
pre
back
to
the
to
to
to
the
state
that
it
used
to
be
yesterday.
It
was
yesterday,
and
there
are
still
something
needs
to
be
done.
Apart
from
this
work
on
on
pre-environment
and
afterwards,
I
I've
done
that
I
will
think
how
to
do
that
properly.
Like
I
think
this
better
way,
the
better
way
would
be
to
separate
data
playing
to
have
like
a
dedicated
environment.
For
for
for
this
work.
B
I
think
so
so
yeah
look
I,
understand.
I
I,
see
I,
see
now
where
the
confusion
comes
in,
because
yeah
that
pre
has
two
customers.
I
guess
so
there
is
I
mean
two
customer
groups,
there's
definitely
the
quality
and
delivery.
As
a
customer
group
around
the
release
process,
which
you
pointed
out,
you've
got
the
timings
for
and
everything
that's
great,
but
yeah
it's
a
bit
of
a
more
invisible
customer
Group,
which
is
developers.
B
So
we
have
developers
and
infrastructure
people
using
it
as
a
you
know,
as
a
means
of
safely
rolling
out
configuration
changes,
so
it
is
unfortunate.
I
think
we
have
kind
of
gotten
ourselves
into
a
bit
of
a
unfortunate
pickle
in
terms
of
like
what
do
we
do,
because
we're
kind
of
I
I
see
what
you
know.
I
understand
what
you're
trying
to
do
and
they're
like
I'm,
trying
to
understand
I'm,
trying
to
think
of
I'm
trying
to
think
of
how
we
can
do
both
and
it's
becoming
it's
really
hard.
B
I
I
can't
think
of
a
way.
Besides,
maybe
it's
time
to
do
a
separate
data
plane
similar
to
which
should
just
be.
B
It
should
just
be
a
database
I
can
give
you
some
hints
on
how
to
see
the
data
and
stuff
as
well
once
it's
running
and
and
the
QA
stuff,
but
it
should
just
be
a
cloud
SQL
database,
similar
to
what
we
already
have
and
I.
Don't
know
what
we
do
for
redis
I
think
it
might
be
Memory
store.
Yes,
it
is
memory
store,
so
it
should
probably
just
be
a
reusing
of
some
of
the
terraform.
B
We
have
in
that
environment
to
spin
up
more
copies
of
that,
and
then
you
can
just
kind
of
connect
it
to
that
and
then
hopefully
you
will
also
need
to
like
enable
some
of
the
database
syncing
tasks
in
the
chart
and
stuff
like
there's
a
few
things.
You'll
need
to
do,
but
hopefully
it
wouldn't
be
too
difficult.
B
It
is
unfortunate
because
if,
if
the
testing
was
short
enough,
we
could
probably
just
do
some
messaging
and
kind
of
get
away
with
it.
But
honestly
it
sounds
like
if
you've
got
to
be
routing
and
you
want
to
have
a
good
amount
of
time
to
test
stuff
and
not
feel
like
you're
rushed
and
everything,
maybe
spending
a
bit
of
time
to
do
that.
Then
you
get
all
the
flexibility
you
want
and
then
you
don't
have
to
worry
about
anything.
Maybe
that
is
the
easier
way.
D
Yeah,
like
the
idea
of
separate
data
plane,
was
flying
around,
but
the
the
thing
is
that
no
one
knew,
how
long
is
it
gonna
take
and
the
end
of
the
quarter
is
just
around
the
corner.
That's
that's
the
problem,
so
I'm
I'm
going
to
switch
it
back
today,
like
after
the
meeting,
and
we
will
see
well
I
will
start
doing
something
else,
but
then
we
will
see
how
to
how
to
spin
up
the
the
new
data
plane.
Maybe
we
also
need
to
rename
the
environments
not
pre-call
it
like
a
Something
Something.
B
Different
yeah
that
shouldn't
be
too
difficult,
see
if
you've
got
an
if
you've
got
an
issue
somewhere
about
that
tag
me
on
it,
because
I've
got
some
notes
on
like
how
you
like
how
you
sync
the
data
but
like
how
you
make
sure
it's
running
the
database
migration
tasks
and
like
I,
can
give
you
some
hints
on
how
to
make
sure
the
data
plane
gets
populated
and
also
some
pointers
onto
the
data
stores.
You
need
I
think.
D
Yeah,
we
don't
have
an
issue
because
we
decided
not
to
do
that
right
now
and
think
about
this
next
quarter.
But
if
we
have
to
do
that
now,
then
I
will
create
an
issue.
Obviously.
A
E
Isn't
that
issue
just
the
flip
side
of
19414,
which
was
proposing
creating
something
dedicated
for
release
candidate?
Oh.
C
B
A
Okay
and
you've
been
your
point
about
adding
information
hours
and
three
reason
why
I
used
to
I
think
it's
a
very
good
point.
So,
let's
document
it
in
our
documentation.