►
Description
Join us for Kubernetes Forums Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Trusted Software Supply Chain with JTE - Steven Terrana, Booz Allen Hamilton
DevOps was all about getting application developers and operations engineers to work together more effectively. In large part, automated testing and infrastructure as code enabled repeatable deployments we could be confident would work in production. Unfortunately, bottlenecks frequently arose in the software delivery process because the security team was never pulled into the fold. Enter DevSecOps. In this talk, we’ll cover how to integrate security into every step of the software development lifecycle to build a trusted software supply chain to production and how the Jenkins Templating Engine can accelerate the adoption of these practices at scale in your organization.
A
Hi
Ron,
so
I'm
Steven,
Tirana
I,
was
lucky
enough
to
be
sitting
next
to
Michael
last
night,
so
I
work
at
Booz,
Allen
Hamilton
I'm
we're
a
federal
consulting
firm.
So
my
day-to-day
life
involves
working
with
different
government
agencies
to
help
modernize
legacy
IT
systems
or
help
develop
new
ones.
So
this
is
actually
the
perfect
talk
to
follow
up
what
we
just
saw
around
some
some
dangers
and
your
kubernetes
configurations,
and
today
we're
going
to
talk
about
building
trusted
software
supply
chains
all
right.
A
So
how
do
we
get
applications
onto
our
clusters
that
are
as
secure
as
they
can
be
by
default?
So
today
we're
going
to
talk
about
what
does
dedsec
ops
actually
mean
walk
through
a
couple,
different
kinds
of
security
testing
that
you
can
integrate
and
then
we'll
talk
about
what
I've
been
working
on
the
last
couple
years
for
how
we
implement
this
at
the
enterprise
scale
next
slide.
A
More
generally,
we
were
still
seeing
a
pretty
significant
bottleneck
when
it
came
time
to
actually
releasing
software
out
to
a
production
for
our
end
users.
That's
because
we
left
out
a
very
important
team.
At
no
point
had
we
pulled
in
the
security
team
to
see
what
the
requirements
were
to
be
allowed
to
release
our
code
into
production,
so
enter
dead,
set,
cops
and
dead
set
cops.
A
If,
if
you
take
away
one
sentence
from
the
next
half
hour,
it's
that
dead,
SEC
ops
is
all
about
incorporating
security
into
every
step
of
the
software
development
lifecycle
and
shifting
it
left
as
much
as
possible
to
make
sure
that
the
security
teams
that
your
organization,
their
requirements,
reflected
in
the
automated
processes
to
get
your
applications
from
your
laptops
out
to
end-users
in
production.
So
there's
there's
six
different
boxes.
There
I'm
going
to
go
through
each
of
them
and
a
lot
more
detail
and
sort
of
talk
about.
What
is
it?
A
Why
do
you
actually
care
and
what
are
some
some
common
tools
that
I'm
seeing
folks
use
to
implement
this
so
first
up
is:
is
application
dependency
scanning,
so
we're
all
building
applications?
Most
of
us
have
not
ran
every
single
line
of
code
that
goes
into
our
application,
and
that's
because
we're
pulling
in
third-party
application
dependencies,
they
frequently
take
care
of
common
coding
problems
that
it's
not
worth
the
time
for
all
of
us
to
code
it
individually.
A
The
challenge
here
is
that,
because
we
didn't
write
that
code,
there's
frequently
vulnerabilities,
that's
sort
of
just
how
building
software
goes.
The
the
real
problem,
though,
is
when
you
don't
patch
these
vulnerabilities
all
right,
so
you'll
start
a
project,
you'll
pull
in
sort
of
the
boilerplate,
you
know,
react
starter
or
you
know
spring
boot,
starter
API
and
you
get
a
dependency
list
and
you
never
patch
it.
You
know
years
go
by.
You
have
a
very
full
backlog,
understandably
and
upgrading
the
versions
of
these
application
dependencies
never
seems
to
be
the
highest
priority.
A
So
if
we're
talking
about
our
dev
sack
ops
pipelines
as
a
trusted
software
supply
chain,
you
can
think
of
these
application
dependencies
as
the
ingredients
that
are
going
into
building
your
application.
So
application
dependency
scanning
is
all
about.
How
do
we
scan
these
to
make
sure
that
they
don't
have
known
vulnerabilities
right?
So
another
challenge
is
that
these
are
changing
every
single
day.
It's
very
likely
that
new
CVEs
are
being
released
that
are
exposing
our
applications
to
security
vulnerabilities.
So
how
do
we
actually
go
about
fixing
this?
A
One
best
practice
is
to
leverage
a
centralized,
artifact
repository
and
do
some
actual
scanning
on
these
dependencies,
so
a
tool
that
I've
used
used
in
an
fonda
would
be
like
Nexus
Nexus,
which
is
an
artifact
repository.
The
idea
here
is
that,
instead
of
pulling
your
dependencies
directly
from
the
internet,
you
can
store
these
in
a
centralized
artifact
repository
as
artifacts
are
being
pulled
into
your
environment.
You
can
scan
them
to
see
if
there
is
any
known
vulnerabilities
against
them,
and
then
you
know
the
first
day
that
you
pull
in
a
dependency.
A
So,
let's
assume
we
did
that
we
know
that
all
of
our
application
dependencies
are
secure,
we're
not
pulling
in
an
old
Struck's
package.
That's
gonna
expose
the
organization.
Next
up
is
actually
scanning
the
code
that
we've
written
to
make
sure
that
does
it
doesn't
have
any
inherent
security
vulnerabilities.
So
that
means
did
you
hard
code,
IP
addresses
or
passwords.
A
So
why
does
this
actually
matter?
The
first
is:
it
can
assist
a
lot
in
code
review.
These
tools
can
help
you
from
a
security
practice
perspective,
but
it
can
also
help
from
some
of
the
industry
standardized
best
practices
so
that,
when
you're
doing
code
reviews
on
your
applications,
you
can
focus
on.
You
know
the
aspects
that
are
specific
to
your
team
and
allow
these
tools
to
automate
the
the
quality
of
you
know.
You
don't
have
dead
code
in
your
application.
That's
ever
actually
going
to
be
run
alongside
those
security.
A
A
So
up
until
this
point,
we've
made
sure
that
the
ingredients
in
our
application
are
secure.
We
actually
wrote
some
code
and
we
scanned
it
to
make
sure
that
the
code
we
were
in
isn't
inherently
insecure.
So
next
up,
we
are
a
cube
con,
so
I
would
assume
that
a
lot
of
us
are
building
containerized
applications.
So
now
that
we've
written
code,
we
want
to
package
that
pulling
in
those
application
dependencies
into
a
a
container
image.
This
is
a
new
artifact,
so
we
need
to
scan
it.
A
We
need
to
make
sure
that
the
you
know
if
we're
just
pulling
random
images
from
docker
hub
make
sure
that
there
aren't
crypto
minors
on
there,
making
sure
that
there
aren't
vole
nura
below
s
packages
and
our
container
images.
So
why
does
this
matter?
It's
the
same
thing
as
application
dependencies
if
you're
pulling
straight
from
docker
hub,
you
don't
know
exactly
what
went
into
building
that
container
image.
So
what
can
you
do
to
prevent
this?
There's
some
tools
out
there
that
can
do
some
container
image
scanning.
A
If
you
go
into
the
vendor
Hall,
there
will
probably
be
about
604
container
image
scanning
tools
that
you
can
choose
your
favorite
and
what
are
some
best
practices
to
help
with
this.
So
a
lot
of
what
I
do
is
my
day
to
day
is
being
on
a
DevOps
team.
That's
that's
supporting
multiple
application
teams
simultaneously.
A
lot
of
application
developers
would
prefer
to
just
write
code
and
not
necessarily
be
concerned
with.
How
does
my
code
turn
into
a
container
image?
How
do
I
write
a
helm
chart
to
play
that
on
to
kubernetes?
A
So
when
it
comes
to
choosing
base
images,
one
thing
that
I've
seen
be
successful
is
to
have
a
heavier
centralized
platform.
Team
or
DevOps
team
actually
manage
some
gold
images
that
the
application
developers
can
start
with.
So,
instead
of
just
going
out
to
docker
hub
for
every
team
and
choosing
the
the
latest
thing
that
seems
like
it
does.
What
you
want.
A
You
can
sort
of
curate
some
starting
points
for
the
application
development
teams
in
your
organization
and
then
continuously
scan
those
and
be
responsible
for
patching
them,
so
that
you
can
sort
of
offload
a
lot
of
that
responsibility
from
the
application
teams.
When
you
do
that,
it
means
that
the
application
developers
now
have
a
much
smaller
boundary
of
control
that
they're
responsible
for.
If
they're,
inheriting
all
of
the
patches
from
this
centralized
base
image,
then
they're
only
responsible
for
patching
their
application
dependencies
or
whatever
they're
customizing.
On
top
of
that
base
image.
A
So
security
vulnerability
is,
in
general,
come
in
two
flavors
right.
You
have
vulnerable
packages,
so
we
pulled
in
an
insecure
ingredient
into
our
application,
or
we
pulled
a
image
from
docker
hub
that
has
crypto
miners
on
it,
but
there's
also
configuration
errors
which
we
saw
a
whole
whole
lot
of
and
previous
talk.
A
So
a
lot
of
those
container
image
scanning
tools
that
we're
using
to
scan
our
container
images
can
also
scan
the
configuration
of
the
infrastructure
that
we're
building,
whether
it's
the
underlying
hosts
or
your
kubernetes
cluster,
or
the
configuration
of
a
container
image
to
make
sure
that
it
doesn't
have
known
vulnerabilities.
So
being
a
federal
consultant.
There
are
a
lot
of
federally
regulated
guidelines
on
how
you're
supposed
to
build
and
deploy
infrastructure,
so
things
like
secure
technical
implementation
guides
and
this
guidelines
FISMA
compliance.
A
If
we're
building
a
car,
we
want
to
know
where
all
the
different
pieces
are
coming
from
and
who's
manufacturing
it.
The
same
thing
applies
when
you're
building
your
applications.
So
up
until
this
point,
we've
made
sure
that
the
ingredients
of
our
application
are
secure
by
leveraging
a
centralized,
artifact
repository
and
doing
application
dependency
scanning.
We
then
wrote
some
code
and
we
made
sure
that
it's
secure
by
doing
some
static
code,
analysis
and
making
sure
we're
not
hard
coding,
IP
addresses
or
otherwise
writing
code.
That's
going
to
leave
us
susceptible
to
exploitation.
A
A
So
and
then
we
scanned
it
right
so
with
continuous
compliance,
we're
able
to
then
scan
that
container
image
to
make
sure
that
we're
not
running
it
as
the
root
user
make
sure
it's
compliant
with
the
different
security
profiles
that
help
enforce
some
of
these
security
configurations
so
that
you
can't
get
root
access
to
the
underlying
host
as
easily
as
we
just
saw.
So
at
this
point,
you
can
now
actually
deploy
the
application
and
make
sure
it's
not
susceptible
so
dynamic
application.
A
Security
testing
is
a
mouthful
of
a
way
to
say
penetration
testing,
so
we
can
actually
deploy
our
applications
and
make
sure
that
they're
not
susceptible
to
common
exploitations.
You
know,
if
you
have
a
forum,
is
there
a
way
for
me
to
do
arbitrary
code
execution
things
like
that,
so
a
common
tool
to
do
this
is
a
lot
of
SAP.
It's
open
source,
there's
a
whole
bunch
of
other
tools
that
can
help
out
with
this
and
what?
A
So
this
talk
is
primarily
about
the
supply
chain
of
our
applications,
but
another
good
tool
or
practice
that
you
can
be
implementing
is
like
continuous
security
monitoring
of
your
clusters,
all
right
so
there's
the
CNCs
project
Falco.
So
if
you
had
that
configured
on
your
cluster,
it
can
be
monitoring
all
of
the
different.
You
know
colonel
or
commands
that
are
happening
on
your
node.
So
if
you're
running
penetration
testing-
and
you
have
Falco
rules
configured
that
can
monitor
the
environment,
to
make
sure
that
only
the
correct
commands
or
commands
that
you
expect
are
being
executed.
A
So
the
pipeline
everything
up
until
now,
there's
a
lot
of
different
tools
that
can
implement
it
and
doing
them
all
manually
would
take
a
significant
amount
of
time.
If
all
of
this
put
together
is
in
part
to
help
us
accelerate
our
for
delivery,
we
need
a
way
to
tie
all
that
together
and
automate
it.
So
that's
what
the
pipelines
responsible
for
so
it's
going
to
orchestrate
all
of
these
different
software
delivery
related
activities.
Basically,
when
a
developer
does
something
in
github
what
types
of
automated
scans
or
quality
assurance
tests
are
gonna
be
executed.
A
So
why
does
this
matter?
It
helps
reduce
friction
and
adopting
these
practices
through
automation,
if
the
expectation
was
for
every
development
team
and
a
large
organization
to
learn
how
to
administer
the
tools
that
help
you
do
these
things
and
then
further
to
go
automate
it
it's
going
to
be
extremely
challenging
to
find
time
in
their
sprint
capacity
to
dedicate
cycles,
to
learning
how
to
do
continuous
compliance
or
fine
tune,
static
code,
analysis
profiles
or
what
have
you
so
by
setting
up
an
automated
dev,
psych
ops
pipeline,
you
can
reduce
friction
and
you
know
accelerate
adoption.
A
The
second
is,
you
can
mitigate
technical
debt
by
doing
this
continuously,
another
common
pitfall
is
to
push
security
to
the
right
right,
so
you've
been
developing
something
for
six
months.
You
want
to
release
it
out
to
production,
and
then
you
go
do
these
security
scans
and
you
find
several
hundred
vulnerabilities
that
need
to
be
patched
before
you're
actually
going
to
be
approved
to
do
that
deployment.
So
by
having
an
automated
dedsec
ops
pipeline.
If
you're
doing
this
on
every
single
change,
it's
going
to
help
you
with
you
know
continuously
making
sure
that
you're
secure.
A
So
by
doing
it
continuously
that
fast
feedback
can
help
a
lot
with
with
fixing
problems
as
they
arise
and
then
again
from
the
federal
space
authorizing
officials
are
those
people
that
are
willing
to
take
responsibility
for
your
applications.
So
if
you
can
communicate
to
them
that
every
single
change
is
being
run
through,
all
these
different
kinds
of
security
testing
helps
them
feel
a
lot
more
comfortable
which,
if
they're
comfortable
they're
gonna,
be
a
lot
more
eager
or
willing
to
do
frequent
deployments
to
production.
A
Does
anyone
work
in
the
federal
space
all
right?
Let's
see
a
couple
hands,
so
I'm
hoping
some
of
these
concepts
are
familiar.
I
assume
a
lot
of
this.
You
know.
Strict
approach
to
software
delivery
also
applies
in
industries,
like
you
know,
finance
or
healthcare,
anywhere
that
you
have
like
PII
or
payment
data,
or
really
any
data.
No
one
wants
to
go,
get
their
data
hacked,
but
especially
in
the
federal
space,
getting
an
authority
to
operate
for
a
new
application.
If
you're
lucky
takes
three
months,
if
you're
average
it
takes
a
year
and
a
half.
A
So
by
implementing
a
lot
of
these
practices,
you
can
drastically
reduce
how
long
it's
going
to
take
for
a
new
government
system
to
be
approved
and
deployed
into
production,
so
putting
it
all
together.
All
of
the
security
testing
that
we're
talking
about
is,
in
addition
to
all
of
the
other
kinds
of
automated
testing
that
the
industry
has
been
doing
for
several
years.
A
So
when
you're
dealing
with
enterprise
scale,
adoption
of
DEP,
SEC,
ops
or
you
have
a
diverse
application
portfolio
which
lets
as
consultants
speak
for
there's
different
kinds
of
apps
that
your
organization,
depending
on
the
application
there
might
be
different
tools
that
are
being
used
to
implement
each
of
these
different
practices.
All
right.
So
if
you
take
an
easy
example
in
in
you
know,
testing
if
you've
got
a
front-end
application,
it
might
be
using
something
like
karma
or
just
to
do
it's
you
know
testing.
If
it's
a
back-end
application,
it
could
be
j-unit
or
or
python.
A
Some
teams
in
an
organization
might
be
using
sonar
cube
for
static
code
analysis.
Other
teams
might
be
using
fortify,
so
the
purpose
of
this
slide
is
is,
admittedly,
to
be
a
little
intimidating.
There's
a
lot
of
activities
that
go
on
in
automating,
a
fully
matured,
dedsec
ops
pipeline
and,
if
you're,
a
central,
dev,
ops
team,
that's
helping
automate
these
software
delivery
processes
for
a
lot
of
different
application
teams.
A
A
So
let's
say
over
time
you
want
to
make
a
change
to
your
dedsec
ops
pipeline.
You
know
you're
continuously
improving
you've
identified,
something
that
would
make
this
process
flow
better.
If
you
want
to
roll
that
change
out
now,
you
have
to
open
64
requests
and
modify
60
different
pipelines
and
from
a
Booz
Allen
perspective,
as
a
consultant
were
we're
doing
this
kind
of
large-scale
support
of
dedsec
ops
pipelines
at
multiple
clients.
A
So
what
we
were
finding
was
that
within
any
given
client,
you've
got
a
whole
bunch
of
duplication
with
these
application,
specific
pipeline
implementations
and
then,
if
you
zoom
out
across
all
of
Booz
Allen,
we've
got
DevOps
engineers
in
the
firm
at
all
of
our
different
client
engagements.
That
are
doing
the
same
thing.
So
we
were
finding
that
I
was
taking
something
like
four
to
six
months
when
our
project
started
to
end
up
with
a
fully
mature
dev
SEC
ops
pipeline
and
the
ongoing
sustainment
of
that
pipeline
was
pretty
high
because
of
the
these.
A
The
implementation
of
this
automated
process
was
a
pretty
tailored
implementation
for
for
each
application.
So
about
three
years
ago,
we
we
sort
of
sat
down
and
said
every
application,
regardless
of
what
tool
it's
using
is
going
to
follow.
Basically,
the
same
process
or
a
set
of
processes
at
any
given
organization,
you're
going
to
build
something
you're
going
to
test
it
somehow
and
package,
it
you're
going
to
deploy
it
and
you're
going
to
test
it.
It
doesn't
matter
if
you're
building
a
jar
file
to
SCP
it
onto
a
server
or
your.
A
You
know
building
a
container
image
and
deploying
it
with
helm,
do
with
kubernetes
cluster
there's.
Generic
workflow
is
largely
the
same
and,
furthermore,
a
lot
of
the
time.
The
implementation
of
those
specific
steps
is
pretty
undifferentiated
work.
There
was
no
reason
that
every
DevOps
engineer
at
the
firm
should
Google
sonar,
cube,
plus
Jenkins,
find
the
six
lines
of
pipeline
code
that
go
into
doing
static
code
analysis
and
copy
and
paste
it
into
their
Jenkins
files.
A
So
we
started
out
trying
to
figure
out
like
how
can
we
accelerate
pipeline
development
to
ease
the
adoption
of
these
practices,
and
how
can
we
ease
the
maintenance
of
large-scale
enterprise
level,
dedsec,
ops
pipelines
in
three
years
later
and
more
weekends
than
I
want
to
admit?
We
have
the
Jenkins
templating
engine,
how
many
people
are
using
Jenkins
or
familiar
with
Jenkins?
A
That's
a
lot
of
hands
so
Jenkins
by
default.
You
have
a
Jenkins
file
that
goes
in
the
source
code
repository
and
now
it
outlines
what
your
pipeline
is
going
to
do
so
with
the
Jenkins
templating
engine.
The
idea
was
why
don't
we
just
define
a
pipeline
kind
of
like
we
did
on
this
slide
in
a
tool
agnostic,
templated
way,
while
still
giving
teams
the
flexibility
they
need
to
choose
the
tools
that
are
that
are
the
best
for
the
job.
So
this
is
what
I
was
able
to
throw
together
sitting
next
to
Michael.
A
Yesterday,
as
a
representation
of
what
that
looks
like
in
the
middle,
you
have
what
would
be
a
template,
they
get
a
lot
more
complicated
than
that,
but
from
a
conceptual
standpoint,
you're
going
to
do
something
like
build,
scan,
deploy
and
test.
You
can
one
application.
That's
using
docker
performing
static
code
analysis
with
sonar
cube,
deploying
it
with
helm
and
using
selenium
for
integration
testing,
or
you
could
have
the
second
application.
A
That's
building
an
app
with
Gradle,
using
fortify
to
scan
it
using
ansible
to
automate
some
deployments
and
then
using
something
like
rest
assured
to
test
its
restful
api.
The
power
here
is
that
you
no
longer
have
individualized
jenkins
files.
You
have
tool
agnostic
pipeline
templates
that
can
be
applied
at
the
organization
level,
where
you
get
to
specify
what
are
the
organizationally
approved
software
delivery
practices
to
get
code
into
production,
while
still
giving
teams
the
flexibility
that
they
need
to
choose
the
best
tools
for
the
job.
A
So
I
have
about
five
minutes
real,
quick
on
that
I'll
go
over
the
the
value
of
it.
I
think
I've
got
five
minutes,
so
I
might
show
a
quick
demo
or
open
it
up
to
questions.
So,
what's
the
what's
the
value
of
doing
it
this
way
the
first
is
organizational
governance.
So
if
you
have
60
copy
and
pasted
jenkins
files,
you
have
no
assurance
that
everyone
is
actually
following
the
same
process.
A
Everyone
went
and
implemented
it
in
their
own
way,
which
was
a
significant
waste
of
time.
To
be
honest,
so
the
second
value
there
is
optimizing
pipeline
code,
reuse,
like
I,
said:
there's
no
reason
everyone
should
go
figure
out
how
to
do
so
in
our
cube
analysis
and
Jenkins,
like
we
all
already
know,
if
you
Google
is
the
first
result,
so
at
Booz
Allen
we
were
able
to
open-source
our
pipeline
libraries
right.
So
the
tool,
specific
implementations
of
different
steps
of
that
pipeline
are
organized
into
what
we
call
pipeline
libraries.
A
So
if
you
want
to
do
a
deployment
with
helm,
there's
a
helm
library
that
contributes
a
deploy
to
step
so
through
that
we've
seen
pipeline
development
time
go
from
four
to
six
months
to
a
four
to
six
days,
if
you're
leveraging
tools
that
we've
already
integrated
with
and
if
you
aren't
writing
a
new
library
is
the
same
thing
as
writing.
Regular
jenkins
pipeline
is
code.
It's
just
a
slightly
different
way
to
organize
it.
A
So
you
can
dynamically
compose
your
pipeline,
leveraging
a
reusable
template
instead
of
building
individualized
pipelines
for
each
application
and
then
the
last
point
having
had
to
support
a
60
micro
service
system
worth
with
copied
and
pasted
jenga's
files.
In
my
humble
opinion,
it
is
a
lot
easier
to
manage
a
pipeline
template
that
outlines
the
business
logic
of
your
software
delivery
processes
and
then
modularized
tool,
libraries
than
it
is
to
manage
those
sixty
separate
jenkins
files.
A
So
it's
open
source,
it's
on
github,
if
you're
interested
in
it,
it's
called
the
template
engine
plug-in
there's
a
whole
bunch
of
documentation
at
this
point,
I
don't
know
that
I
have
time
for
a
demo,
but
I'm
always
happy
to
to
talk
if
anyone's
interested,
so
I
hope
that
I
hope
that
resonates
for
you.
You
have
three
minutes,
go
ahead
and
do
your
demo
and
then
we're
going
into
break
anyway.
So
we
lose
a
little
bit
of
time
to
break
them.
Sorry,
all
right
I
have
three
minutes.
That's
that
should
be
enough
time.
A
So
this
is
Jenkins
I'm
gonna
demo,
a
pipeline
that
primarily
shows
off
the
templating
side
of
things.
So
there's
a
couple
different
use
cases
and
I'm
gonna
go
admittedly
a
little
quick
here
to
show
all
the
different
examples
here,
but
on
the
top
we
have
a
pipeline
template,
so
nothing
there
is
specific
to
a
tool.
It
says
we're
gonna,
do
build
static
code
analysis
and
then
deploy
to
dev.
Alongside
your
pipeline
template,
you
get
a
configuration
file.
A
So
instead
of
defining
a
700
line
Jenkins
file
for
each
application,
we
were
able
to
define
a
pipeline
configuration.
That's
going
to
implement
this
template,
so
it's
going
to
read
a
lot
like
your
text,
sack
where
there's
a
library
section,
that's
going
to
pull
in
exactly
what
tools
are
being
used
to
implement
these
different
steps.
So
in
this
case
we've
got
a
maven
application
using
sonar
cube
ansible
for
deployment
and
then
a
Splunk
library
for
for
some
monitoring
of
the
pipeline
down
below.
A
We
have
an
application
environments
definition
every
everyone
has
different
application
environments
and
different
numbers
of
them.
So
here
we're
able
to
define
a
dev
environment
which
we
can
use
in
our
ansible
library
for
deployment.
So
if
we
click
build
or
actually
since
we've
got
three
minutes,
I'll
show
an
existing
run.
It's
going
to
pull
in
all
these
libraries
dynamically
compose
what
that
template
actually
means
with
this
configuration
and
then
go
and
execute
it.
A
So
if
we
scale
that
out,
it's
traditionally
not
going
to
be
defined
in
the
Jenkins
UI,
you
can
apply
this
to
an
entire
github
repository
or
an
entire
github
organization.
Alright,
so
if
I
have
a
single
application,
instead
of
having
a
Jenkins
file
in
the
repository,
I
can
pull
it
out
into
a
centralized
pipeline.
Configuration
repository
and
I
can
achieve
the
exact
same
thing
without
giving
developers
access
to
the
Jenkins
file
and
by
leveraging
these
modularized
tool
agnostic
pipelines.
A
So
the
real
power
here
is,
if
we
go
to
an
entire
github
organization,
I
can
define
multiple
configuration
files
that
have
a
hierarchical,
taxonomy
right,
so
maybe
at
the
entire
organization
level
everyone's
using
sonar
cube,
so
I
can
define
everyone
has
to
use
sonar,
cube
and
then
give
teams
the
flexibility
they
need
to
pick
what
specific
libraries
they're
using
for
other
things.
So
here
we've
got
a
Gradle
application.
It's
going
to
look
like
you
would
expect
Gradle
sonar,
cube
analysis.
A
I
can
go
over
to
the
maven
application
and
it's
going
to
be
using
maven
in
sonar
cube
analysis.
So
both
of
these
repositories
and
all
of
these
jobs
are
leveraging
the
exact
same
pipeline
template.
So
I
know
that
every
development
team
in
my
organization
is
following
the
same
software
delivery
practices
and
that
same
pipeline
template
and
now
we're
giving
teams.