►
From YouTube: Release Trains
B
All
right,
so
this
whole
discussion.
Actually
let
me
step
back
before
I
even
start.
I've
been
talking
about
the
next
step
with
with
alessio,
and
when
I
say
next
step,
I
mean
way
in
the
future
like
how
can
we
actually
deploy
commits
even
without
merging
them?
How
do
we
actually
roll
out
experiments
even
before
we
consider
all
of
the
reviews
so
basically
doing
the
bleeding
edge
thing
under
certain
restrictions
right
like
what?
B
What
kind
of
experiments
would
you
be
able
to
do
almost
in
production
without
actually
merging
things
so,
like
we
talked
about
this,
maybe
a
couple
of
months
ago
and
during
the
ama,
with
the
delivery
on
wednesday?
Sid
actually
had
a
discussion
point
basically
on
how
do
we
cut
down
the
time
between
two
commits
being
deployed,
two
changes
being
deployed
to
an
environment.
In
this
case,
we
were
talking
about
canary,
given
that
there
is
always
a
run
in
time
between
the
moment.
B
B
You
need
to
do
some
level
of
testing,
so
that
can
be
that
can
last
for
hours
and
that's
a
common
thing
in
a
lot
of
places.
Not
only
with
us
and
the
idea
in
general
is
how
do
you
ensure
that
if
you
can't
cut
that
time
down
to
negligible
which,
in
majority
of
cases
you
can't,
how
do
you
ensure
that
consecutive
commits
can
actually
be
deployed
also
consecutively,
even
if
from
the
moment
of
them
being
merged
to
the
moment
of
them
being
deployed?
We
talk
about
ours,
so
to
explain
a
bit
differently
right
now.
B
What
usually
happens
is
you
merge
something
into
master?
Rightly
your
commit
lands
there
so
commit
a.
Is
there
commit
b
follows
right,
after
maybe
like
a
minute
later
in
some
cases
seconds
later
right.
So
what
happens?
Is
you
build
your
deployment
artifacts,
you
start
deploying
to
non-prod
environments,
you
do
all
sorts
of
qa
on
it
and
you
roll
that
out
to
production
once
you're.
B
A
B
That's
wonderful,
that's
the
general,
I
think
concept.
Basically,
how
do
you
make
sure
that
the
time
between
the
changes
being
deployed
is
the
smallest
possible,
regardless
of
the
running
time?
I
think
sid
mentioned
transit
time.
He
called
it
transit
time
because
there
was
no
better
name
for
it
and
I
couldn't
find
a
better
name
for
it
as
well.
B
So
this
morning
I
was
discussing
like
while
I
was
writing
that
issue
up.
I
was
discussing
like
brainstorming
a
bit
with
alessio,
who
knows
a
lot
about
merge
trains
because
he
participated
in
those
in
that
development
back
then,
and
basically
like
if
you
strip
all
of
it
down
release
trains
are
basically
just
merge
trains
for
releases
right
like
it's,
no
different,
I'm.
A
B
And
if
you
do
this
two
times
that
doesn't
make
sense
like
if
you
have
a
merge
train
right
like
how
does
the
merge
train
right
now
work?
You
have
the
commit.
The
merge
commit
in
the
merge
request
itself
is
like
a
branch
is
created
out
of
master.
That
commit
is
added,
so
you
have
a
detached
branch,
so
a
separate
branch
on
which
the
pipelines
actually
run
right.
B
So
this
is
the
detached
pipeline
that
you
might
see
in
the
merge
request,
and
then
you
add
the
merge
request
to
to
the
train
in
a
certain
order,
and
this
way
you're
kind
of
guaranteed
that
merge
request
one
and
two
have
that
same
order,
so
that
your
master
doesn't
run
away.
As
you
merge
things,
meaning
merge
request,
one
has
commit
a
merge
request
to
has
commit
b.
You
ensure
that
you
have
master
plus
a
and
master
plus
a
plus
b
in
that
order.
B
Theoretically,
we
could
achieve
that
relatively
simply,
basically,
the
decision
of
whether
something
should
be
merged
or
not,
becomes
a
bit
more
complex
because,
right
now
the
idea
is,
is
the
pipeline.
You
created
successful,
yes,
greater
than
you're
merging
it,
but
in
this
case,
if
we
add
more
logic
to
it,
we
would
have
something.
Like
is
the
environment.
B
B
So
the
only
thing
like
from
that
discussion
I
had
with
him.
The
only
thing
that
we
need
to
do
is
like
expand
the
logic
of
how
do
you
define
merge
strains?
How
do
you
define
what
is
being
done
while
the
merge
train
is
running?
So,
theoretically,
you
could
have
your
pipelines,
so
the
unit
tests,
for
example,
run
at
the
same
time
as
you're
building
your
deployment
artifacts,
and
it
is
like
once
that
is
complete.
B
It
really
doesn't
matter
how
long
it
lasts.
You
execute
a
deployment
to
an
environment
and
based
on
the
monitoring
system
that
we
already
have
in
place.
You
observe
whether
there
is
like
an
elevated
number
of
errors.
Right,
like
you,
define
something
and
based
on
that,
you
get
the
return
information,
and
that
tells
you
all
right.
This
commit
a
is
not
causing
any
issues
or
anything
like
that.
This
is
okay.
The
test
pass
the
deployment
past,
the
metrics
are
okay,
it's
ready
to
go,
and
you
already.
B
Well,
the
next
stage
is
already
basically
production
because
you
already
deployed
it
to
an
environment
that
is
not
production.
You
already
measured
something
against
that
environment,
so,
basically,
that
commit
is
ready
to
be
merged
into
main
branch
and
because
you've
already
built
everything
in
order
to
deploy
and
test.
B
You
can
just
promote
that
all
the
way
to
whatever
the
production
environment
is
like.
However,
you
define
it
right,
so
I
mean
I'm
oversimplifying
it
here
right,
obviously,
because
there
is
like
a
lot
of
really
hard
moving
pieces
there,
but
that
is,
I
think,
the
general
concept,
and
that
way
you
will
always
have
commit
a
and
commit
b,
which
are
one
next
to
another
right
like
they.
B
The
the
champion
enter
into
the
chain
the
same
way
and
if
both
of
them
are
okay,
they
are
going
to
also
be
deployed
in
that
same
order
because
they
pass
the
same
criteria
right
like
the
same
rules
that
you
set
right
now,
things
get
seriously
complicated
if
something
fails,
but
I
think
this
is
something
we
already
decided
to
not
immediately
tackle
with
merge
trains.
As
far
as
I
remember,
if
a
merge
fails
in
the
merge
train,
you
remove
it
from
yeah,
you
just
pump
it
out.
B
Yeah
you
bump
it
out,
and
then
you
repeat
the
whole
process
with
everything
right
like
you
build
after
that,
you
rebuild
it
from
the
last
known.
So
it's
the
same
concept
as
well
like
you
would
remove
the
failed
one
and
you
have
to
redeploy
to
the
environment
and
retest
redo
the
qa
testing
and
so
on.
But
that
is
pretty
much
the
same.
I
think.
B
A
B
B
On
tax,
exactly
yeah
like,
if,
if
you
deploy
fully
on
tanks-
but
I
don't-
I
don't
think
that
is
the
problem
we
are
trying
to
resolve
here,
like,
for
example,
at
gitlab.com.
The
only
reason
why
we
deploy
on
tags
right
now
is
because
our
system
was
initially
built
with
tags
in
mind.
We
are.
We
are
basically
deploying
from
commits
these
days.
It's
just
that
the
rest
of
the
system
is
built
that
way,
so
it's
easier
for
us
to
just.
It
was
easier
for
us
just
to
adapt
that
and
fit
it
into
the
structure.
B
A
Right
so
I
could
see
a
really
cool
place
where
we
create
like
a
multi-project
pipeline
for
these
multiple
projects
and
they
all
have
their
own
release
train
and
then
it
merges
into
a
different
project
for
verification
of
your
release,
candidate
to
then
deploy
to
production.
So
you
have
all
of
these
like
target
changes
on
their
own
release,
chain
release
trains
in
their
projects,
deploying
to
a
new
target
environment
which
is
a
staging
or
canary,
and
then
that
change
gets
promoted
into
production.
A
B
And
no,
this
really
depends
on
the
projects
that
you
have
so
in
a
simplified
version.
You
don't
even
need
that
you
only
need
that
single
project
that
is
going
to
be
the
controller
or
coordinator
in
this
case
right,
so
it
will
be
picking
all
of
those
different
commits
and
assembling
the
actual
deployment
so
that
it
can
then
use
the
release
train.
B
That
is
in
the
simplified
way,
in
a
more
complex
way,
which
is,
if
you
actually
have
the
micro
service
micro
service
services.
You
then
don't
necessarily
need
that
coordinator
right.
Like
then,
individual
projects
do
need
that
release
train
and
you
have
like
more
complex
interactions
between
different
components.
Right.
B
Its
deploy
true
right
and
it's
commits
it-
commits
wow
english
today
the
commits
of
of
its
own
right.
How
can
that
project
run
that
through,
while
shortening
that
transit
time
yeah,
then
it
becomes
later?
It
becomes
a
case
that
becomes
your
building
block
and
you
can
add
more
complexity
on
top
right,
like
add
multiple
projects
and
think
about
it
on
a
different.
A
Okay,
because
what
I
want
to
do
is
just
give
the
team
as
much
freedom
to
think
about
this
problem,
my
engineers
and
give
them
just
like
a
very
simple
statement,
and
then
we
can
start
going
through
edge
cases
and
and
problems.
I
do
want
to
build
something
that
is
dog
food
able
for
us
and
that's
also
applicable
to
users
who
deploy
on
tags.
So
those
are
going
to
be
like
four
or
five
iterations
forward,
but
I
just
want
to
keep
those
things
in
mind.
B
B
That,
like
it,
can
be
a
component
of
the
whole
deployment
process
right
like
it,
it
can
be
dog
food,
but
it's
just
not
the
like.
You
can
dog
food
at
this
moment.
I
guess
that's
what
I'm
trying
to
say.
The
other
thing
that
sid
mentioned
that
I
didn't
really
have
the
time
to
look
into
is
spinnaker
apparently
spinnaker.
Does
this
really
well,
and
I
see
that
you
already
looked
into
some
competitive
landscape
there?
B
A
It's
tricky
because
nobody
calls
this
the
release
chain,
but
they
call
it
like
safe
deployments
or
deployment
queuing
or
deployment
schedules.
So
that's
what
took
me
a
really
long
time
to
like
yeah.
How
do
we
articulate
what
release
trains
are
to
the
market
because
the
market
is
like?
Oh,
I
just
want
to
schedule
and
sync
with
my
deployments
or
if
I'm
truly
cd,
I
want
to
schedule
and
sequence
each
change
I'm
making,
because
people
are
committing
straight
to
production.
You
know
like
in
their
in
their
minds
right
yeah,.
A
For
me,
this
is,
this
is
still
the
merge
trains
functionality,
but
it's
going
to
be
merge
trains,
scope
to
environments
so
that
we
sequence
all
the
commits
for
a
particular
environment
in
the
same
order,
and
then
we
batch
them
and
we
run
them
through
their
release
pipeline
to
go
to
the
end
production
state.
So
that's
what
I'm
thinking
we'll
position
this
as
like
in
the
market
and
then
it'll
combat
against
all
the
deployment
queuing,
the
dependencies
that
other
competitors
are
doing.
A
I
think
it's
it'll
afford
us
a
great
amount
of
attraction
from
our
ci
users
trying
to
transition
to
cd,
because
if
they're
already
adopting
merge
trains,
then
this
is
like
a
natural
extension
of
their
current
process.
Rather
than
introducing
this
thing
called
release
train,
which
is
also
what
agile
thinks
of
when
they
think
of
safe-
and
I
want
to
like
not
have
that.
I
don't
want
to.
A
I
don't
want
people
to
look
at
them
like
oh
they're,
trying
to
be
safe
at
gitlab.
No,
no!
No!
That's
not
one,
not
what
we're
trying
to
accomplish
here,
but
I
love.
I
love
this
name
of
release
trains.
I
think
it's
great
from
an
internal
nomenclature,
but
in
the
in
the
market,
we'll
probably
talk
about
this
as
a
safe
deployment
for
merge
transfer
environments.
B
Yeah,
but
that's
that's
the
general
problem.
I
have
general
with
with
our
merchant
trains.
It's
really
a
mouthful
like.
If
you
talk
about
merge
trains,
you
need,
how
do
we
call
it
the
detached
pipelines
as
well
right
like
merge?
I
forgot
the
name
even
like
it's.
A
super
long
name
merge
with
pipeline.
B
A
Right
and
one's
a
positioning
thing
and
go
to
market
and
how
we
name
the
future
and
the
others
like
how
it
actually
works
in
practice.
So
they
may
be
completely
different
features
on
the
back
end
and
working,
and
we
may
continue
to
call
them
release
trains.
It's
just.
I
want
to
be
mindful
of
how
this
is
when
people
are
using
spinnaker
and
they're
using
deployment
sequencing,
which
is
what
it's
called
on
the
spinnaker
side
or
they're
using
circle,
ci
and
they're
using
deployment
queuing.
A
B
This
was
amy
delivery.
I
mean
not
my
idea,
okay
to
be
clear.
This
is
sid
mentioning
things
and
then
me
thinking
about
it
and
then
me
getting
alessio.
Who
was
thinking
about
this
and
it
just
kind
of
tied
a
couple
of
ends
because
we
did
think
about
how
can
we
actually
speed
this
up
couple
of
months
ago,
but
we
decided
to
hold
for
kubernetes,
because
kubernetes
allows
us
to
do
some
of
these
things
much
much
much
quicker
for
gitlab.com,
and
now
that
sid
mentioned
this
specific
sync
sequencing.
B
Actually
ties
really
well
with
what
we
just
discussed
earlier
and
as
kubernetes
is
now
rolling
out
to
dot
com.
We
are
seeing
like
significant
drop
in
deployment
times,
and
it
allows
us
to
maybe
think
about
these
things
and
we
get
some
things
for
free,
for
example,
in
kubernetes,
where
we
can
roll
things
out
independently.
B
We
have
multiple
clusters
already,
so
we
can
roll
out
multiple
different
changes
to
different
users
without
a
seriously
significant
investment
in
new,
tooling
or
whatever
right
like
we
already
have
coming
or
get
for
free
from
for
kubernetes,
so
some
of
its
lists
right,
cool
anyway.
Yes,
let
me
know
when
you
have
the
link
for
this
and
always.