►
From YouTube: POC: Security release pipeline
A
It
is
not
a
surprise
that
security
releases
are
the
hardest
release
that
release
managers
need
to
accomplish,
and
this
is
basically
because
security
releases
are
time
consuming
and
they
are
full
of
manual
steps.
For
example,
this
is
the
last
one
and,
as
you
can
see
on
this
issue,
it
contains
a
large
list
of
steps
that
that
release
managers
need
to
do.
A
We
have
been
adding
these
steps
as
a
consequence
of
us
choosing
the
boring
solution,
which
means
that
whenever
we
need
to
add
an
item
or
a
step
into
security
release,
we
basically
modify
this
template
and
add
a
new
step.
This
has
worked
in
the
past,
but
it
is
not
working
now
I
mean
this
list
is
unmanageable.
It
is
not
going
to
scale
so
one
thing
that
we
can
do
about
this
manual
steps
is
to
transform
them
into
a
pipeline.
The
same
way
we
handle
coordinated
pipelines.
A
So
here
it
is
so
this
pipeline
is
confirmed
of
different
stages
and
if
you
notice,
the
stages
are
very
similar
to
the
security
release,
template.
For
example,
we
have
the
prepare
stage,
the
back
Port,
publish
and
finance
right.
So
these
steps-
or
these
jobs,
represent
most
of
the
manual
steps
in
a
security
release.
They
don't
represent
all
of
them
because
not
all
of
them
can
be
automated.
A
Some
of
them
require
coordination
with
different
teams,
but
this
is
a
good
number,
so,
let's
see
the
first
one,
which
is
a
start,
and
this
is
basically
creating
the
release
task
issue
that
we
just
saw
with
the
main
difference
that
this
issue
is
already
reduced
in
the
number
of
tasks.
So,
instead
of
having
the
bunch
of
manual
steps,
it
has
items
like
execute
the
security
task
job
or
execute
the
security
published
job
so
instead
of
having
88,
it
has
27,
which
is
way
more
manageable,
so
I
already
implemented.
Some
of
these,
for
example,
notify
jihu.
A
So
it's
already
finished
and
I
have
like
a
fake
g-hole
issue,
because
this
is
not
notifying
anything.
This
is
a
dry
run
and
well
it
added
I
smell
a
small
note.
At
the
end
of
it
saying:
okay,
preparation
of
security
release
has
started.
It
is
a
schedule
for
this
date
and
it's
releasing
these
packages,
and
it
also
has
like
the
notifiers
lack
the
the
manual
tasks
that
we
need
to
do
is
to
notify
some
stage
teams
that
the
security
release
has
started,
and
this
can
be
also
easily
automated
actually
well.
A
A
So
you
get
the
idea
of
having
a
security
release
pipeline
two
items
that
I
want
to
highlight
about.
This
is
first
one.
Well,
the
number
of
steps
has
been
significantly
reduced.
We
have
27
instead
of
88,
which
I
think
is
great
and
second,
which
I
think
this
it
is
the
most
important
one
is
that
it
is
kind
of
changing
our
mindset.
A
A
I
think
we
could
start
with
us,
but
with
security
releases,
and
then
this
proposal
also
belongs
to
another
epic
that
I
have
been
working
about
reducing
the
active
time
security
releases
by
50
and
also
reduce
the
manual
tasks
of
security
releases
also
by
50
I
also
have
other
proposals
about
this.
So
that's
it.