►
From YouTube: Delivery: Discussing deployment branching 2019-03-18
Description
John Jarvis and Marin Jankovski discuss automated deployment branching
B
B
B
Omnibus
knows
which
things
to
pull
from
based
on
the
version
files
inside
of
the
repository
of
omnibus.
So
you
know
omnibus
github.
You
have
get
early
version
version
files,
that's
get
lab
rails
version
file
pages
and
so
on
that
files,
those
files
get
get
updated
from
the
side
of
release
tools.
So
if
in
regular
branches
in
master
branch,
for
example,
all
of
the
version
files
have
master
for
each
of
the
components
when
we
actually
tagged
in
release
tools,
release
tools
will
check
the
version
files
based
on
the
gate,
lab
see
E
and
E
repository.
B
B
A
B
A
B
In
the
same
pipeline,
omnibus
github
gets
clones
and
that
specific
tag
gets
checked
out,
or
rather
whatever
is
in
that
specific
tag.
Inside
of
get
lab
rails
will
then
be
added
to
omnibus,
and
then
you
see
that
being
committed
so
get
commit
message.
Update
version,
211,
I
know
our
c7
and
the
tag
gets
pushed
right.
A
A
And
I
and
I
kind
of
put
in
this
issue
that
it's
just
basically
finding
the
last
green
commits
yep
right
on,
because
the
way
the
way
I
the
way
I
sketch
this
out
is
that
on
Sunday
we
look
for
the
last
green
commit
for
get
levy.
Ii
get
lab,
C
II.
We
create
the
new
branch
for
that
week
then,
and
then
we,
you
know,
kick
off
a
kick
off
a
build
yeah.
A
So
so
for
the
branch
name
and
the
tag
name,
this
is
where
it
gets
a
little
tricky.
I
think
we
want
I,
don't
think
we
want
to
use
major
and
minor
releases
at
all
like
I.
Don't
think
it
makes
any
sense
right
like
we
should
just
use.
We
should
know
now
since
and
I
was
just
gonna
say
like
year,
year
month
and
week
number
for
the
branch
like
that
and
I
know
you
don't
like
it,
but
give
me
a
better
idea
like
I.
Don't
have
I,
don't
have
any
other
suggestions
so.
B
A
B
What
what
I
think
is
important
for
us
to
know
is
in
which
part
of
the
cycle
we
are
at
so
you
know
major
minor,
might
not
be
offering
quite
a
lot
of
information,
but
it
does
allow
us
to
know
which
release
cycle
we
are
in.
So
this
is
why
the
version
file
should
have
been
updated
to
11.10
dot
P,
because
that
tells
us
we
are
in
1110
cycle
development
cycle
right
because
we
are
now
in
11
9
release
cycle.
A
So
for
the
branch
name,
I
initially
thought
I
would
do
major
minor
and
week
number,
as
the
branch
name,
because
you
need
to
have
is
we're
creating
a
new
branch
on
every
Sunday
right.
So
ask
me,
you
know
or
major
minor,
and
then
today,
like
year-month-day
I
mean
it
has
to
have
something
we
need
to
have
something
we're
creating
a
new
branch,
every
Sunday,
which
is
in
the
same
major
minor
release.
So
what
do
you
think
so.
B
Let's,
let's
just
step
a
tiny
bit
back
here
and
think
about
our
actual
goal,
because
this
is
right
now,
an
intermediate
step
right
like
this,
is
for
us
only
to
speed
things
up
a
bit
and
see
like
what
kind
of
breakage
we
have
we're
doing
yeah.
So
what
we
want
to
achieve
in
the
end
is
not
even
have
a
special
branch
right,
I've,
just
tagged
based
on
whatever
is
there
in
master
at
that
moment.
So.
A
B
I
think
it's
gonna
simplify
things
if
we
do
create
a
branch
right
now,
but
what
I'm
trying
to
say
right
now
with
this
stepping
back
is
what
kind
of
work
who
do
we
need
to
do
in
order
to
not
duplicate
that,
therefore,
effort
right
like
we
need
to
know
which
commits
we
want
to
actually
include
right,
and
we
need
to
be
able
to
do
that
in
an
automated
fashion.
So
what
skarbek
did
there?
A
A
B
B
Know
as
well
yeah,
but
we
need
what
kind
of
need
to
keep
it
in
perspective
and
expect
that
it
might
happen
so
that
we
don't
duplicate
work.
All
right.
Well
in
that
case
is
just
branch
naming
that
is
confusing
us
right
now.
So,
let's
think
about
what
would
need
to
happen
when
we
are
in
that
situation
will
be
branch
off
from
aster.
How
are
we
going
to
name
those
branches
to
begin
with
right.
A
How
do
we
determine
what
major
and
minor
is
major
is
probably
something
we
just
set
manually
and
whenever
minor
is
sort
of
just
like
tracks
to
the
month
right,
like
yeah,
could
probably
figure
it
out
automatically
based
on
what
month
you're
in,
but
then
I
was
thinking
like
well,
maybe
it
doesn't
matter
like.
Maybe
we
should
just
use
a
date/time
stamp
because,
if
we're
tracking
it
to
the
month
anyway
like
why
not
just
say
you
know,
year
month
and
then
week
number
and
that's
kind
of
where
I
landed
with
the
branch
name.
A
A
B
A
way
to
inform
people
of
where
we
are
at
in
the
process,
but
also
disconnect
them
from
the
old
way
of
thinking
where
we
were
tied
to
a
stable
branch
specific
to
a
specific
release.
I
mean
how
other
companies
do
it.
They
have
a
special
name
branches
right,
like
developed
or
three
or
whatever
else,
but
that's
just
a
slower
running
monster
honestly.
B
A
Think
I
think
most
other
companies
probably
would
deploy
from
the
tip
of
Master
and
then
create
branches.
Don't
demand,
and
also
we
kind
of
had
this
difficulty
right.
Where
we
had
multiple
I
know,
look
companies
had
multiple
repositories
like
we
do
it.
We
don't
deploy
independently.
Like
you
know,
we
kind
of
gather
everything
together.
First
yep,
hey
I,
actually
think
it's
it's
possible.
We
could
create
if
we're
basically
deploying
from
tag
not
from
branch
right
now
correct.
We
could
create
branches
on
demand.
A
I
think
the
problem
here
is
that
when
we
have
a
build
deployed
to
staging
and
a
developer
wants
to
seize
a
serious
regression,
he
needs
to
make
that,
mr
as
soon
as
possible,
having
the
branch
already
created,
makes
it
easier
like
he
can
just
go
home
for
the
developer,
to
create
an
M
R
against
master
and
an
mr
against
the
branch
that
he
knows.
So
he
knows
that
that
commit
will
be
picked
up
on
tomorrow's
builds.
A
Otherwise
we
agree
that
as
soon
as
he
spots,
the
regressions
he's
gonna
have
to
create
the
branch
and
we're
also
dealing
with
like
yeah
and
I.
Think
it's
pretty
guarantee.
Within
a
week
we're
gonna
have
yeah
I,
so
I'm,
I'm
kind
of
like
keep
on
coming
back
I
think
we
should
create
the
branches
in
advance
on
Sunday.
You
just
need
to
come
up
with
a
name
and
something
that
we
can
programmatically.
B
A
B
What
kind
of
problem
are
we
running
into?
We
want
to
do
all
of
the
automation
ourselves.
So
what,
from
the
developers
perspective,
I
would
love
to
not
have
to
think
about
the
branch
names
at
all
I
as
a
developer
would
like
to
always
target
master
branch
and
how
this
ends
up
in
a
release
is
not
my
problem.
I
want
to
be
able
to
show,
with
my
merge
request,
the
importance
of
having
this
deployed
as
soon
as
possible
right.
A
A
B
A
B
If
we
have
been
naming
branching
naming
so
the
special
branches
could
be
created
based
on
the
showers,
I,
don't
know
whatever
we
decide,
but
then
we
get
out
of
the
business
of
figuring
out
the
naming
for
this
longer
running,
slower
master
branch,
and
that
gives
us
also
very
much
closer
to
what
we
wanted
to
do.
To
begin
with.
Is
that
that's
that's
too
much
work
right,
I.
A
A
You
would
be
yeah
you
would
need
to
update,
but
you
kind
of
have
to
do
that
anyway,
right,
like
I,
mean
it
should
be
fine
like
you
should
you
should
be
able
to
just
update
on
Sunday.
You
just
take
your
basically
the
same
thing
we
have
now
you
take
your
stable
branch,
but
we
would
update
it
from
master
every
Sunday.
Now
the
disadvantage
is.
Is
that
let's
say
we
do
that,
then
that
bill
doesn't
go
anywhere,
there's
so
many
problems.
A
B
If
we
ensure
that
always
a
single
source
of
truth
for
developers
is
master,
then
they
don't
have
to
think
about
any
other
branch.
So
when
you
actually
do
a
fast
forward
for
that
weekly
branch,
theoretically,
none
of
the
work
is
going
to
be
lost,
or
rather
none
of
the
work
is
going
to
cause
a
merge
conflict
or
anything
like
that,
because
it's
a
classic
alert
right,
correct.
A
Yeah-
and
this
is
one
I
think
we
can
do
it
this
way-
I
just
like
yeah
I,
just
don't
know
if
it's
safe
enough
right.
Because
do
you
understand
the
kind
of
scenario
saying
like
you
know,
you
have
the
previous
week's
build
on
production,
then
it
comes
Sunday
and
then
you
update
whatever
the
latest
crap
is
on
master
and
then
that
gets
that's
like
VOA
doesn't
have
problems
right.
A
B
A
B
B
We
like,
whenever
the
conflicts
gonna
happen.
The
conference
are
going
to
happen
only
if
we
have
two
branches
changing
the
same
thing
and
we
are
not
right
like
that
branch.
The
only
difference
between
those
two
branches
is
timing.
Right,
like
some
things,
are
going
to
be
picked
before
others,
so
that
could
theoretically
go
around,
but
it
should
be
smart
enough
to
resolve
those
things
for
us,
because
we
only
have
a
small
slower
running
branch,
I.
A
Don't
know
like
okay
Sunday,
we
create
the
branch
on
Thursday.
We
find
the
regression
the
source
file
that
has
the
regression
when
toad
went
through
a
major
refactoring
on
master.
So
now
the
developer
creates
an
M
R
against
master,
but
when
he
created,
but
when
we
try
to
pick
that,
mr
into
the
branch
that
was
created
on
Sunday,
the
previous
Sunday,
there
could
be
conflicts
and.
B
A
A
A
B
A
B
A
Not
the
branch
yeah,
whether
it
has
the
major
and
minor
built
in
which
I
think
could
be
nice,
because
it
gives
you
some
context
for
where
we
are
in
the
release
cycle,
and
it
would
if
we
do
do
major
and
minor.
It's
really
a
matter
of
how
do
we
determine
what
the
minor
version
is
kind
of
tracks
with
a
month,
so
we
can
sort
of
like
based
off
of
what
month,
we're
in
and
then
other
than
major
and
minor.
You
need
some
other
identifier,
because
we're
gonna
have
like
three
of
these
branches.
A
B
A
Could
do
that
and
then
and
then
the
next
question
is,
is
like
what
do
we
tag
when
we
create
the
Omnibus
build?
What
will
the
tag
look
like,
and
that
is
like
another
unless
that
the
Omnibus
keeps
track
of
all
of
the
shah's
from
all
the
sources
which
it
doesn't
currently
keep
track
of,
like
the
versions
right
which
are
which
are
correspond,
the
tags
or
does
it
does
it
have
the
shah's
as
well
forget?
Does
the
Omnibus
have
like,
but
in
its
manifest
file
like
the
showers
of
he
does,
he
doesn't
have
older,
shows.
A
A
A
B
B
B
A
A
B
A
B
A
A
B
Basically,
you
can
see
you
can
have
the
slower
running
pipeline
ID
for
the
branch
as
in
on
Sunday
the
release
tools
automatically
created
this
branch
and
then,
when
it
actually
tagged
omnibus,
it
can
also
have
like
every
time
we
tagged.
It
has
the
in
the
tag
it
has
the
pipeline
ID
that
specific
tag.
So
we
have
consistency
across
branch,
slash
tag
and
you
can
always
an
idea
of
where
to
go
for
information.
If
you
do
need
to
go
to
get
information.
A
Okay,
just
make
sure
I'm
on
the
same
page
1110
week,
one
Sunday
night
or
Sunday
morning.
The
first
CI
job
kicks
off,
which
creates
the
branch
and
the
name
of
the
branch
will
be
11
10
and
instead
of
stable
Oh
have
the
pipeline
ID
of
the
release
tools
pipeline,
correct
the
branch
yeah.
So
now
it's
and
okay.
So,
let's
fast
forward
to
Monday
after
Sunday
so
Monday
the
branch
already
exists.
A
Now
we
have
this
job,
that's
going
to
build
a
new
package
to
get
it
to
staging
because
we're
doing
this
everyday
on
that
on
that
branch,
because
people
are
I
assume
like
everyday
people.
Are
tagging
em
ours
for
picking
in
their
release?
So
what
would
the
tag?
Look
like
it'd,
be
ten
dot,
10
11
or
something
the
pipeline
ID
of
that
branch
or
the
pipeline
idea
of
the
tag
so.
A
B
If
we
say
that
on
Sunday,
we
created
automatically
that
branch,
11th
and
pipeline
idea
right,
we
can
automatically
commit
this
to
omnibus,
and
then
we
don't
have
to
care
anymore,
because
every
time
we
want
to
tag
a
new
release,
it's
gonna
have
a
stable
branch
and
it's
just
going
to
always
pick
up
whatever
the
latest
is
in
there
and
we
can
name
the
tag.
Whichever
way
we
want,
we
don't
even
have
to
change
anything
honestly.
We
can
leave,
leave
the
same
package
name
that
we
currently
have
in
the
comment.
A
B
A
A
B
Has
a
version
file
inside
of
that
branch
and
that
branch
that
version
file
points
to
a
certain
end
point
in
master,
it's
going
to
be
master
in
developing
branches,
it's
going
to
be
whatever
users
or
developers
set.
So
if
we
say
that
this
new
branch
is
our
source
of
truth
and
version
file
says
it's
11
10
pipeline
ID,
every
time
you
trigger
a
built
is
going
to
be
created
in
this
format.
So
you
don't
even
have
to
tag
it.
You
can
just
have
things
running
in
in
schedule,
schedule
pipelines.
B
A
I
see
yeah
I
think
it
I
think
it
works.
I
mean
the
only
thing
I
don't
like
is
that
there's
a
bit
more
indirection
to
figure
out
like
I,
want
to
see
the
gate
live,
see
the
source
tree
for,
what's
to
put
it
on
staging
I.
Think
to
do
that
right,
I
would
need
to
check
out
the
commit
of
omnibus
look
at
the
version.
B
B
A
B
A
Oh
in
the
omnibus
pack-
yes,
yes,
yes,
we
do
like
right
in
this
Genki
a
crown
job.
Yes,
oh
yeah,
we
can
yeah,
no
I
made
it.
So
it's
finite,
initially
yeah,
it's!
So
the
idea
right.
We
can
pull
this
from
Prometheus.
This
gives
you
the
shower
versions
of
all
the
different
components:
yeah,
so,
okay,
I,
think
I'm
I
think
I'm
down
with
this.
So
basically
we
just
we
just
create
the
branch
every
Sunday
and
then
we
kick
off
an
omnibus
build
and
it
will
pull
the
latest
commits
and
like
getting
another
latest
yeah.
B
So
whatever
what
we
can
also
do,
is
we
say
that
whatever
gets
added
to
the
branch
right,
like
whatever
we
pick
into
there,
we'll
have
a
scheduled
pipeline
on
staging
once
a
day?
Creates
a
package
deploys
it
just
from
there.
Right,
though,
we
get
to
a
point
where
things
build
up
until
I,
don't
know
when
we
create
when
we
push
this
to
canary
and
then
when
we
push
the
canary,
we
just
kind
of
go
that
down
that
route
between
staging
and
canary,
deploying
those
things
and
then
come
Monday.
B
B
But
but
what
I'm
trying
to
say
here
is
we
are
all
of
a
sudden,
switching
not
all
of
a
sudden
sorry.
We
are
now
switching
from
caring
about
two
projects
to
caring
about
one
project
it
in
this
case,
and
it
would
be
up
to
the
developer
to
ensure
that
whatever
needs
to
happen
gets
into
master
of
Syria
and
II.
So.
A
B
B
A
B
B
A
B
Right,
so
this
is
where
I'm
thinking
that
I'm
probably
missing
in
educators,
but
this
is
where
I
was
thinking.
No,
this
is
where
I
was
thinking
we're,
depending
on
master
now,
so
whatever
ends
up
in
master.
This
is
where
we
create
like
weekly
branches
in
github
EEE
get
created
from
github
EE
master.
That
means
any
fix.
You
get
into
c
e
needs
to
go
into
master
of
c
e
and
merge.
A
The
I
see
so
you're
only
freezing
the
thing
is:
is
that
well,
okay,
I
I,
see
I,
see
where
you're
going.
It's
just
that
I'm
trying
to
make
sure
that
the
developer
handles
the
conflicts.
I'm
just
worried,
yep
master.
We
received
some
refactoring
during
the
week
of
a
source
file
that
needs
to
be
updated
and
we're
not
gonna
see
that
conflict
until
after
the
merge,
train-like
moves
the
commit
over
to
EE
and
then
we
try
to
end
them
and
then
I
guess
what
we'll
do
is.
A
B
So
that's
something
to
think
about,
but
maybe
not
this
very
moment
just
FYI
I
did
check
out
merch
train
and
it
shouldn't
be
that
big
of
a
deal
to
change
or
add
an
option
in
merge
train
to
instead
of
target
master
tag,
target
any
arbitrary
branch
that
we
want
to
supply
it
to.
So,
for
example,
we
could
theoretically
say
this
gets
extracted
into
environmental
variable
which,
if
an.
A
B
B
B
A
B
A
We
need
to
create
this
weekly
job
to
create
the
the
crew
to
create
the
branch
using
the
pipeline
ID
release
tools,
so
yeah,
yep,
okay,
great
I'll,
I'll,
write
up
what
we
talked
about
and
then
we'll
just
hopefully
get
I
think
we
I
mean
I,
think
we
can
start
this
week
unless
it
for
something
else.
You
know
start
this
week.
This.