►
From YouTube: 2022-06-06 Delivery team weekly EMEA/AMER
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
Well
then,
let's
rock
it
out
today
welcome
matt
how's
it
going
john
yeah,
oh
good,
thanks
how's
everyone
doing
very
well
good,
we'll
do
introductions
here
at
the
end.
Let's
go
ahead,
get
through
the
discussion
items,
but
firstly
an
announcement.
We
do
have
family
friends
day
scheduled
on
the
24th.
If
you
plan
on
taking
that
out,
please
make
sure
that's
noted
inside
of
your
pto
ninja
thingamabob
discussion
items
recently.
A
I
think
myra
you
were
the
release
manager.
When
this
came
up,
we
had
an
issue
with
the
release
instance
and
you
had
no
ability
to
troubleshoot
hypothetically.
This
should
now
be
resolved,
so
it's
just
the
same
way.
You
would
log
into
the
rails,
console
we're
going
to
log
into
the
release.
Instance
via
ssh
all
team
delivery.
Engineers
should
have
this
capability,
so
this
is
effectively
a
new
baseline
entitlement
that
is
being
added
to
our
capabilities
now.
A
So
at
some
point
we
should
try
to
validate
that
this
works,
but
otherwise
all
the
moving
pieces
should
be
in
place.
I
know
I've
already
got
access
to
it
because
I'm
an
sre,
so
I've
already
had
this
access
through
other
means,
but
I
think
it'd
be
wise
if
maybe
alessio
or
myra
you-
and
I
could
work
together
to
make
sure
that
you
could
log
into
the
release
instance
and
such
so.
A
We
could
get
rid
of
bullet
point
b
because
I
saw
myra
struggling
and
I
just
thought
it
was
funny
because
ahmad
neither
one
of
our
managers
in
vlad
is
gone.
I'm
not
really
sure
how
to
address
camera
proxy.
B
B
Okay,
so
I
was
looking
at
the
how
the
week
went
in
terms
of
things
that
we
deployed
packages
that
we
created-
and
I
was
comparing
this
with
what
we
saw
at
the
beginning
of
the
last
week
and
what
was
the
pain
coming
from
the
week
before
so
there
is,
I
put
a
couple
of
screenshots,
so
we
had
the
security
release
and
but
basically
what
we
see
here
is
that
as
well,
this
time
by
the
end
of
the
week,
we
started
going
well,
we
had
five
six
deployment
a
day
and
this
is
reflected
in
the
number
of
wasted
packages,
the
yellow
line
which
goes
close
to
zero,
so
sometimes
one
sometimes
zero,
and
I
mean
this
was
great
to
see,
because
if
some
let
me
share
my
screen
so
that
we
can
see
the
same
thing
together
for
a
couple
of
seconds.
B
That
was
a
different
story.
This
is
when
we
had
a
problem
with
the
family
and
friends
day
and
tagging
stuff
that
never
got
deployed.
So
this
is
where
we
want
to
be
and
yeah.
This
is
where
we
don't
want
to
be
another
interesting
point
that
I
noticed
looking
at
these
numbers.
B
Let
me
go
back
here,
which
we
see
better
so
someone
this
morning
somewhere
in
this
morning,
picking
twitter,
employee
label
to
something-
and
that's
reflected
here,
because
we
are
usually
we
do
better,
but
now
we
are
wasting
more
packages,
so
I
mean
this
is
already
a
fact
that
everyone's
in
release
management
knows
that
speaking
to
or
to
deploy
with
the
current
schedule
is
just
yeah.
B
Let's
say
it's
a
waste
of
time,
because
the
packages
are
close
enough
to
having
the
next
package
ready
for
promotion
more
or
less
when
the
previous
one
completed
the
production
rollout.
So
if
someone
thinks
that
hey,
they
have
something
important
to
deploy,
they
add
the
picking
to
after
employee
label,
but
it's
outside
of
any
incident.
There's
no
real
involvement
with
release
managers.
B
The
package
gets
lost,
I
mean,
maybe
we
promote
it.
It
depends
on
when
it
came
to
us,
but
usually
it's
just
extra
time
spent
in
packaging
waiting
and
doing
stuff,
and
then
it
will
overlap
for
sure
with
something
else
and
yeah.
That's
the
fun
fact
of
the
day.
C
B
Okay,
that's
a
good
point,
so
I
was
thinking
I
was
rethinking
some
of
the
of
the
tagging
strategies
that
we
started
discussing
one
year
ago,
even
more
that
I
would
rather
prefer
just
to
remove
peak
into
her
to
deploy
then
going
because
let
me
try:
okay,
that's
a
bit
of
a
moonshot,
but
right
now
we
have
a
schedule
which
is
six
times
each
day
more
or
less,
and
this
creates
an
auto
supply
branch.
B
Then
we
have
another
schedule,
which
is
every
15
minutes.
Take
a
look
at
the
status
of
the
current
auto
deploy
branch.
Is
it
green?
Is
it
after
the
last
known
package
tag,
and
then
there
is
another
schedule
which
is
take
a
look
at
the
status
of
the
emergent
pipeline
if
something
is
labeled
with
picking
two
to
deploy
peak
it
into
the
ultimate
branch.
Now
these
three
things
are
just
madness,
because
what
often
happens
is
that
someone
that
you
add
the
label
it
gets
picked
on
an
autopilot
branch,
then
the
new
one
is
created.
B
So
the
thing
never
is
never
tagged,
or
I
mean
the
the
making
things
right
with
this.
Three
independent
schedule
is
really
hard.
So
what
I'm
thinking
is
that
we
probably
want
to
have
just
one
schedule
which
says:
is
there
a
need
for
a
new
package?
This
is
open
to
a
discussion.
What
does
it
mean
to
have
a
need
for
a
new
package?
So
don't
don't,
then?
No,
let's
not
consider
that
for
a
moment.
B
So
if
that
pick,
the
latest
master
green
branch
and
tag,
if
not,
is
there
something?
So
basically
that's
the
point
right,
so
I
don't
want
to
go
down
with
this
street
route.
But
just
do
I
need
to
deploy.
Is
something
ready
to
be
packaged?
B
Yes,
then,
tag
from
master
and
then
something
we
can
build
on
top
of
that
is
the
equivalent
of
auto
deploy,
which
is
do
not
package
anything
without
this
sha,
which
means
we
are
in
an
incident.
We
have
a
fix,
the
fix
is
merging
to
master.
B
Then
we
say:
that's
the
next
thing,
nothing
before
this
point
in
time
can
get
packaged
and
deployed,
and
this
is
much
much
simpler
than
the
current
approach
when
all
those
things
are
moving
and
we
end
up
creating
a
lot
of
branches
that
triggers
new
pipeline
that
are
just
creating
noise,
because
if
something
is
merged
in
master
already
had
his
own
pipeline
run.
But
now
we
do
wait
a
lot
of
time
when
we
peek
and
we
have
to
wait
for
the
result
of
the
pipeline
on
master.
B
C
Yeah,
I
think
there
are
several
areas
of
improvement
there.
It
will
just
worry
me
about
when
we
want
to
deploy
a
bug,
fix,
isolated
way
and
in
a
quick
matter.
If
we
remove
the
peak
into
the
auto
deploy
and
we
build
from
master
and
we
cut
the
branch
from
master,
that
would
mean
that
the
bug
fix
it
will
be
packaged
along
with
other
changes
and
not
isolated,
which
might
not
be
ideal
if
we
are
in
an
incident
and
we
want
to
deploy
just
that
change.
Yeah.
B
But
this
is
what
basically
everyone
is
doing,
so
we
still
have
the
locking
feature.
I
think
that's
the
way
to
go.
If
we
want
to
do
something
like
this,
so
let
me
try
so
for
those
who
are
not
familiar,
I'm
sorry,
matt!
If
you
don't
follow,
you
can
ask
questions
but
I'll
try
to
explain
this
so
right
now
we
say
search
something
green
branch
off
and
then
follow
this
branch
until
it's
time
to
just
to
create
a
new
one.
B
This
is
how
it
works
today
right,
so
we
can
pick
things
into
this
out
supply
branches
or
not.
If
there's
nothing
to
pick.
B
What
I
would
like
to
do
is
the
opposite
when
we
say
search
something
green
tag
and
move
on,
but
we
can
still,
we
can
still
use
the
auto
apply,
locking
features
so
right
now
with
this
new
word,
the
ultimate
by
branch
is
master,
but
if
we
want
to
stop
because
we
want
to
deploy
a
fix
in
isolation,
we
branch
off
from
master
from
the
last
deployment
and
we
lock-
and
we
can
write
a
chat
ups
command
for
this,
so
that
we
can
see
that
the
the
right
now
we
have
chat,
ops,
ram,
auto
deploy
lock
name
of
the
branch,
and
this
could
just
be
I'll
supply
lock
without
the
name
of
the
branch.
B
This
will
can
search
for
the
last
deployment,
find
sha
branch
off,
create
a
whatever
random
name
for
it
and
lock
to
it,
and
so
we
can
pick,
but
the
rather
do
this
manually
as
a
release
managers
than
just
having
all
those
schedules,
because
I'm
still
doing
this
manually.
If
I
know
that
something
is
ready,
I
will
just
run
the
the
scheduled
pipeline
manually
because
I
don't
want
to
wait.
Whatever
is
15
minutes
for
that
schedule.
Five
minutes
for
the
other
one,
that's
I'm
already
hands-on,
so
I
just
prefer.
I
can
do
this.
It's
fine!
B
If
I
can
do
this
with
shadows,
but
I
mean
the
the
ui
already
has
the
the
the
control
for
picking
merge
requests
into
a
branch.
So
we
can
just
use
that
one.