►
From YouTube: Increase Agility and Quality Using Trunk-Based Development in Continuou... Hope Lynch & Logan Donley
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Increase Agility and Quality Using Trunk-Based Development in Continuous Delivery - Hope Lynch & Logan Donley, CloudBees
JW Grand Ballroom 2
Speakers: Hope Lynch, Logan Donley
Jump into this fast-moving and practical discussion to dig into how you and your peers can use a single mainline of source code to manage continuous delivery with greater agility and higher quality.
A
All
right,
we
are
we're
going
to
get
started
so
good
morning.
Everybody-
and
first
thing
I
want
to
say,
is:
I
hope
you
know
what
you
signed
up
for,
because
this
is
a
bird
of
a
feather
session,
which
means
we're
going
to
wander
around
we're
going
to
ask
questions
and
we're
going
to
hope
that
you
also
have
questions
or
comments
to
make
during
the
sessions,
because
that's
the
whole
basis
of
birds
of
a
feather.
B
C
B
A
Thank
you
hope,
lynch
senior
director
platform
at
cloudbees.
I
am
responsible
for
understanding
voice
as
a
customer
understanding
our
product
vision,
our
product
direction,
giving
input
to
sometimes
our
customers
on
how
they
can
use
our
products
more
successfully.
I
have
a
background
in
product
management,
agile
transformation,
consultation,
pretty
much,
you
name
it
in
technology.
I've
done
it
at
one
point
or
another.
So
with
that,
let's,
let's
roll
through
logan,
I
think
you've
got
the
first
one
yeah.
B
So,
since
we're
talking
about
trunk-based
development,
we
want
to
start
with
just
a
little
bit
of
background
on
the
different
branching
strategies.
So
without
a
branching
strategy
in
place,
everything's
a
bit
chaotic
right,
we
have
merge
hell
where
it's
like.
If
hope's
writing
some
code,
I'm
writing
some
code,
we're
both
trying
to
merge
it
into
the
same
the
main
line
we
end
up
in
a
situation
where
we
have
a
lot
of
conflicts,
and
it
just
takes
a
lot
of
time
and
so
back
in
2010.
B
There
was
this
idea
called
git
flow,
which
was
created
and
what
git
flow
is
all
about
is
moving
kind
of
the
the
main
line
from
the
main
branch
to
a
development
branch,
and
so
that
means
our
main
branch
is
always
going
to
be
stable
right.
I
can
deploy
that
at
any
point
in
time
and
it's
safe
and
the
approach
is
then
we
have
this
develop
branch
where
everybody
forks
off
of
this
or
branches
off
of
this
and
they
have
their
own
feature
branches,
and
so
that
works
really
nicely
at
large
scale.
But
it's
very
complicated.
B
You
have
feature
branches,
you
have
development
branches.
You
have
release
branches,
hotfix
branches,
it
gets
quite
intense,
and
so,
when
you
try
to
do
cincd,
it
just
ends
up
really
blowing
up
the
amount
of
work
you
have
to
do
and
so
github
came
along
and
said
all
right.
We
like
the
ideas
here,
we're
going
to
build,
what's
called
github
flow,
very
creative.
What
they've
done
is
they've,
basically
removed
all
of
the
develop
branch
and
the
release
branches,
and
so
now
the
main
branch
is
the
main
line.
So
everybody
contributes
basically
forking
or
sorry.
B
B
Everybody
works
off
of
the
main
line
or
the
the
main
branch,
but
we
have
a
very
strict
way
that
we
operate
to
ensure
that
we
don't
have
merge
conflicts
and
the
way
that
you
do
that
is
you
consistently
push
and
pull
code
you're
not
going
to
sit
there
where
you
know
hope
is
going
off,
I'm
going
off.
We've
each
got
our
own
separate
workflows
and
we're
keeping
those
lines
separate
for
months
on
end.
This
is
really
the
idea
of
you
know.
B
If
any
of
you
look
to
the
actual
definitions
of
continuous
integration
and
all
the
rules
kind
of
associated
with
it,
one
of
them
really
is.
You
should
be
contributing
code
back
to
your
main
branch,
essentially
every
day,
maybe
even
multiple
times
a
day.
Think
about
ci,
it's
not
the
tooling.
It's
continuous
integration.
B
D
A
A
E
A
A
F
F
Yeah
some
other
teams
like
ours.
I
work
in
develop
experience
there.
We
can
push
through
it
directly
to
the
main
branch
and
just
keep
integrating
through
our
team
order.
Teams
prefer
actually
having
pre-request
reviews
into
maine
just
released
from
there
automatically
as
well.
So
there's
a
really
large
mix
of
where
people
are.
Some
people
are
actually
not
comfortable
with
trunk.
A
I
have
a
follow-up
question
for
you
sure,
so
is
anyone
in
your
organization
using
future
flags,
because
I
have
a
sneaking
suspicion
that
sometimes
trunk
based
development
is
not
used
because
people
are
worried
about
what
goes
live
in
production.
And
how
can
I
roll
it
back?
But
if
you're
using
future
flagging
that
eliminates
part
of
that
problem.
F
Some
teams
do
use
future
flags.
We
are
just
about
implementing
actually
rollouts
with
canary
a
b
and
blue
green,
mostly
trying
to
do
the
canary
part
of
it
first,
so
we
can
affect
a
smaller
set
of
customers,
but
the
still
work
in
progress
is
a
very
big
too
many
teams
and
it's
kind
of
hard
to
change
the
whole
company.
How.
A
G
Yeah,
we
were
I've
been
there
for
four
years.
We
were
using
kind
of
a
hybrid.
When
I
first
got
there,
we
were
using
develop
as
trunk
and
then
it'd
be
a
move
to
master,
and
then
we
eventually
went
all
to
trunk
based
we're,
not
cd,
mostly
because
of
resource
constraints,
to
get
the
testing
up
to
stuff
to
be
able
to
go
that
fast.
But
we
have
the
tool
most
of
the
tooling
in
place.
It's
just
a
matter
of
getting
the
business
processes
and
testing
processes
being
capable
of
keeping
up
with
it.
G
Yeah
we
still
have
a
qa
team.
Most
of
the
most
of
the
constraints
have
been
on
feature
testing
and
stuff,
like
that.
Like
unit
testing
is
pretty
up
to
snuff,
but
it
doesn't
doesn't
catch
enough
to
be
able
to
depend
on
it.
There's
an
effort
to
build
out
automated
integration
tests,
but
just
haven't
had
enough
resources
to
invest
in
it
to
get
it
there.
A
H
So
I
say
the
main
reason
we
don't
do
trunk
based.
We
do
like
short-lived
feature
branches
is
that
we
do
pull
requests
and
reviews
right
so
and
that's
sort
of
my
main
concern
about
trunk
is
like
bases
like:
when
do
people
review
it
so
yeah,
all
of
our
all
of
our
pr?
All
of
our
you
know.
Mergers
to
our
main
branch
are
reviewed
by
teammates.
A
H
B
To
that
I
think,
that's
technically
still
trunk
based
development
by
the
like.
If
you
go
to
trunk
based,
development.org
or
whatever
it
is,
they
have
a
scaled
trunk-based
development,
which
is
exactly
that.
It's
it's
short-lived.
It's
like
you
know,
you
don't
have
people
sitting
next
to
you,
so
they
can't
code
review
directly,
but
you
spin
up
a
pull
request
and
then
they'll
look
at
that.
B
E
That's
always
been
my
main
question,
like
you
know,
we're
actually
in
the
middle
of
a
pretty
big
re-architecture
of
our
repo.
So
it's
pretty
major
changes
and
if
you
just
merge
that
into
the
trunk
and
then
it
goes
to
the
pipeline
and
it's
all
screwed
up
for
whatever
reason:
how
do
you
unscrew
that,
like
what
does
that
process?
Look
like.
B
To
release
this
right
now,
it's
like
all
right,
whatever's
in
maine,
just
push
it.
The
other
one
is
just
don't
break
the
build,
so
basically,
never
like
their
whole
idea
is
just.
You
should
never
merge
something
that
causes
an
issue,
and
so,
if
you
do,
you
should
have
a
ci
job
in
place.
That
will
see
that
that,
like
main
branch,
the
the
test
broke
and
it'll
just
roll
back
and
back
out
the
change
automatically
so.
E
A
A
It
was
a
scramble
and
it
was
stressful,
but
all
of
the
lessons
learned
while
we
went
through
that
and
we
and
we
tested
it
initially,
of
course,
on
a
very
small
team
of
about
eight
to
ten
people,
but
once
we
got
through
it
and
we
learned
what
the
patterns
were
and
we
learned
what
our
processes
should
be
and
a
lot
of
it
was
down
to
team
agreements
right.
You
come
down
with
your
your
team
agreements
on
the
agile
team.
A
D
D
We
do
capability-based
hiring
and
we
do
lots
of
training
and
ongoing
education,
and
so
I
think
there
is
and
we're
very,
like
risk-averse,
very,
very
risk-averse
organization,
and
so
I
think,
there's
a
lot
of
ideas
that,
like
you,
have
to
have
certain
reviews
and
other
things
in
place,
because
we
have
such
a
such
a
wide
range
of
people
who
might
be
like
just
starting,
never
coded
before.
Right
are
learning
how
to
do
it,
but
are
involved
in
the
processes
versus
people
who
are
really
experienced.
D
D
A
A
Oh,
we
are
having
it.
You
know
what
I'm
just
going
to
stick
with
this
slide,
because
it's
it's
going
bananas,
but
so
for
trunk
based
development
based
on
what
we
have
talked
about.
Is
there
anyone
who
now
thinks?
Maybe
you
are
doing
some
form
of
it
in
your
organization,
but
you
you
just
didn't
really
think
that
you
were
doing
trunk
based
development.
A
So
if
you
are
in
an
organization
where
the
conversation
comes
up
that
your
resource
constrained
well,
we
can't
do
that
because
we
don't
have
enough
people
looking
at
trunk
based
development
actually
could
be
one
of
the
solutions.
You
may
not
need
more
people.
You
just
may
need
to
change
your
processes
and
your
branching
strategies.
A
B
F
So
those
are
complications
that
you
are
not
really,
if
your
pipeline's
not
mature
enough
to
to
fail
fast
and
safe,
like
it
doesn't
matter
much
like
which
floor
you're
using
it's,
probably
why
you
should
put
the
time
there
and
for
the
whole
merch
straight
to
maine,
which
some
of
our
teams
do.
It's
really
like.
A
Absolutely
so
a
few
of
the
comments
that
have
come
in
not
really
any
questions,
but
one
that
made
me
laugh
a
little
bit
from
the
theaters
we
are
trying
here.
Git
flow
is
dragging
us
so
that
that's
great,
but
a
lot
of
the
comments
I
think
are
in
line
edward.
They
switch
from
git
flow
to
trunk
a
few
years
back,
some
in
the
organization
that
want
to
go
back,
but
the
pipeline
was
extremely
complicated.
A
Basically,
like
you
had
mentioned
logan,
you
know
the
coordination
that's
required
if
you're
not
doing
trunk
is
a
lot
comments
on
pr
is
needed
for
some
audit
compliance.
Yes,
basically,
trust
verify
from
joel,
let's
see
joel.
In
addition,
by
doing
prs,
you
can
feed
metadata
to
the
life
cycle
of
that
change,
for
example,
approvals,
cascade
through
cicd,
additional
employee,
metadata,
etc.
That's
also
a
good
point
process
is
up
to
the
development
team
and
the
process
is
standardized
and,
more
importantly,
document
it.
The
least
favorite
thing
in
any
organization.
A
A
How
many
meetings
we
had
to
go
in
and
have
a
discussion
about
what
the
process
actually
should
be,
because
now
you
know
now
the
world
is
very
different.
What
should
we
do?
Instead?
It
took
a
lot
of
meetings.
There
were
a
lot
of
complaints
from
a
lot
of
people
who
said
you
know
I'm
in
this
meeting.
I
could.
A
I
could
be
writing
code
and
some
people
who
just
wanted
to
be
heads
down
all
day
and
not
have
a
conversation
with
anyone
that
was
really
tough
for
them,
but
once
we
got
through
it,
they
were
able
to
spend
more
time
heads
down
versus
having
so
many
meetings
so
that
so
that
did
work
well.
Why?
Thank
you,
joel
documentation
is
always
the
hardest
in
any
way
that
that
can
be
automated
a
bit
definitely
is
a
help,
any
other
thoughts
or
questions
on
trunk
based
development.
I
I
am
the
third
engineer
on
a
team
of
three
engineers
great.
We
moved
to
like
something
akin
to
trunk
based
development
still
using
github
prs,
because
security
et
cetera
one
issue.
I've
noticed,
is
that,
like
it
seems
like
the
thing
that
trunks-based
development
is
trying
to
do
is
reduce
the
risk
of
conflict
from
like
diverging
branches
right,
so
that
still
requires
like
getting
prs
approved
and
not
letting
them
live
for
weeks,
which
sometimes
happens.
But
I'll
say.
The
thing
that
really
like
made
us
move
towards
always
be
ready
to.
I
C
A
A
A
There
were
a
lot
of
people
using
a
lot
of
things
that
just
did
not
work
with
the
flow
that
we
were
trying
to
do.
You
don't
have
to
take
away
the
independence
of
choice
that
people
have,
but
the
process
has
to
be
similar
enough
that
if
someone
doesn't
come
to
work
one
day
or
they
leave
or
you
know
whatever
someone
else
can
look
at
and
say
you
know
what
I
get.
What
was
going
on
here
or
maybe
read
the
documentation
and
understand
it.
A
Some
folks
and
again,
I'm
gonna
say
you
know
if
you've
got
a
cowboy
on
your
team,
like
the
guy
with
the
red
light,
we
had
a
lot
of
it.
Was
he
basically
said
you
know
what
I
see
what
we're
doing
here,
I'm
going
to
do
a
little
bit
of
it,
but
everything
else,
I'm
just
going
to
do
it
my
way,
which
basically
was
a
lot
like
the
old
way
we
were
doing
it
so
that
caused
a
lot
of
complications.
A
B
B
I
don't
think
there's
any
anything
super
specific
on
number
of
commits,
but
there
is
a
trunk
base.
What
is
it
trunk
based
development.org
or
something?
It
has
like
a
million
different
pages
that
give
a
bunch
of
advice
going
like
30
years
back,
but
it's
yeah,
I
think
really.
The
key
is,
is
just
making
sure
that
as
many
times
per
day,
you're
pulling
and
syncing
your
local
from
the
remote.
B
A
Have
a
comment
here
from
steve:
if
your
team
is
using
prs,
it
is
worth
checking
the
time
it
takes
for
prs
to
be
approved
to
ensure
no
team
member
is
waiting
longer
than
any
other.
I
had
a
team
where
one
developer
was
looking
really
slow,
but
they
were
waiting
three
times
longer
for
prs
to
be
approved
so
yeah
having
something
that
alerts
you
that
prs
are
sitting
and
and
getting
stale
is,
is
definitely
important.
A
Joel
says,
as
a
manager
leader,
I
usually
look
to
these
metrics
as
gauge
to
investigate
issues
versus
labeling
engineers
is
slow.
We
should
be
looking
at
scenarios
like
this
and
figuring
out.
Why,
for
example,
an
issue
I
had
like
this
turned
out:
we
had
resources
in
serbia
when
they
worked.
It
was
essentially
our
early
hours.
Their
prs
were
lost
in
the
morning
hours,
and
you
know
that
is
a
great
observation.
A
The
team
I
had
at
that
time
the
majority
were
in
the
u.s.
We
had
two
in
the
czech
republic
and
one
in
germany,
but
we
were
working
similar
enough
hours
that
it
wasn't
a
concern,
but
I
imagine
if
you
have
a
team,
that's
globally
distributed
and
everyone
is
working
different
hours,
making
sure
those
prs
aren't
sitting
there
and
getting
stale
for
the
people
who
maybe
are
working
working
opposite
hours
of
you
definitely
would
need
a
process.
So
I
definitely
thank
you,
steve
and
joel
for
that
input.
J
A
So
the
team
I
worked
with
at
the
time
we
decided
on
different
levels
of
things
that
needed
approval
right.
It
was
some
of
it
was
risk
based.
Some
of
it
was,
you
know,
magnitude
of
change
based,
but
we
tried
to
make
it
so
that
the
bare
minimum
stuff
actually
needed
a
pr.
Sometimes
if
it
was
somebody
who
was
really
really
new.
A
Theirs
would
get
reviewed,
maybe
for
the
first
two
to
three
months,
but
after
that
it
was
just
based
on
the
categorization
that
we
had
come
up
with,
and
when
you
made
your
pr,
you
know
it
went
into
that
category
because
they
had.
You
know
they
had
to
indicate
on
the
pr
which
one
it
was
so
it
would
do
some
automated
filtering,
but
it
wasn't
that
anyone
sat
and
had
to
look
at
each
one
and
then
two
on
a
rotating
basis.
This
was
some
people's
favorite
job
and
I
say
that
not
sincerely.
A
We
tried
the
thing
where
you
know
a
certain
person
is
assigned
to
do
the
review,
but
it
quickly
dropped
their
velocity
like
through
the
floor,
trying
to
go
in
review.
The
pr
suggest
changes
all
of
that
they
really
couldn't
do
work.
So
we
moved
more
to
something
where
if
there
was
someone
who
did
a
similar
type
of
work
more
often
they
would
be
asked
first
because
they
could
look
at
it
more
quickly
because
they
almost
had
sort
of
a
intuition
about
it
at
that
point
and
they
could
go
through.
A
B
Just
add,
like
one
thing:
we
work
with
our
customers
on
is
exactly
having
the
preview
environments,
so
whenever
you
commit
like,
if,
if
let's
say
I
want
to
share
my
code
with
you
or
I
added
some
new
feature
to
the
front
end,
I
want
you
to
be
able
to
visualize
it.
I
would
then
create
a
short-lived
pr.
The
ci
job
would
kick
off.
You
know,
do
all
the
testing,
but
also
spin
up
a
short-lived
environment
that
you
could
go
look
at.
I
could
commit
some
changes.
You
could
create
some
changes.
J
B
You
can
do
it
full
stack
as
well.
It's
just
you
know
it
gets
tricky
depending
on
your
environment,
but
if
you
have
like
helm
charts
that
say
you
know,
I've
got
my
backend,
it
also
spins
up
database.
I
can
initialize
some
fake
data
like
we
do,
have
people
doing
that
full
stack
sure
it
just
depends
on.
You
know
it's
like
some
front-end
stuff.
I
can
use
like
mock
service
workers.
Things
like
that
that
just
totally
fake
out
the
back
end.
So
it's
not
really
needed
but
yeah,
depending
on
what
you're
doing
absolutely
yeah.
A
Comment
from
edward,
which
basic
basically
syncs,
with
what
you
were
saying,
logan
for
our
org,
we're
looking
into
deploying
a
short-lived
environment
for
a
pr.
We
will
then
run
qa
automation
on
that
environment
and
the
pr
will
get
approved
based
on
the
outcome
of
that
test,
along
with
the
usual
peer
approvals,
so
yeah
that
works
out.
I
think
we
might
almost
be
at
we're
actually.