►
From YouTube: Continuous Delivery and InnerSource - Why you Should be Doing Both - Tom Sadler & Steph Egan, BBC
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Continuous Delivery and InnerSource - Why you Should be Doing Both - Tom Sadler & Steph Egan, BBC
Virtual Track
Speakers: Steph Egan, Tom Sadler
Continuous Delivery and InnerSource are two software engineering practices that aim to increase quality and break down organisational barriers. It may come as no surprise, then, that these practices can really compliment each other. Continuous Delivery makes InnerSource contributions seamless, and gives contributors confidence in the stability of the project. Continuous Delivery tooling is often a good candidate for InnerSource because it solves common problems, and allows consumers to contribute features they require for their specific use cases. This case study of BBC iPlayer & Sounds looks at how InnerSource projects are Continuously Delivered, how Continuous Delivery tooling is opened up to collaboration via InnerSource, and what impact this has.
A
Hi
everyone
I'm
tom
sadler,
I'm
a
software
engineering
team
lead
in
bbc
iplayer
and
sounds
and
a
board
member
of
the
inner
source
commons
foundation.
My
co-presenter
steph
eagan
is
a
principal
software
engineer
and
we
are
both
leaders
on
inner
source
and
continuous
delivery
practices
within
iplayer
and
sounds
and
across
the
wider
bbc.
A
So
we
previously
did
a
version
of
this
talk
entitled
inner
source
and
devops
like
chips
and
gravy.
Continuous
delivery
is
a
key
part
of
devops
and
we
believe
these
practices
work
extremely
well
together
for
anyone
not
from
the
north
of
england
or
from
canada,
we'd
highly
recommend
you
try
chips
and
gravy
and
we
also
recommend
you
try
continuous
delivery
within
a
source.
A
A
So
what
is
a
source
inner
source
is
the
use
of
open
source
best
practices
for
software
development
within
the
confines
of
an
organization.
So
what
this
kind
of
looks
like
in
practice
is
much
like
with
open
source.
You
have
contributors,
making
pull
requests
into
software
projects
and
the
trusted
committers
reviewing
feeding
back
and
merging
these
in.
B
Next,
I'm
going
to
talk
about
our
continuous
delivery
journey
so
far,
so
the
bbc
has
moved
to
a
devops
model
when
we
moved
over
into
using
cloud
services
and
suddenly
all
our
teams
had
the
freedom
but
also,
more
importantly,
the
responsibility
to
control,
not
just
our
applications,
but
also
the
infrastructure
that
they
were
built
on,
and
we've
spent
the
last
five
years
working
out.
What
that
means,
teams
manage
their
own
ci
cd
infrastructure,
how
their
applications
are
deployed,
what
they're
deployed
on
and
they
support
the
whole
application
out
of
hours.
B
My
team
delivery
engineering
was
created
in
response
to
that.
How
do
we
help
these
teams
move
faster
and
have
better
engineering
practices
overall,
we're
part
of
a
group
of
support
teams
who
help
in
all
areas
of
devops.
You
could
maybe
call
us
site
reliability.
Engineering,
if
you
put
all
of
those
teams
together,
delivery
engineering
has
been
around
for
almost
three
years
now
and
we
use
a
couple
of
techniques
to
help
teams
in
iclear
and
sounds
first.
We
build
tooling
that
we
see
solves
problems
that
a
lot
of
teams
are
having,
and,
secondly,
our
subject
matter.
B
B
If
you
haven't
seen
these
before,
they
came
out
of
a
large
amount
of
research
by
the
devops
research
and
assessment
or
dora,
and
you
can
read
up
on
them
in
the
state
of
devops
reports
or
in
the
accelerate
book,
which
I
would
highly
recommend.
So
those
four
key
metrics
are
deployment.
Frequency
change,
lead
time,
mean
time
to
recovery
and
failure
rate,
and
I'm
not
going
to
go
into
the
specifics
of
those
today.
B
First,
we
make
our
services
as
easy
to
use
and
integrate
with
as
possible.
This
means
removing
any
as
many
barriers
to
entry
as
possible,
often
creating
more
work
for
ourselves,
so
that
other
teams
don't
have
to
do
it.
One
of
our
most
popular
services
we
provide
was
called
proxy
and
it's
really
simple.
It
just
provides
some
authentication
on
top
of
s3,
but
this
allows
teams
to
make
internal
tooling
easier,
and
everyone
thinks
it's
great
just
because
they
don't
have
to
talk
to
us
before
they
install
it.
They
can
just
use
it.
B
A
So
deployment
tracker
is
one
of
the
tools
made
by
delivery
engineering.
This
is
a
system
which
tracks
iplayer
and
sound
software
deployments,
and
the
data
is
used
for
measuring
deployment
frequency
and
lead
time.
This
data
can
be
used
for
other
things.
For
example,
there
is
an
inner
source
contribution
made
to
deployment
tracker
to
integrate
with
our
monitoring
systems,
so
that
graphs
could
include
annotations,
showing
which
component
was
deployed
to
what
environment
at
when
at
what
time.
A
This
example
shows
the
launch
time
of
our
tv
applications
and
using
the
deployment
annotations.
We
can
easily
see
if
release
has
had
an
impact
on
this.
Having
this
detailed
understanding
of
how
our
software
is
behaving
in
production
is
exactly
the
type
of
things
we
need
when
we're
continuously
delivering
software.
A
So
moving
on
to
my
experiences
from
the
maintainer
side,
so
I
work
on
the
iplayer
and
sounds
connected
tv
applications
so
connected
tvs,
smart
tvs,
setup
boxes,
games
consoles
and
other
streamer
devices,
and
these
tv
apps
are
composed
of
many
shared
libraries
that
are
maintained
by
a
number
of
teams
with
responsibilities
split
by
functionality,
for
example,
my
team
develops
and
maintains
the
initial
application
launch
and
user
sign
in
so
organizationally.
It
looks
a
little
bit
like
this,
where
we
have
in
this
kind
of
example.
A
A
Coming
back
to
deployment
tracker
and
its
release
annotations,
the
shared
pipelines,
deployment
tracker
integration
as
an
example
of
a
classical
source
benefit.
Many
teams
benefit
from
features
added
to
the
shared
project,
in
this
case
the
shared
project
being
the
pipeline
and
allowing
contributions
to
the
pipeline
unlocks
many
more
opportunities
such
as
this
work,
where
the
operability
guild
added
telemetry
around
how
long
the
pipeline
was
taking,
and
this
is
a
sort
of
feature
that
might
never
have
happened
if
we
didn't
allow
contributions.
A
So,
to
summarize
why
we
in
a
source
pipeline
product
development
teams,
can
contribute
to
the
infrastructure
that
releases
their
code,
there's
less
demand
on
the
pipeline
owners.
My
team's
time
increases
the
reuse
of
continuous
delivery
infrastructure
for
common
functions
in
the
tv
application
space,
so
that
teams
can
spend
more
time
on
product
development.
B
First
up
continuous
delivery
is
hard
thinking
about
your
application,
its
infrastructure,
how
you
deploy
it
all
requires
a
lot
of
knowledge
and
experience
to
get
right
and
a
two
pizza
sized
team.
It
just
isn't
doable.
Sometimes
building
tooling,
that
any
team
can
use
will
mean
that
they
can
think
a
little
bit
less
about
these
areas
and
accelerate
them
in
their
real
focus,
which
is
building
great
applications.
B
B
Finally,
continuous
delivery
is
personal,
although
there
are
lots
of
common
problems.
No
one
team
works
the
same
way
and
I
don't
think
that
we
should
be
forcing
any
team
to
work
in
a
specific
way.
The
tools
my
team
builds
have
to
deal
with
a
lot
of
completely
different
ways
of
working.
The
change
lead
time
for
one
team
is
not
quite
the
same
as
another.
B
Inner
source
allows
us
to
be
open
and
honest
about
the
figures
we
produce,
but
also
allows
teams
to
make
more
accurate,
make
things
more
accurate
for
themselves
if
they
need
to
cover
a
specific
use
case.
They
can.
One
example
of
this
was
a
contribution
to
add
time
selection
to
our
metrics.
Viewing
website
we'd
written
this
off
due
to
time
constraints,
but
one
team
really
wanted
it
and
they
were
able
to
contribute
that
feature.
And
now
everybody
benefits.
B
So
to
summarize,
why
should
you
in
a
source,
your
continuous
delivery,
tooling
teams
can
focus
more
on
where
their
expertise
is
building
great
applications.
It
brings
everyone
up
to
a
base
level
of
practice
irrelevant
of
their
skill
level,
and
teams
can
have
more
say
in
the
direction
of
the
tooling
that
they
use.
A
A
A
A
A
This
two-way
visibility
is
very
helpful
when
working
in
a
source
automated
releases
are
enabled,
via
structured
versioning
labels,
on
the
pull
request
and
our
pull
request
template.
This
enables
the
release
generator
to
determine
the
version
number
populate.
The
release
notes
from
the
pull
request
body
signal,
whether
the
release
includes
an
or
any
audience
facing
changes
and
includes
a
link
to
the
jira
ticket.
A
You
can't
merge
unless
the
branch
is
up
to
date
with
master
and
has
passed
our
automated
tests,
which
reduces
the
risk
of
bugs
being
caused
by
conflicts
across
branches,
and
you
can't
merge
unless
the
relevant
labels
are
present
present
and
the
pull
request.
Template
has
been
filled
out
to
enable
the
automated
release
notes.
A
So
this
is
the
process
when
you're
working
on
tv
client,
regardless
of
whether
you're
making
an
inner
source
contribution
or
working
in
your
own
area,
the
main
difference
being
who
does
a
code
review
and
the
automated
release
notes
enforce
consistent
visibility
of
work
on
tv
client
across
the
teams.
This
makes
contributing
to
tv
clients,
seamless.
A
A
So
to
summarize,
why
should
you
continuously
deliver
your
inner
source?
It
means
that
all
teams
have
visibility
of
each
other's
work.
It
means
that
shared
code
is
continuously
integrated
and
deployed
for
all
consumers.
You're,
not
leaving.
Anyone
behind
quick,
reliable
deployment
encourages
inner
source
contributions
and
continuous
delivery
gives
confidence
to
potential
adopters
contributors
to
your
in
the
source
project.
B
I
hope
that
we've
shown
that
both
continuous
delivery
and
inner
source
results
in
higher
quality,
better
documented,
better
supported
code,
and
I
hope
to
leave
you
today,
looking
to
in
a
source
your
continuous
delivery,
tooling,
by
solving
common
problems
once
and
self-serving.
Your
release,
software
and
also
to
continuously
deliver
your
inner
source
projects,
make
contributions,
seamless
and
have
confidence
of
stability
and
production.