►
From YouTube: 2020-06-23: Security Releases as part of auto-deploy
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,
awesome
not
thank
you,
everyone
for
joining
and
we
are
going
to
go
to
the
security
releases
as
part
of
the
app
to
deploy
and
just
to
get
us
started,
and
we
like
to
briefly
go
over.
What
is
the
problem
that
we
are
trying
to
solve
and
what
is
the
proposal
that
we
aim
build
so
I'm
going
to
share
my
screen.
A
Can
you
see
also
okay,
so
the
problem
that
we
want
to
solve
is
that
whether
we
are
performing
a
security
release,
the
auto
deploy
processes
are
stopped.
That
implies
that
gitlab
is
no
longer
receiving
any
deployment
under
the
security
releases
finish
and
giving
that
the
security
releases
take
between
two
or
three
days
when
they
are
easy
or
four
to
five
days
when
they
are
called
normal.
That
means
that
gitlab
calm
is
not
receiving
any
deployment
for
a
long
period
of
time.
A
So
we
need
to
implement
a
way
in
which
the
security
risks
can
coexist
at
the
same
time
of
Diablo
deployed
processes,
so
one
shouldn't
block
the
other,
and
particularly
what
we
want
to
achieve
is
that
day
out
of
destroy
branches,
they
need
to
be
created
at
the
same
rhythm
so
daily.
On
the
same
on
the
same
branch,
we
need
to
continuously
deployment
to
get
love
at
the
same
pace
and,
additionally,
we
want
forget
love
to
be
protected
24/7,
so
we
need
to
find
a
way
to
deploy
the
security
fixes
once
they
are
ready.
A
B
A
Well,
we
perform
security
releases,
basically
at
the
end
of
the
month
after
the
22nd
and
then
on
to
this.
Until
that
moment
we
basically
merge
all
the
March
security
fixes
and
we
deploy
them
to
staging,
and
then
we
deploy
them
to
penury,
they
are
verified
and
then,
if
everything
goes
right,
we
sync
the
content
of
security
into
canonical
right,
and
that
is
the
moment
in
which
they
reach
like
canonical
so
I.
Would.
A
Yes,
they're
following
regularly,
but
we're
in
a
security
release.
We
have
this
auto
deployed
task
security
that
deploys
our
of
security
content
right,
so
yeah,
okay,
so
continuing
to
achieve
these,
the
modifications
that
we
need
to
do
are
several
starting
with
the
security
release
process
and
from
the
engineering
side.
A
We
need
to
find
a
way
to
merge
request
to
merge
the
merger
feistel
it
in
master
once
it
is
ready-
and
there
are
a
lot
of
more
minutia
here-
that
I
am
not
going
to
go,
introduce
these
details
because
I
want
the
call
to
refocus,
but
that
is
like
the
main
point
and
from
the
release.
Man
on
your
side.
That
implies
that
the
security
release
is
basically
kind
of
reduced,
because
once
we
merge
the
merge
of
ways
that
are
targeting
master
once
they
are
ready.
A
A
So
what
is
what
are
the
key
differences
from
the
current
security
release
that
we
have
to
the
one
that
we
are
proposing
with
this
epoch?
The
first
one
is
that
the
merge
request
already
master.
They
should
be
merged
once
they
are
ready,
and
this
implies
that
the
well
they
should
be
verified
by
the
maintainer
and
the
code
review
process,
but
they
should
also
need
to
be
verified
by
a
knapsack
team
member
before
they
are
merged
until
now.
A
At
the
moment,
these
security
fixes
are
verified
on
staging
after
they
are
merged,
but
we
need
to
move
that
verification
before
and
also
during
the
security
release
we
want,
we
don't
longer
need
the
following
actions.
We
shouldn't
need
to
have
to
deploy,
to
task
the
auto,
deploy
security
and
deployed
to
staging
and
perform
the
QA,
because
that
is
supposed
to
be
performed
before
the
security
rule.
The
security
fix
large.
A
Okay
and
the
modifications
to
our
outer
deploy
process
is
that
well
in
canonical
stays
the
same
way
as
it
is
right
now
the
fixes
are
pick
into
the
coronal
to
deploy
and
then
security.
We
need
to
implement
kind
of
the
same
thing.
We
need
to
pick
the
security
fixes
into
the
current
auto
deploy
branch.
The
security
fixes
that
are
already
and
there
are
merge
and
then
since
and
assuming
that
outer
deploy
from
canonical
is
constantly
merged
into
the
security
of
the
deploy.
The
security
of
the
deployer
should
contain
all
the
fixes
from
security
and
canonical.
A
So
that
means
that
security
needs
to
be
used
for
Beyonc
and
what
our
modifications
to
our
infrastructure
right
now.
The
way
we
have
it
now
is
that
uncanonical,
all
the
protected
branches
are
push
mirrors
to
security
and
the
security
are
Porsche
mirrors
built,
but
we
need
to
change
this
well,
the
stable
branches
stay
the
same
way.
We
have
it
through
push
mirror
but
but
master
and
to
deploy.
They
need
to
be
merged
into
security
from
canonical
into
security,
and
we
can
keep
the
posh
mirror
from
security
to
build.
B
A
Yeah
they
need
to
prepare
security
fix
well,
we
pointed
them
to
the
to
our
documentation
and
they
found
like
the
whole
process
like
to
build
a
security
fix.
You
need
to
create
the
merge
of
authority
master.
You
need
to
create
the
merge
of
march
of
authority
in
the
web
course
you
need
to
ensure
all
of
them
are
approved.
So
we
have
all
of
these
guidelines
for
the
security
release
process
from
for
the
developer
site,
right.
C
B
A
In
this
new
process,
they
should
verify
it
like
us,
any
other
merge
request
before
it
is
merged.
So
right
now,
every
merger
place
every
regular,
merge
request.
It
should
be
verified
before
it
is
merged
like
it
is
like
the
developer
task
to
do
it,
and
at
this
moment
we
are
kind
of
all
suggesting
that
they
follow
the
same
process
of
verifying
their
code
before
it
is
merged.
But,
additionally,
we
are
asking
an
application
security
engineer
to
verify
it
from
the
security
perspective,
and
for
that
we
also
have
like
this
proposal.
A
You
have
probably
seen
it
about
the
way
we
should
validate
the
merge
request
before
they
are
merged,
and
this
basically
involves
triggering
an
especial
job
on
security
merger.
Well,
that
is
going
to
build
a
docker
image
and
this
docker
image.
It
is
going
to
be
used
by
an
application
engineers
to
test
the
changes.
So
once
the
application
engineer
is
happy
with
these
changes
in
it.
While
it
is
happy
like
it
has
verified
that
they
are
working,
it
is
going
to
approve
the
merger
first
and
now
the
merger
process
consider
ready
to
be
merged
right.
D
So
my
needs
to
add
a
bit
more.
You
said
application
applications
app
sack,
so
it's
up
SEP
16
and
the
second
thing
is:
you
also
said
that
application
F
SEC,
can
click
this
button.
Actually
developers
also
can
click
this
button
in
the
regular
process
right
working,
the
regular
merge
request
process
outside
of
security.
They
have
the
same
thing
that
allows
them
to
build
the
same
package
docker
image
and
execute
automated
QA
on
it
on
demand
so
for
developer.
Nothing
should
exactly
change.
C
C
The
developer
can
verify
the
fix
themselves,
apps
that
can
verify
it
on
production
and
right
now,
like
everything's
waiting
in
a
list,
basically
until
we're
ready
to
release
it
and
then
it
all
gets
merged
at
once,
and
then
that
we
have
to
go
through
and
verify
every
single
fix
in
a
batch.
Basically,
so
we
to
be
real-time
right.
B
A
B
It's
just
what
I
asked
earlier,
which
was
just
I,
was
trying
to
get
my
head
around
whether
we
were
trying
to
run
two
separate
release
pipelines
at
a
time
which
sounds
like
yes,
is
the
answer,
so
security
heading
out
to
sell
posted
like
we
already
do,
I
think
it's
the
answer
versus
like
where
we're
trying
to
merge
in
the
security
ones
into
or
to
deploy.
So
that's
that
all
make
sense
to
me
now.
Yeah.
C
A
I
think
for
the
back
forces
he
still
makes
sense
to
merge
them
like
when
we
start
the
security
release,
because
we
don't
need
them
like
before.
So
the
back
part
stays
the
same.
Basically,
okay,
myself,
okay,
awesome,
so
I'm,
very
sorry
that
I
am
trying
all
this
information
that
you
I
mean
I'm,
pretty
sure
Lisa.
But
thank
you
for
for
listening
and
for
keeping
the
pace.
A
Okay,
so
I
would
like
for
us
to
identify
what
are
the
biggest
problems
or
the
biggest
well
yeah
the
biggest
problem,
because
we
have
a
lot
of
small
details
that
I
don't
want
to
go
into
those
because
we
are
going
to
be
here
the
whole
day,
but
I
think
I
shall
identify
like
four
main
areas
that
we
can
work
somehow.
So
the
first
one
is
merging
the
merger
points
to
master
when
they
are
ready.
A
The
second
one
is
allow
for
security
master
to
diverge
from
canonical
master
and
the
same
one
goes
for
security
under
deployed.
So
we
need
these
two
branches
to
be
allowed
to
diverge
from
canonical
and
then
also
we
need
to
move
the
outer
deploy
Italian
to
security
inside
of
each
inside.
Each
of
this,
like
problem,
we
have
a
lot
of
steps
that
we
can
do,
but
I
think
these
are
the
ones
that
are
the
biggest.
B
C
So
the
ability
to
have
a
mirror,
instead
of
just
straight
push
something,
and
instead
to
have
that
merged
something
that
doesn't
exist
and
based
on
my
experience
with
the
mirroring
work,
I
did
in
the
last
couple
releases
it.
It
would
take
at
least
one
full
release
like
a
month,
probably
more
just
to
support
that.
C
Is
way
more
complicated
and
that's
why
I
think
I
think
we're
ultimately
gonna
end
up
relying
on
this
project.
We
have
called
merged
rain,
which
was
built
to
handle
the
taking
the
contents
of
E
and
Genet
in
to
see
basically
and
removing
all
the
e
stuff.
But
then
we
also
added
support
for
that
to
handle
merging
branches
in
the
same
project.
So
you
give
a
project
and
bring
it
a
source
project
and
a
source
branch
and
a
target
project
and
target
branch
and
then
merges
one
into
the
other.
C
B
C
I
think
so
my
your
third
one
allows
security.
I'll
go
play,
diversion
canonical
out
of
play,
I
think.
Ultimately,
we
wouldn't
even
need
a
canonical
auto
deploy.
It
would
only
exist
on
security,
and
that
would
be
the
state
of
the
latest
passing
build
of
this
resulting
merge
of
canonical
master
and
security
master,
and
that
becomes
the
auto
deploy
and
I
would
only
exist
on
security
and
build
for
tagging.
D
C
D
D
D
That's
that's
my
main
concern
as
well.
Like
has
been
for
all
these
months.
So
if
you
remember
Robert
in
in
Myra,
when
we
spoke
originally,
we
were
still
deploying
once
a
week
or
rather
from
a
branch
once
a
week.
So
the
auto
deploy
branches
were
waist
lower
and
it
was
back
in
November
Amy.
So
back,
then
we
could
have
it.
Please
sell!
Well,
we
have
a
week
and
then
we
can
prepare
a
back
porch
release
and
we
have
some
time
to
actually
figure
that
out
we're
doing
daily
deploys
now
from
from
master.
Basically.
A
C
D
C
A
B
D
D
C
C
D
Shouldn't
that's
the
point.
The
point
is
that
it
shouldn't
impact
anything
else
that
we
know
right
like
we
are
assuming
that
it's
not
gonna.
So
if
we
like
I,
agree
with
you
Robert
that
it
is
even
a
smaller
iterative
step,
because
if
we
move
that
to
security,
we
can
know
whether
it
works
reliably
one
way
or
another,
and
we
can
have
uninterrupted
operation.
D
If
that's
the
case,
that
means
that
we
have
solid
foundation
to
work
on
the
next
step,
which
would
be
mirroring
master
into
security
master
and
then
adapting
Auto
picker
to
pick
from
there
right
like.
That
is
the
step
forward,
where
we
still
expect
no
change
right
like
as
long
as
there
is
actual
no
change
in
impact.
We
are
good,
but
we
are
like
slowly
inching
towards
that
model.
Is
that?
B
D
D
D
C
D
The
the
actual
failures
on
auto
deploy
branches
actually
gets
fed
into
broken
master,
because
it's
a
protected
branch
and
failure.
There
prevents
us
from
deploying
so
quality
Department,
so
engineering
productivity
is
responsible
for
making
sure
that
master
and
auto
deploy
are
passing.
So
that's
where
the
information
will
go
at
minimum.
D
C
D
La
a
sign
of
in
in
a
minute
to
go
to
the
next
meeting,
I'd
suggest
like
I,
don't
know
how
long
this
meeting
is
for.
So,
if
you
want
to
continue
discussing
just
go
for
it,
but
it
would
be
interesting
to
to
do
a
small
PLC
just
to
see
everything
that
is
gonna
break
and
then
before
we
discuss
like
continue
discussing
this
bigger
picture
by
the
way,
my
I
think
it
should
be
a
recurring
meeting,
because
I
think
it's
important
that
we
keep
a
cadence
on
this.
D
We
should
try
to
find
out
like
what
kind
of
information
that
brings
us
for
the
next
meeting,
because
we
would
want
to
iterate
quick
on
this
and
through
POCs,
not
through
larger
projects,
that,
yes,
this
is
an
iteration
but
moving
all
the
branches
to
security
is
gonna
take
a
month
at
minimum
to
actually
achieve
safely
right.
So
small
POC
is
that
that
allows
to
see
what
breaks
and
what
doesn't
should
feed
us
enough
information
to
keep
these
meetings
fueled
with
information.
D
A
Right
thanks
foreign
bye,
okay,
so
we
are
well
basically
about
to
finish
the
reason.
Also,
but
I
think
we
have
like
two
possible
immediate
steps.
First,
it's
like
to
grab
up
the
validate
security
fixes
before
they
are
merged.
So
there
are
some
small
steps
like
we
don't
have
any
blocker
on
this
one.
There
are
some
small
step
that
I
still
need
to
complete,
but
I
really
think
that
then
next,
not
these
security
release
that
we
are
going
to
perform
most
likely
this
week,
but
the
next
one
from
next
month.