►
From YouTube: Enable a Pipeline As Code Capability for 12,000 Developers - Jimmy McNamara & Aoife Fitzmaurice
Description
Enable a Pipeline As Code Capability for 12,000 Developers - Jimmy McNamara & Aoife Fitzmaurice, Fidelity Investments
Aoife Fitzmaurice and Jimmy McNamara take us through a journey on how Fidelity Investments plan to roll out a Pipeline As Code capability to 12,000 developers. Leveraging cloud based kubernetes platforms to ensure best operational outcomes the team is driven to enable this best practice capability across Fidelity. This capability is key to assisting the growth of both an innersourcing and open-sourcing culture throughout the firm.
Looking for something specific?
0:00 Introduction
1:16 Who's Fidelity?
2:21 Enabling ALM for the Enterprise
4:47 Principle for enabling a pipeline platform
5:36 Traditional vs DevOps Teams
7:04 Key principles
8:13 Measuring DevOps
9:15 Enabling value through self-service model
10:10 Reference Architecture
12:45 Pattern based pipeline as code model
14:48 Culture and challenges
15:22 Managing scale through Automation of DevSecOps
16:34 Lessons learned
17:31 Partner communication
19:04 Q&A
SUBSCRIBE CDF CHANNEL ►► https://tinyurl.com/y4e4434n
ABOUT US
The Continuous Delivery Foundation seeks to improve the world’s capacity to deliver software with security and speed. Learn more at https://cd.foundation/
A
A
Fidelity
we'll
talk
you
through
the
plans
we
have
for
the
area,
we'll
talk
to
you
through
a
description
of
our
area
and
the
principles
that
help
us
underpin,
enabling
this
capability
for
such
a
large
amount
of
developers
so
standard
disclaimer.
Here
just
to
make
sure
everyone
knows,
this
presentation
is
a
case
study
of
fidelity
investments
experience
it's
not
an
endorsement
or
recommendation
of
any
vendor
product
or
service.
A
B
A
Thanks,
eva,
okay,
so
start
a
little
bit
about
fidelity
itself,
so
fidelity
has
been
a
company
been
around.
You
know,
since
1946.
I
think
one
of
the
key
things.
That's
a
real
principle
and
a
belief
in
fidelities
is:
it
is
a
huge
enabler
of
business
differentiation
and
that's
been
something.
That's
been.
You.
B
A
A
We
are
an
enterprise
focused
service.
We
cover
a
large
amount
of
capabilities
right
from
the
point
of
inputting
code
into
your
source
code
management
scanning
that
code
and
delivering
it
out
via
pipeline
and
applying
it
out
into
your
target
environment.
We
we
manage
the
all
those
platforms
and
the
user
experience
across
those
platforms
for
us,
it's
all
about
focusing
on
the
capabilities
focusing
on
the
user
experience
enabling
self-service
we're
all
about
enabling
the
developer
to
go
fast
and
big
thing
as
well.
A
You
know
we
support,
you
know
over
1
billion
downloads
of
our
factory
in
the
last
month,
so
again
huge
amount
of
hardbacks
in
their
systems.
We
matched
there's
over
100
million
lines
of
code
that
go
through
our
static
analysis
system.
So
again,
really
large
scale
really
complex
and
it's
all
about
enabling
and
making
sure
that
the
platforms
themselves
are
resilient
and
it's
also
making
sure
that
we
wrap
those
platforms
in
self-service
so
that
we're
really
getting
out
of
the
way
the
developers
and
we're
enabling
them
to
go
as
fast.
B
So
I'm
just
going
to
run
through
some
of
the
kind
of
principles
that
we
are.
We
sorry
you're
going
back
and
forth
so
yeah
apology,
so
I'm
gonna
run
through
some
of
the
principles
for
enabling
a
pipeline
platform
just
across
the
firm.
So
as
kind
of
jimmy
kind
of
pointed
out,
we
are
a
small
central
group
that
provide
I.t
to
the
firm
itself,
so
some
of
the
things
that
we
kind
of
walk
through
here
will
show
how
we
kind
of
enable
that,
without
having
to
grow
a
huge
team
that
for
that
central
management.
B
One
so
in
terms
of
then,
the
teams
that
we
are
supporting,
we
can
see
from
this
kind
of
layout
we're
showing
basically
a
maturity
of
the
teams
that
needs
to
happen
over
time.
We've
gone
through
some
of
this
and
we've
gone
to
be
quite
mature
for
some
of
the
teams
that
we
do
support,
but
there
are
some
teams
that
are
still
quite
new
in
the
journey
in
terms
of
looking
at
initially
agile
development,
then
on
to
continuous
integration,
delivery
and
then
deployment
and
then
into
true
devops
teams.
B
We
also,
you
know
over
time,
have
seen
some
of
the
kind
of
anti-patterns
that
may
have
started
to
emerge,
but
as
we
kind
of
guide
those
teams
with
some
of
the
practices
and
principles,
principles
that
we
have
in
place,
we
see
a
lot
of
these
anti-patterns
starting
to
go
away,
which
is
great,
but
it
does
you
know
we
do
need
that
flexibility
to
be
able.
So
it
can't
be
a
one
size
fits
all.
B
How
can
they
they
can
go
from
continuous
integration
to
continuous
deployment
to
continuous
delivery
into
a
full
devops,
with
full
automated
pipelines
end
to
end
so
giving
some
of
these
capabilities
that
are
less
around
you
know,
green
and
red?
Are
things
up
or
down
it's
more
into
the
business
value
and
the
maturity
of
those
teams
and
allowing
them
then
to
make
progression
themselves
to
then
be
able
to
realize
the
full
value
of
pipelines.
B
It's
just
not
possible.
We
would
have
to
be
expand
and
grow
to
have
a
huge
number
within
the
team
to
support
that
so
having
self-service
functionality
and
capabilities
that
we
produce
that
essentially
enables
both
an
api
and
a
ui
format
allows
us
to
then
grow
at
pace.
Bus
can
adopt
our
platform
very
easily.
They
can
create
their
bitbucket,
their
pipelines
to
artifactory
target
spaces
and
start
to
deploy
out
to
the
cloud
providers
in
a
click
of
a
button.
B
B
We
have
a
layer,
then
that
we
look
at
kind
of
platform,
management
and
governance,
so
things
like
you
know,
supporting
the
the
core
versions
that
are
available
doing
the
upgrades
doing
the
audit
technology,
lifecycle
management,
cost
management,
secrets
management,
all
the
core
aspects
that
are
required
in
order
to
make
sure
that
developers
don't
have
to
worry
about
the
tools
and
capabilities
themselves.
They
can
just
leverage
them
to
go
forward.
B
We
take
on
a
lot
of
that
ownership
itself,
but
then,
as
we
kind
of
look
to
the
future,
we're
conscious
of
the
rate
of
pace
change
within
technology
previously,
it
might
have
been
five
six
seven
years
and
then
you
know
you
look
at
the
next
thing.
Now
it's
every
couple
of
years,
so
we
constantly
have
to
be
evaluating
the
next
thing.
So
we
need
to
be
able
to
try
scan
scale.
B
Is
this
something
that
we're
interested
in?
Are
business
partners
interested
in
it?
And
how
do
we
scale
it
out,
then?
If
that
is
something
that
we
should
go
forward
with
so
constant
evolutions
within
that
space
and
then,
as
I
talked
about
before,
as
we
look
to
kind
of
help,
our
teams
kind
of
mature
into
a
devops
practices,
doing
the
everything
is
called
models
with
pipelines,
etc.
B
We
need
to
be
able
to
kind
of
develop
those
communities
so
that
we
enforce
those
kind
of
engineering
practices
within
those
communities
themselves.
So
a
lot
of
these
kind
of
boxes
up
the
top
talk
about
some
of
the
areas
that
we
really
focus
in
when
we
look
at
our
developer
communities
and
then
on
the
right-hand
side.
These
are
a
lot
of
the
kind
of
metrics
that
we
previously
talked
about.
How
can
teams
understand
how
they
are
doing
in
terms
of
their
journey?
How
can
they?
B
How
can
the
business
partners,
the
management
players
make
sure
that
we
actually
focus,
and
we
actually
prioritize
our
automation?
Our
everything
is
code
approach.
We
do
this
through
metrics.
How
do
we
measure
the
value
of
what
we're
doing
so?
That's
the
right
hand,
side
that
we
make
capable
for
our
teams
and
obviously
the
bottom
layer,
then
talks
about
the
providers
that
we
will
be
deploying
out
to
as
a
firm.
B
B
We
also
have
looked
at
intersourcing
our
libraries
and
utilities,
so
instead
of
every
team
having
to
create
those
capabilities
themselves,
they
just
come
to
that
inner
source
libraries
and
we
work
together.
There's
no
ownership
kind
of
concerns
around
this
space.
This
is
for
everybody
and
everybody
is
capable
of
rewriting
into
it.
Then
we
do
a
structure
in
order
to
then
do
the
code
reviews
the
peer
reviews
and
make
that
available.
A
Thank
you.
If,
if
you
talked
about
the
principles
that
underpin
our
the
services
we
offer,
but
as
with
anything
else,
it's
it's
it's
not
all
about
processes
are
not
all
about
technology.
So
there's
many
things
in
many
aspects
to
tabling
you
know
a
best-in-class
organization
and
best-in-class
experience
for
developers.
A
A
And
inquisitive
people
that
that
are
going
to
push
the
boundaries
in
terms
of
you
know
making
sure
that
the
you
know
that
we
continue
to
focus
on
automation.
We
continue
to
focus
on
you
know
best
in
class
technologies
and
enabling
the
best
experience
possible
for
our
our
developers
and
and
making
sure
really
it
is
that
the
in
the
easy
way
is
the
right
way.
A
Additional
part
of
what
the
key
for
us
is
is
about.
Having
really
opened
us
conversations
with
our
partners
we're
a
center
of
business
unit.
We
face
often
we're
central
service.
We
face
off
to
multiple
business
units.
Each
of
the
business
units
has
different
needs
and
wants,
and
it's
just
having
the
very
honest
conversation
in
really
trying
to
understand.
What
is
the
business
need
that
is,
is
driving
your
ask.
I
think
we're
all
technologists
we're
all
technologists
and
there
is
a
maybe
there's.
A
A
We
can
design
a
a
robust
and
scalable
capability
that
supports
all
needs
and
wants,
and-
and
really
you
know
when
you
have
those
conversations,
you're
you're,
changing
your
dialogue
from
a
question
around.
You
know
your
systems
being
scalable
to
more
question
about
well,
okay,
how
are
we
going
to
help
you
solve
your
business
problem
so
that
we
can
help
you
faster?
We
can
help
your
developers
develop,
features
faster
and
again.
Ultimately,
what
that
happened
helps
is
it
helps.
A
B
David,
so
that's
an
interesting
question,
so
we
have
to
like
I
kind
of
spoke
about
at
the
beginning
right
that
we
have
to
accommodate
many
different
types
of
teams
and
equally
those
teams
have
a
particular
journey
that
they're
on
some
teams
are
very
kind
of
manual
that
they're
still
quite
hands-on.
They
have
to
go
through
a
lot
of
red
tape
in
order
to
be
able
to
do
their
ci
cd
functions
and
then
other
teams
are
incredibly
streamlined.
Everything
is
automated.
There's
an
end-to-end
kind
of
controls
that
are
in
place.
B
They
have
change
functions
that
are
completely
automated
and
all
allowed.
So
within
our
space,
not
only
we
need
to
be
able
to
the
entire
spectrum
as
part
of
that
and
not
get
in
the
way
so
from
very
immature
teams,
as
they
start
their
journey,
we
can
enable
them
with
those
practices
so
that
over
time,
working
with
the
other
communities
that
we've
developed,
they
do
start
to
mature
and
they
do
start
to
kind
of
hit
further
ride
in
that
spectrum.
A
B
There's
another
one
here,
then,
about
decoupled
architectures.
So
when
we
talk
about
some
of
this,
so
there
are
some
capabilities
right
that
are
are
baked
in
that
are
homegrown.
Some
things
like
governance
change
management,
some
of
these
types
of
functions,
so
we
generally
look
to
decouple
those
from
the
actual
platforms
itself.
So,
instead
of
like
focusing
on
libraries
that
things
like
that,
would
that
would
be
very
specific
to
a
particular
platform
can't
be
leveraged
across
platforms.
B
A
Yeah,
so
not
sure
what
that
what
what
what
that
really
kind
of
focuses
on
so
why
the
ocean
revolve
when
you're
entering
with
every
system,
I
think
so
that
is
about
kind
of
showing
demonstrating
the
values
of
your
system
and
kind
of
creating
good
partnerships
with
your
development
communities
across
the
various
business
units.
I
think
some
of
what
we
do
is
we.
We
establish
good
platforms
across
robust
scalable
platforms
across
you
know
ci,
for
instance,
and
what
we
do,
then,
is
we,
as
a
central
business
unit,
communicate
across
various.
B
A
Possible
so
that
the
cost
of
actually
using
the
system
is
is
diminished
over
time.
And
actually
you
know,
our
goal
really
is-
is
to
wrap
these
capabilities
in
the
self-service
portal
and
orchestrate
capabilities
across
the
various
platforms,
so
that
ultimately
get
to
a
point
where
new
developers
come
into
the
organization
and
they
can
get
pretty
much
set
up.
And
you
know
within
you
know,
within
the
day
of
joining
so.
B
A
B
A
Yeah
and
there's
another
question
there
from
david.
In
terms
of
you
know,
size
of
teams,
are
we
consulting
practice
or
platform,
so
we
primarily
platform,
but
we
also
provide
a
mechanism
for
linking
teams
across
the
organization.
So
again,
it's
more
about
intersourcing
and
developing
that
community
around
identifying
common
practices-
and
you
know,
and
also
and
sharing
that
so
that
platforms
is
reduced.
B
B
So
I
think
victor
kind
of
has
a
question
around
serverless,
so
the
challenge
with
serverless
is
always
you
know,
audit,
traceability,
etc.
So
the
same
guardrails
that
do
exist
for
any
technology
type
also
exists
for
serverless.
So
if
you
have
deployed
a
service
function,
you
know
there
needs
to
be
traceability
of
how
you've
done
that
deployment.
What
you've
deployed
it
back
to
you
know
our
everything
is
called
approach
to
how
we
kind
of
do
our
deployments,
etc.
B
Would
help
with
that
traceability
itself,
as
we
kind
of
bring
back
that
metadata
as
well
equally
as
those
kind
of
functions,
etc,
are
kind
of
running
within
the
cloud
providers
themselves.
You
know
the
output,
the
traceability
the
logs
related
to
that
also
needs
to
be
brought
back
so
that
in
the
event
of
a
particular
team
getting
audited,
and
they
have
that
full
traceability
across
the
board
and
that's
not
necessarily
solely
our
responsibility.
B
A
Yeah
I
mean
fidelity
is
broad.
It
supports
many
different
business
units
are
in
different
industries
and
that
they're,
you
know,
depending
on
the
industry,
their
independence
on
how
they,
how
the
development
early
software.
So
then
it's
just
a
question
of
supporting
all
that
and
supporting
the
business.
Ultimately.
A
There's
one
question
there:
why
are
your
dependencies?
So
we
are
very
much
cloud
focused
and
one
of
the
things
we
we
benefited
from
from
the
external
to
the
external
flag
was
reduction
dependencies
in
terms
of
a
say,
infrastructure
teams
itself,
so
infrastructure
is
code
available
on
external
cloud
means
that
your
developers
can
take
on
that
responsibility.
A
Beneficial
from
additional
features
and
functions,
especially
around
automation,
which
is
great
as
well,
you
know
it
provides
that
ability
to
as
long
as
you.
If
you
focus
on
and
and
value,
you
know,
execute
the
automation
you
can
really
go
after
that
which,
which
you
know,
definitely
provides
huge
benefits
and
allows
you
to
actually
go
after
more
feature
functions.
B
So
I
suppose,
within
our
kind
of
viewpoint,
it's
not
an
either
or
so
I
think
you
know
if
you
kind
of
look
at
it
and
you
kind
of
require
everybody
to
adopt
a
small
set
of
actual
kind
of
pipelines
themselves,
it
can
become
quite
a
brittle
system.
There's
there's
many
different
kind
of
use.
Cases
that
you
would
need
to
enable
your
central
train
would
have
to
grow
to
be
quite
large
in
order
to
be
able
to
support
the
entire
firm.
B
Instead,
we
have
multiple
business
units
that
jimmy
kind
of
talks
about
before
and
they
you
know
their
interest
is
not
to
actually
create
a
huge
amount
of
snowflake
pipelines.
Their
interest
is
to
kind
of
leverage,
what's
already
been
used
as
part
of
this
inner
source
kind
of
program
that
does
exist
and
by
process
of
kind
of
working
through
that
and
the
communities
that
we
do
have
a
standardization
does
appear,
it's
a
natural
kind
of
standardization
versus
an
enforced
type
of
a
pattern.