►
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
Okay,
so
well,
thank
you
for
taking
the
time
for
this
call.
The
purpose
of
it
is
to
is
for
me
to
understand
how
do
you
see
the
deployment
and
the
release
process
from
your
point
of
view
as
an
italian
team
member,
because
I
am
aware
of
how
it
works
from
the
other
side
from
the
delivery
side,
but
I
want
to
understand
if
the
process
is
as
effective
for
you
as
as
it
is
right
now
for
my
team.
A
So
I
have
a
couple
of
questions
set
on
the
agenda
to
get
us
started
and
the
first
ones
are
related
to
the
deployment
like
for
you
as
an
italian
developer.
What
is
the
usual
process
that
you
follow
to
deploy
a
change
into
gitlab.com.
B
A
merger
quest
gets
merged
at
some
point,
the
get
league
server
version
gets
updated
on
gitlab.com
repository
and
then
everything
at
least
from
ours
perspective
seems
to
happen
automatically.
So
in
most
cases
everything
is
is
pretty
good
and
I
think
we
totally
cannot
complain
about.
A
C
Okay,
so
that.
B
Well,
yeah,
obviously,
when
the
when
the
gilly's
server
version
file
not
gets
merged,
that
merge
request
that
it
gets
stuck
for
some
reason,
then
it's
usually
not
something
we
we
closely
have
pay
attention
to.
So
it
can
take
a
long
time
before
we
actually
see
that
it
gets
stuck,
and
then
we
we,
inter
we
do
an
intervention
on
that.
So
that's
that's
really
like
a
pain
point
for
in
that
perspective
and
yeah.
On
the
other
hand,
I
think
we
also
have
like
the
giddily
alerts
channel.
B
It
called
and
that
that
that
gives
notification
about
deployment
to
each
environment
and
it's
often
not
really
there's
a
lot
of
noise
in
there.
So
it's
hard
it's
easy
to
miss
when
something
is
not
going
right.
B
Also,
I
always
forget
where
I
should
be
looking
if
the
pipeline
fails,
because
I'm
not
sure
if
there's
a
direct
link
to
where
you
can
see,
what's
happening,
why
the
deploy
is
failing.
So
those
are
like
two
pain
points.
In
my
perspective,.
B
C
A
B
Is
it
actually
like?
I
really
like
the
fact
that
we
in
each
merge
request
you
can
see
on
which
environments
are
affected
by
that
workshop?
So
it's
really
nice
easy
to
see.
Even
merch
request
is
deployed
to
an
environment
which
is
really
great,
a
very
great
feature.
That's
for
dark,
footy.
A
You
mean
the
merch
request
that
updates
the
italian
file
in
the
gitlab
repo.
B
A
C
So
probably
the
way
you
visualize
deployments.
A
And
the
way
you
get
notified
to
if
a
merch
request
file
on
gitlab
will
be
some
sort
of
the
pain
points
that
you
are
daily.
You
are
dealing
in
a
daily
basis
right.
A
Yeah,
so
I
am
trying
to
summarize
what
are
the
pain
points
that
you
are
struggling
with.
One
of
them
will
be
the
way
you
visualize
deployments
through
this
italian
alerts,
channels,
which
is
not
very
specific,
not
very
descriptive,
and
the
other
one
will
be
when
you
get
notified
when
a
merch
request.
A
The
merchant
quest
that
updates
the
gitlab
server
version
on
the
gitlab
repo
failed,
because
there
isn't
much
you
can
do
about
it
and
on
the
last
one
I
do
think
it
is
a
bit
painful
for
you,
because
that
merchandise
is
subjected
to
broken
master
failures
that
are
completely
unrelated
to
your
work
or
to
flucky
failures,
because
we
have
some
of
them.
So
if
they
fail
well,
the
merch
chocolates
pipeline
fails
and
the
merge
requests
cannot
be
merged.
So
I
guess
that
slows
down
a
bit
the
way
it's
a
little.
B
Yeah
yeah,
I
I'm
a
little
bit
used
to
to
the
broken
master
guidelines
for
the
gitlab
rails
repository,
but
most
most
many
of
the
people
in
our
team
are
not
obviously
so
yeah.
It's
really
hard
for
them
to
like
investigate,
what's
happening
and
also
like
yeah
all
the
tests,
you're
running
gillard
rails
with
the
new
version
of
gidley,
and
that
I
guess
today
I
had
a
really
nasty
issue
that
that
changing
hitley
made
something
breaking
gitlab
rails.
B
C
B
Yeah,
that's
the
thing
with
an
integration
test.
Of
course,
it's
not
always
easy
to
to
find
the
calls
yeah.
A
B
C
A
A
Having
participated
in
some
italy
incidents
in
which
yeah
the
problem
was
that
italy
got
updated
and
somehow
was
not
compatible
with
the
way
rails
is
handling
things,
and
then
italy
needs
to
be
reverted.
But
in
that
case
the
process
is
a
bit
slow
because
first,
we
need
to
revert
the
the
version
update
and
then
we
need
to
redeploy
it,
and
although
it
is
easy
to
do
it,
it
takes
time
it
takes
like.
B
B
B
Well,
we
did
it
once
that's
right
and
then
then
you
have
to
somehow
stop
the
the
auto
the
ball
to
create
these
merch
requests
and
then
yeah.
Then
you
have
that
issue.
Obviously.
A
Yeah,
it
is
very
manual
and
I
I
also
think
the
fact
that
you
don't
have
access
to
that
pipeline
schedule,
the
one
that
creates
the
merge
requests.
It
also
puts
a
dependency
or
not
because
you
need
us
to
like
re-enable
the
task
once
the
fix
has
been
merged
into
master.
So
you
can
pick
that
one
and
then
deploy
it
so
yeah.
B
Yeah
in
our
in
our
pipeline,
we.
A
B
Manual,
step
to
to
run.
A
B
Pipeline
in
gitlab
rails,
so
in
the
merchandise
before
we
merge
it,
but
it's
not
very
often
you
used
also
because
of
the
reasons
you've
just
been
since
about
that
tests
can
be
flaky
and
stuff
that
that
always
feels
like
sometimes
false
positives.
A
C
A
Yeah,
I'm
curious
about
that
because
it
is
the
gitlab
pipeline
or
the
package
of
q,
a
that
kind
of
tests,
gitlab
basic
functionality
like
issues,
merchandise,
milestones,
pipelines,
etc,
but
I'm
not
sure
until
what
extent
that
would
cover
like
detailed
integration
into
it.
B
Yeah,
that
might
help
to
have
a
q
a
that
that
actually
tests
things
that
we
know
gidly
might
break.
B
I
haven't
been
considering
this
yet
so
I
didn't
really
think
it
true.
B
Yeah
we
need
some
safeguard,
like
sometimes
these
rails
tests
on
the
gitlab
rails.
Projects
really
stop
us
from
doing
really
silly
stuff.
So
so
we
need
those
those
those
guard
rails
in
some
other
way,
then
I
would
say
yeah
other
than
that.
I'm
I'm
wondering
if
that
gives
issues
or
makes
it
harder
to
to
bundle
a
package
for
self-managed
users
that
that
also
is.
B
B
A
B
A
Our
side,
sometimes
when
we
are
deploying
italy
or
gitlab
changes,
and
we
have
an
incident
and
it
turns
out
it-
was
caused
by
a
italy
change.
It
is
difficult
for
us
because
then
we
need
to
go
and
try
to
find
someone
from
your
team
available,
because
we
don't
really
know
how
to
fix
that
right.
We
even
know
that
the
problem
is
italy,
but
I
don't
know
how
to
fix
it
and
then
that
put
that
sort
of
puts
the
italian
team
in
the
spot,
because
we
need
someone
available
to
fix
it
to
unblock
the
delivery
work.
A
So
what
we
are
trying
to
do
is
to
remove
those
dependencies
to
make
every
group
stage
the
owner
of
their
own
deployment
pipeline,
and
it
will
be
the
delivery
teamwork
to
define
like
the
pipeline
steps
and
the
pipeline
requirements
like
it
needs
to
be
packaged.
It
needs
to
have
proper
qa,
it
needs
to
be
deployed
in
a
safely
manner,
and
it
needs
to
be
able
also
to
be
rolled
back
in
case
something
happens,
but
then,
to
put
it
bluntly,
let's
just
imagine
when
something
gets
merged
into
master.
There
is
like
a
button.
A
It
is
a
very
long-term
goal
and
I
think
the
italian
component
is
one
of
the
most
complex
and
intertwined,
because
there
is
like
spread
in
many
different.
I
don't
know
stages
in
our
deployment
pipeline,
so
still
is
something
that
we
want
to
do
not
only
for
italy
but
for
every
other
github
component,
like
pages
cars,
etc.
B
Yeah
yeah,
but
then
you
have
to
be
a
lot
more
aware
about
about
backwards
and
forward
compatibility.
I
guess
like
it
was
bf2
backward
or
forward
one
version
to
make
sure
that
it
always
keeps
working.
A
A
B
With
grpc,
that
should
not
be
an
issue
like
it
should
cover
that
case,
like
if
one
of
the
boat
ends
has
a
newer
message,
version
that
the
other
one
does
then
at
least
not
mesh's
level
that
that
should
just
work
but
like
what
are
the
impacts
for
fields
that
the
rails
sends
and
get
killed.
Not
like
not
knows
about,
or
are
there
any
problems
that
that
could
give?
A
Yeah
for
sure
it's
something
that
I
have
in
my
head,
that
I
still
don't
have
a
clear
answer.
It
might
as
well
be
that
we
can
update
both
components
at
the
same
time
now,
but
I'm
also
not
quite
certain
and
just
one
last
question
that
comes
to
my
head
about
the
italian
deployments.
A
What
do
you
do
or
how
do
you
guarantee
backwards?
Compatibility,
for
example,
for
italy
if
you
deploy
something
and
then
another
thing
that
might
not
be
compatible
with
your
last
feature
or
with
the
last
commit
that
got
deployed,
do
you
have
like
an
automatic
check
to
prevent
those
situations,
or
is
it
just
more
like
in
the
developer
and
maintainers
to
try
to
see
like
oh,
this
thing
might
break
something,
so
we
need
to
wait
for
another
release
or
something.
B
A
To
the
release
process-
and
I
think
that
might
be
a
bit
more
obscure
on
your
side,
but
have
you
followed
or
have
you
performed
recently
like
a
batch
release
from
italy
or
a
security
release.
B
I
haven't
done
myself.
I
reviewed
something
on
that
on
that
on
a
patch
release,
I
think,
but
not
like,
really
follow
the
release
process
myself.
A
From
what
I
recall
to
include
italy
fix
into
a
gitlab
batch
release,
I
think
you
will
need
to
prepare
like
a
merch
request,
targeting
the
stable
branch
and
then
the
maintainer
will
need
to
approve
and
merge
it.
And
then
you
basically
need
to
wait
for
a
patch
release
for
gitlab
to
happen.
So
we
can
task
like
a
new
version
and
that's
it
I
very
broadly.
That
will
be
it
if
I
am
not
mistaken,.
A
A
B
Well,
it
doesn't
happen
too
often,
so
in
that,
in
that
perspective,
it's
it's
it's
pretty
okay.
Luckily,
we
are
lucky
that
that
now
we
had
some,
we
had
to
do
some
some
backboarding,
sometimes
with
first
for
a
certain
customer,
and
that
was
pain,
painful,
especially
like
doing
a
lot
of
backboards
on
on
small
fixes,
but
that's
that's
the
burden
of
creating
merch
requests,
I'm
not
sure
if
you
can,
if
you
can
get
around
that,
because
yeah
that
back
porting
the
code
is,
is
always
needed.
B
C
Yeah,
okay,
so
this.
A
This
one
will
be
the
same
idea
as
like
a
self-serve
deployment.
The
same
idea
would
be
to
have
some
sort
of
self-serve
release
in
a
way
in
which
you
could
still
prepare
the
merch
quest,
merge
it
into
the
stable
branch,
but
then,
like
italy,
maintainer
will
be
to
able
to
attack
italy
version
and
release
it
without
waiting
for
us,
like
the
release
manager,
delivery
team
to
do
a
patch
release
for
gitlab,
like
that.
This
will
be
the
main
idea
that
we
are
trying
to
also
aim
for
yeah.
B
And
the
like,
like
version
numbers,
would
they
diverge
or
is
it?
Is
it
the
idea
to
keep
like
the
same
patch
version
number
for
for
gitly
and
gitlab.
A
That
is
a
good
question.
I
would
say
that
the
version
number
will
be
the
same
like
we
will
try
to
think
about.
They
should
be
the
same
because
if
we
have
like
15
that
three
that
to
get
now
that
is
pointing
to
15.3
that's
for
vitaly,
it
might
be
weird
and
it
may
be
break
something,
but
I'm
not
sure
so
I
suppose
perhaps
tagging
italy
will
also
attack
her
gitlab,
but
then
you
will
be
able
to
do
it
yourself
without
waiting
for
us,
so
that
might
work
as
well.
B
C
Okay,
so
we
are
on
time,
do
you
have
any
questions
or
comments
or
anything
that
you
want
to
add.
B
No,
not
really,
I
think
like,
as
I
mentioned
it's
for
me,
also
quite
a
lot
of
magic,
which
is
I'm
not
sure
if
that's
the
that's
the
the
purpose
of
well.
Maybe
it's
the
purpose
of
your
team
like
make
deployments
and
releases
as
effortless
less
than
possible
as
possible
for
for
the
people
who
are
building
the
software.
B
I
realize
getting
getly
things
fixed
is
sometimes
painful
from
your
side
which,
which
I'm
not
proud
of.
Let
me
say
it
like
that,
although
I
don't
know
how
to
improve
that
and
yeah.
That's
that's
about
it.
B
I
tried
to
follow
up
a
little
bit
on
that
issue,
that
there's
been
a
lot
happening
there,
but
yeah.