►
Description
Delivery team discusses requirements for security patches and releases in continuos deployment and delivery model
https://gitlab.com/groups/gitlab-org/release/-/epics/16
A
The
idea
I
had
was:
how
are
we
going
to
ensure
that
security
fixes
go
first
of
all
stay
public
and,
second
of
all,
private
stay
private,
yes
and
second
of
all,
end
up
on
that
github
dot
org,
so
that
we
can
build
and
deploy
and
then
also
release,
but
then
also
end
up
back
to
public
repository.
So
with
the
introduction
future
introduction
of
security
projects
that
are
private,
we
are
going
to
have
three
places
we
are
going
to
have
github.com
public.
A
We
are
going
to
have
security
private
and
we
are
going
to
have
Daggett
audit
org
private,
but
also
place
where
we
are
building
things
from
right.
So
in
order
to
ensure
that
we
don't
lose
herself
we'll
have
to
introduce
a
clear
way
of
how
things
progress
between
these
repositories.
So
my
idea
was
little
bit.
Com-Pub
leaks
remains
the
source
of
truth
for
any
work
that
kandi
public.
A
That
repository
will
automatically
sync
branches,
so
master
will
automatically
need
to
be
synced,
but
this
is
not
going
to
be
enough
like
we're
not
going
to
be
able
to
use
project
mirroring
because
project
mirroring
just
tries.
If
the
branches
diverged
give
up,
we
will
need
to
have
a
system,
possibly
reusing
the
merge
train
that
will
try
to
actually
merge
the
branches
together.
So
this
is
master.
A
This
is
all
of
the
stable
branches
as
well,
so
all
of
the
backwards,
because
security
private
repository
we
are
going
to,
we
are
going
to
think
about
actually
having
as
soon
as
something
is
ready,
including
the
back
ports.
Have
people
merge
things
in
those
branches
right,
so
in
order
to
keep
those
branches
current
with
ongoing
development,
ongoing
patch
releases
and
so
on,
we'll
have
to
have
the
sync
between
public
repository
and
security.
Private
repository
done
with
a
certain
tool.
I,
don't
know
what
to
react.
B
B
A
A
A
As
simple
as
this
so
calm,
private
security,
dot,
org
SOCOM,
will
constantly
try
to
sync
to
dot.
Org
and
security
will
only
be
used
to
cherry-pick
things
to
target
laboratory.
So
when
we
are
ready
to
do
something,
we
would
fire
off
a
tool.
I,
don't
know
what
that
will
take
all
of
the
merge
requests
that
have
been
merged
here
and
do
a
cherry
pick
and
then
that
branch,
the
Pratt
branch,
would
then
be
synced
to
that
get
love
the
torque,
but.
B
Our
goal
for
this
carry
repository
was
well
guess
not
specifically
for
the
security
deposit
ori,
but
for
our
current
and
fourth
go
for
ongoing
security
practice
to
merge,
merge
request
directly
into
stable
branches
rather
than
security
branches
or
some
others
rooms
that
we
cherry
pick
from
so
I'm
like
if
we're
merging,
stuff,
now
and
scary
repository
into
what
they
eleven
nine
stable.
But
then
we're
not
necessarily
sinking
eleven
nine
stable
to
dev
until
we're
ready
to
do
a
security
release.
B
A
A
A
Exactly-
and
this
is
why
dot
org
is
becoming
a
place
where
things
are
going
to
accumulate,
and
only
when
we
are
ready.
We
can
then
push
to
github.com.
So
calm,
we'll
always
have
this
period
of
time,
where
there's
going
to
be
a
divergence
between
what
we
actually
deployed
versus
what
what
is
actually
public.
So
then.
B
A
A
C
A
Doesn't
matter
we're
just
like
say,
like
with
the
move
of
security
releases
to
little
calm,
private
repository,
that
gift
of
the
org
is
opening
up
for
us,
for
whatever
we
want
to
do
so,
you
know
it
doesn't
have
to
be
building
it
from
somewhere
else.
That's
going
to
be
our
somewhere
else
right,
yeah.
B
A
We
always
you
know,
do
this
or
we
always
have
a
private
repository
and
then
from
that
private
repository,
we
pick
things
that
we
want
to
get
into
the
public,
and
that
also
adds
a
dimension
of
complexity
right
like
if
we
are
to
do
that
with
with
fast-moving
master
that
we
have.
It's
gonna
be
like
tricky
to
keep
that
updated
yeah.
A
So
the
best
idea
I
have
so
far
is
ensuring
that
we
always
have
one-way
street,
and
it
always
has
to
be
around
about
right
like
it
goes
from
get
all
calm
to
security
to
dev
and
then
when
we
are
ready.
Actually
let
me
change
that
statement.
It's
not
only
around
about
one
way.
It's
a
Utrecht
roundabout
one
way,
which
has
a
traffic
light
in
the
middle
yeah
I,
don't
know
if
you've
seen
those
but
the
nude
for
me
by
her
yeah.
A
A
Right,
like
everything
that
we
can
automate
will
mean
that
we
can
just
quickly
release
it
doesn't
matter
right
like
we
can
just
oh,
you
have
two
things
merged
into
backwards:
cool
we're
just
going
to
merge
those
and
move
on,
or
you
know
three
of
those
things,
basically
removing
the
the
build
up
that
we
have
with
regular
security
releases.
All
security
releases
are
going
to
become
regular
because
they're
going
to
be
automated.
A
B
A
B
B
As
it
is
now
there,
they
are
just
like
building
up
at
this
traffic
light,
and
then
we
say:
okay,
we're
ready
to
do
merge
so
looking
all
over
net
we're
ready
to
release.
Let's
merge
the
ball
right
now
into
the
stable
branches,
which
is
the
only
really
thing
really.
The
only
thing.
That's
changed
in
the
security
process
of
wires
that
were
not
merging
directly
in
this
little.
A
B
A
A
B
Basically,
because
we're
out
like
for
our
own
use,
we're
always
gonna
be
building
from
the
dev
master,
which
can
include
security
fixes
if
you're
never
merging
master
back
to
well
yeah.
We
feel
it.
We
still
do
have
to
merge
master
back
super
common,
but
but
at
what
point
is
after
security
really
yeah?
B
A
A
B
B
A
B
A
Is
just
an
intermediate
intermediate
step?
We
are
currently
like
the
intermediate
step
that
job
is
going
to
be
implementing
is
just
branching
and
then
building
from
that,
but
this
is
to
speed
us
up
so
that
we
can
get
to
a
situation
where
we
are
going
to
build
from
aster
right,
because
this
is
a
big
process
change.
There
has
a
lot
of
possibilities
of
breaking
things
left
and
right.
A
So
I
think
back.
Ports
are
kind
of
simple,
because
we
can
say
that
for
back
ports
it
doesn't
matter.
The
back.
Port
branches
are
slower
anyway,
right,
look
as
soon
as
we
create
a
stable
branch,
it
just
goes
lower
and
if
we
even
decide
to
merge
to
hold
off
merging
security
fixes
in
stable
until
we
are
ready.
That
is
fine.
A
Because
what
can
happen
is
we
use
the
same
tools
we
merge
when
we
are
ready
to
release
yeah
and
then
we
think
those
branches
to
definitely
work
backwards
and
then
build
from
that
and
then
release
to
public
and
then
sync
all
of
that
to
public
repositories
that
correct
does
not
change.
The
problem
here
is
master.
That
is
fast-moving.
A
A
A
Will
we
are
going
to
be
built
package
from
us,
but
we're
not
going
to
publish
it?
Then
that
means
that
the
only
thing
that
master
actually
does
need
to
do
is
ensure
that
once
we
are
ready
once
we
are
ready
to
publish
the
backboards,
we
can
safely
publish
master
branch
to
get
love.com
as
well,
so
open
it
up
as
well.
Right.
B
A
A
A
A
B
A
B
A
A
A
B
A
C
B
B
A
A
A
B
This
is
probably
getting
your
hitters
that
ahead
of
ourselves,
but
what
happened
well
like
now
developer
has
to
create
three
backwards:
a
master
branch
chain
and
then
also
create
the
patch
going
to
start
worrying
about
what
happens.
If
there
are
multiple
fixes,
touching
the
same
area
and
then
patches
that
could
be
applied
with
specific
order.
Yeah.
A
B
A
B
B
Maybe
the
stoplight
needs
to
be
earlier
at
the
security
repository
or
stuff
builds
up
there
that
way
we're
never
building
from
there.
So
they
don't
have
to
worry
about
that.
Getting
released
early
and
that's
just
living
in
the
private
repository
and
when
we're
ready
for
security
release,
we
sync
them
to
dead
and
build.
B
B
But
no,
it's
really
cuz
yeah.
Let's
say:
we've
applied
these
post-deployment
patches,
but
they're
only
applied
on
comm,
so
developers
working
on
whatever
they're
working
on
a
master
could
kind
of
retro
actively
make
those
patches
no
longer
apply,
because
they
don't
even
know
that
those
changes
have
done
it.
I.
B
A
A
A
A
Well,
the
stop
like
to
exist
still
on
master,
but
it's
a
fast
changing
traffic
light,
because
as
soon
as
you
merge
it,
we
deployed
it.
We
are
ready
to
create
a
back
port.
We
can
just
merge
the
back
ports
and
cut
a
release
and
publish
because,
regardless
of
what
was
already
merged
in
stable,
it
can
be.
B
B
B
C
A
There
is
a
difference
right
with
security,
prep
branches.
You
have
one
source
of
truth,
and
that
is
master
and
you
cherry
pick
from
there,
but
for
security,
prep
branches
for
all
the
backwards.
That
means
you
have
4,
so
3
back
ports,
no,
oh
three,
two
back
ports,
plus
a
master
node
or
three
back
push
plus
a
master.
It
depends
times
to.
A
A
B
A
A
If
it's
all
automated
or
most
of
it,
if
it's
automated,
like
it,
doesn't
matter
because
what
I
want
to
get
away
from
is
actually
having
to
have
release
managers
I
wanted
to
transfer
this
to
developers,
say:
oh,
you
want
this
to
be
backward.
It
no
problem,
create
a
merge,
request,
apply
specific
label,
have
the
reviewer
merge
it
into
stable
and
I'll
have
automation
that
will
automatically
like
go
through
the
label,
and
you
know
if
it
doesn't
see
a
security
label,
it
can
hold
off.
A
B
B
I
think
you're
gonna
well,
a
that's
just
a
bad
look
and
then
B
I
think
people
are
lazy
and
they're
not
going
to
upgrade
their
systems
every
day.
So
we're
gonna
have
these
published
security
patches
out
in
the
wild
but
which
one
did
I
actually
apply
and
I
think
it
makes
more
sense
to
group
them
up
like
we
are.
A
A
With
movement
of
security
development,
from
that
little
of
the
tork
into
a
separate
repository
that
is
going
to
be
exclusively
private,
we
adds
another
level
that
theoretically,
should
allow
us
to
have
specific
sources
of
truth.
Right,
like
public
repository
on
github.com
will
be
the
source
of
truth
for
the
public
security
release
security.
A
A
A
It
will
be
receiving
things
from
public
automatically,
but
also
when
we
are
ready
for
security.
We
would
then
be
like
syncing
security
repository
to
debit,
lavatory
now
in
theory,
and
obviously
now
that
get
laboratory
being
the
final
stop
once
we
are
ready
to
publish
everything,
it
would
just
push
to
public
completing
the
circle
so
one
way
street.
There
is
no
way
from
there
bit
of
the
torque
to
go
to
security.
It
always
has
to
be
one
way
street
to
simplify
the
process.
Now
the
problem
comes
when
we
add
more
variables.
First
of
all,
back
ports.
C
A
Branch
being
the
biggest
problem,
but
we
can
t
erratically
figure
out
how
to
do
all
the
backwards
because
they
are
slow-moving
and
like
we
have
a
bit
more
control
there.
But
monster
becomes
a
major
issue,
because
if
we
say
that
we
deploy
to
get
love
that
calm
environments
from
private
death
master,
that
means
that
is
the
point
where
everything
is
gonna
build
up,
because
if
we
are
not
ready
to
release
the
public,
we
cannot
publicize
any
of
this.
C
Right,
so,
to
start
with
what
you
first
said,
we
have
the
private
repo
for
security
changes.
Then
we
have
the
public
repo
on
github
calm.
Both
of
these
are
on
koat.com
right
yeah,
so
we
have
a
security
vulnerability
and
we
push
a
new
commit
to
the
private
repo.
At
that
point,
the
synchronization
breaks
because
the
security,
the
private
repo,
is
ahead
of
the
public
one
right,
because
you're
right.
A
A
C
B
A
And
I
was
I
was
even
thinking.
You
know
every
time,
I
see
something
as
complex
as
this
I'm
thinking.
Okay,
we
are
missing
something
and
we
need
to
simplify
the
problem.
Is
simplification
only
moves
you
in
two
completely
opposite
directions?
One
is
everything
needs
to
be
public
which
includes
security,
fixes
which
we
cannot
do,
or
everything
needs
to
be
private,
which
goes
against
what
we
are
doing
here.
Yeah.
C
C
A
B
C
C
C
A
It's
way
more
complex,
but
at
least
removes
the
need
to
constantly
try
to
sync
that
gets
of
the
tour,
and
you
don't
really
know
what's
involved
there,
and
that
would
mean
the
dev
gets
of
the
tour
master
or
all
of
the
backwards
will
never
sink
back.
So
they're
going
to
be
the
endpoint.
So
we
are
moving
from
a
roundabout
to
just
a
one-way
street.
A
B
A
Thinking
about
that
and
I
think
it
actually
does
not.
If
you
also
include
the
other
complexities
that
this
brings.
So,
for
example,
you
know
how
it
looks
with
developers
and
different
accounts
on
their
people
of
the
Touareg,
and
so
on.
That
complexity
already
introduces
a
lot
of
delays.
A
lot
of
problems
for
us,
removing
that
complexity
clears
up
part
of
our
time.
A
B
B
I'm
wondering
if
we
well
like
York,
built
all
this
tooling,
to
make
the
actual
merge
process
easier
and
I.
Don't
know
if
we've
actually
seen
that
do
its
intended
purpose.
Yet
for
release
to
see
like
how
that
improves
things.
But
then
we
still
come
back
to
the
problem
of
like
lack
of
visibility
on
dove,
like
lack
of
cross
references
and
stuff,
like
that,
so
I
think
it's
probably
still
worth
doing,
but
I
feel
like
it
is
more
complex,
I
think.
B
C
About
security
fixes
and
public,
you
know,
changes
and
the
earth
sink
to
Deb
is
always
like,
then,
we'll
never
be
ahead
of
get
lab.
Calm,
they'll
never
be
changes
on
dev
that
aren't
on
comm
and
I.
Think
that
does
make
it
a
bit
simpler.
The
only
purpose
of
death
is
essentially
used
to
run.
Is
you
know
the
API
for
running
for
connecting
to
runners
right
I
mean
that's,
that's
that's
its
primary
purpose
and
also
as
in
order
for
the
code.
C
C
A
A
A
C
C
C
A
B
A
A
A
B
A
B
C
C
C
B
C
The
thing
is:
is
that
it's
using
the
bsd
unix
patch
tool,
so
it
basically
tries
to
apply
a
patch
and
can
kind
of
tell
if
it's
already
been
applied,
but
there's
certain
when
you
start
having
patches
on
top
of
patches
and
it
gets
a
bit
hairy
and
I'm
not
sure
like
I'm,
not
sure
whether
we
want
to
rely
on
that.
In
that
way.
A
Definitely
fork
things
so
they
do
things
from
private
and
then
they
try
to
backwards,
and
that
fork
is
always
private,
but
the
problem
is
their
development
happens
in
private.
So
it's
not
a
difference
between
what
they
do
day
to
day
when
they
have
to
fork
something
so
for
us,
it
would
probably
be
a
difference.
C
I
think
a
diagram
would
actually
be
helpful
here.
I
just
started
to
sketch
one
out
myself
because
to
me
it
seems
like
we
have.
We
have
three.
We
have
three
repositories
right.
We
have
the
public
repository
on
github
com,
you
have
the
private
repository
on
github
com
and
then
we
have
the
repository
on
dev
that,
when
pushed
to
triggers
a
deployment
or
right,
so
all
the
work
happens,
so
I
think
what
you,
what
you
showed
me,
the
diagram
that
you
have
shows
that
the
sync
works
between
the
public
and
private
repository
on
github,
comm
and.
A
C
A
C
Dev
in
a
normal
case
that
commit
would
be
synced
from
the
public
repository
to
the
private
repository,
then
from
the
private
repository
to
dev,
and
then
the
pipeline
would
kick
off
from
dead
and
that's
like
the
normal
arc
flow
for
getting
builds
to
production
to
get
a
standard
burst,
and
then
they
get
promoted.
Okay.
So
now
we
have
a
security
vulnerability.
C
C
Think
this
still
works
fine
right.
So
if
we
have,
if
we
have
the
merge
train
working
between
the
public
and
the
private,
one
should
be
okay.
Hopefully,
unless
if
there
are
conflicts
but
assume
it's
okay,
mm-hmm
and
I,
don't
even
know
if
it's
a
problem,
if
it's
not
okay,
it's
not
the
end
of
the
world.
Right
like
it
just
means
that
the
sink
will
fail
and
we
will
be
the
pipeline
that
deploys
the
production
will
be
stopped.
I,
don't.
C
A
C
C
Think
I
think
what
I
would
say
for
a
first
iteration
is
is
right
now,
where
we're
thinking
a
weekly
cadence
for
these,
these
new
stable
branches
that
were
calling
the
auto
deploy
branches.
So
it's
at
the
end
of
that
week,
then
the
decisions
need
to
be
made
right.
You
have
this
extra,
you
have
this
security
commit
on
the
private
repo
and
it
hasn't
been
merged
to
master,
and
you
want
to
create
a
new
audit
deploy
branch.
You
want
to
create
a
new
branch
on
Sunday,
but
it
needs
to
have
that
security
change.
A
C
A
C
Know
what
I'm
saying
yeah
I
think
it
should
probably
do
this
anyway,
because
there
should
be
no
commits
on
these
auto
deploy
branches.
The
ones
that
are
created
every
week
that
aren't
merged
to
master
our
method
for
getting
commits
into
the
auto
deploy
branch
is
to
add
pic
labels
to
em
ours
that
have
been
merged
into
master
right.
So
we
could.
We
could
look
back
in
the
previous
week.
This
is
kind
of
hairy,
not
not
very
nice.
C
The
alternative
is
does
just
stopped
like
we
could
just
stop
the
auto
deployments
until
we
get
these
security
changes
into
master
and
it
would
really
suck
if
we
had
a
security
vulnerability
at
the
end
of
the
week,
and
it
would
stop,
but
it
would
stop
the
pipeline,
but
maybe
we
should
be
I
mean
I
mean
to
be
honest.
Once
the
security
changes
on
Telecom,
there
should
be
nothing
preventing
us
from
you
know,
making
the
security
fix
public
and
there.
A
C
A
This
is
where
I
was
speaking
with
Robert
nothing
this
cold,
but
earlier,
like
that's
I,
think
we
need
to
temple.
I
have
a
template
for
this
thing
like
it
should
be
completely
unattended,
all
right
like
any.
If
they
want
like.
If
someone
wants
to
add
something
to
it,
they
can
already
do
that
on
a
blog
post.
C
C
C
A
C
A
So
I
do
think
you
said
a
bunch
of
things
there
that
are
actually
useful,
so
limiting
the
scope
is
number
one
making
sure
that
we
don't
think
about
continuous
master.
But
thinking
about
this
intermediate
step
of
having
Auto
deploy
branches,
that's
number
one
and
number
two
is
when
we
have
those
Auto
deploy
branches
thinking
about
from
where
we
are
creating
them
like.
If
we
are
creating
them
constantly
from
master.
We
also
need
to
ensure
that
the
previous
branch
is
merged
in
or
we
just
create.
A
C
Another
thing
we
can
do
Marin,
maybe
is
we
simply
have
a
label
on
an
mr
until
it's
merged
into
master
that
we
can
query
for
so
that
when
we
create
these
branches,
this
this
would
be
the
mr
on
the
private
repo
right
it's
like,
and
until
that,
mr
is
merged
into
master.
That
label
is
present
right
and
that's
way
whenever
we
we
create
the
new
set
of
branches
when
I
create
the
branch
or
when
we
create
the
branch
on
the
private
repo
I.