►
Description
Infrastructure-agnostic Continuous Delivery - Oliver Nocon, SAP SE
There is a lot of movement in the space of Continuous Delivery systems. The Continuous Delivery Foundation drives topics and tools forward like Jenkins, Jenkins-X and Tekton. On the other side there are big players in the market pushing their often proprietary systems. Where will the market evolve to? Should you care? In this session you will learn about one way to get prepared for the future by using the Open Source project "Piper". You will get insights into running "Piper"-based pipelines on different systems in the market. See how you can combine the strengths of multiple systems or just be prepared to not be locked into a specific tool. Judge yourself if “configure once - run anywhere” could become reality or will just stay a dream ...
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
A
A
The
area
I'm
working
in
we're
giving
a
jenkins
infrastructure
to
to
teams
individual
jenkins
instance
instances,
and
we
have
we
serve
more
than
1500
between
thousand
five
hundred
and
two
thousand
instances
to
our
development
teams
and
there's
more
usage
within
the
sap.
Since
you
know
it's
a
big
company
with
more
than
thirty
thousand
developers
and
having
more
than
hundred
thousand
employees
besides
technology,
I
don't
want
to
bore
you
with
a
dora
report.
A
A
Doris
says
not
really
right.
In
essence,
it's
about
the
development
culture,
having
empowered
teams,
trunk
based
development,
loosely
coupled
architecture,
which
nicely
supports
the
autonomy
of
teams,
the
autonomy
of
the
empowered
teams,
high
degree
of
test
automation
in
order
to
increase
your
quality
and
shifting
left
on
security.
A
A
A
A
Giving
teams
the
knowledge
about
this
flow
at
hand
without
the
need
to
dig
into
that
in
too
much
detail
we
see
more,
you
know.
In
a
few
minutes,
these
ready-made
pipelines
are
supported
by
the
hyperstab
library.
The
paper
step
library
essentially
performs
all
the
integrations
to
the
various
systems
which
are
required
in
your
continuous
delivery,
continuous
deployment
pipeline,
and
we
have
another
layer
and
below
which
is
a
common
configuration
layer.
A
A
A
Now,
let's
focus
on
one
key
ingredient
which
we
provide.
We
provide
a
separation
of
the
pipeline
logic
and
the
configuration
what
is
provided
and
that's
what
you
just
saw
is
the
pipeline
script.
The
jenkins
file
on
team
side
essentially
looks
the
same
for
every
single
repository
every
user,
using
it
just
has
these
two
lines
of
code
in
the
jenkins
file.
A
That
has
a
big
advantage.
We
do
have
the
capability
to
innovate
centrally,
when
you
can
add
things
to
this
pipeline.
Remove
things
from
the
pipeline
change
the
flow
a
bit,
what
happened
for
sure
within
certain
limits,
but
it
gives
us
the
flexibility
centrally
to
influence
the
behavior
with
our
teams
needing
to
know
about
it
and
with
that
reduce
the
cognitive
load
or
the
teams.
Maybe
you've
read
this
book
from
manuel
pais
about
team
topologies,
where
he
also
digs
into
the
topic
about
cognitive
load
of
developers
of
teams.
A
A
We
have
this
configuration
file
configuration
layer.
I
just
mentioned
before
right.
It's
one
configuration
file,
it's
a
yaml
file
which
is
t-mode.
Therefore,
they
configure
the
bits
and
pieces
in
there
for
overall
pipeline
flow
for
individual
stages
and
also
for
steps.
In
addition,
they
do
have
capability
to
extend
the
predefined
stages.
They
can
completely
override
the
stages,
prepend
append
something
all
in
the
hands
of
the
team
team
autonomy,
empower
teams.
A
A
Think
about
a
project,
a
product
where
you
have
several
development
teams
working
on
it.
You
want
to
have
some
common
configuration,
you
just
put
it
into
the
custom
defaults
and
it's
out
of
sight
of
the
individual
development
teams.
If
you
just
have
one
development,
team
and
you're
working
exactly
with
this
team,
there's
not
a
lot
of
benefit
in
it
for
sure.
A
If
you
have
more
development
teams
working
on
something,
that's
where
the
benefit
comes
in
and
then
again
coming
back
to
team
autonomy
in
power
teams,
every
team
has
a
possibility
for
sure
to
overwrite
configuration
their
pipeline,
specific
configuration
file
for
stages,
steps
and
the
general
configuration
and,
last
but
not
least,
although
not
recommended
for
sure
out
of
a
jenkins
file.
If
you
just
directly
consume
the
piper
library,
it's
possible
to
just
pass
the
parameters
to
those
steps.
A
A
A
That's
pretty
suitable
for
cloudy
bottle
cloud
deployment,
where
the
version
is
not
really
visible
to
end
users,
but
you
need
to
have
some
kind
of
mean
to
identify
what's
running
on
the
other
side.
There's
library
use
cases
where
you
don't
need
this
long
number.
You
just
need
a
samwell
version,
major
minor
patch.
A
A
A
A
A
How
do
we
scale
continuous
delivery
across
an
arc?
All
right,
then?
We
basically
pick
this
principle
of
pay
float,
not
invented
by
us
for
sure
right.
Their
talks
from
netflix
they're,
using
this
principle
a
lot
as
well.
In
the
end,
it's
about
providing
some
path
which
is
suitable
to
majority
of
teams,
but
not
locking
the
teams
in,
but
allowing
them
to
break
out,
take
a
deep
tour
and
ideally,
feedback
feed
things
back
for
sure.
A
Now
I
start
with
jenkins
right
jenkins
was
our
initial
focus.
We
have
the
ready-made
pipelines,
the
step
library
and
the
common
configuration
layer.
I
mentioned.
The
infrastructure
is
evolving,
there's
github
actions,
there's
tacton
and
this
might
be
whatever
right
new
things
coming
around
the
corner.
All
the
time,
what
did
what
did
we
do
with
the
open
source
project
piper?
In
order
to
tackle
these
kind
of
topics,
we
essentially
made
piper
infrastructure
agnostic.
A
A
A
A
We
can
do
it
in
the
shell
as
well
right.
We,
we
just
need
to
provide
the
information
to
for
retrieval
of
the
vault
for
accessing
board
with
a
role
id
secret
id.
Then
we
could
do.
We
can
do
a
git
clone
and
just
run
piper
artifact
repair
version.
It
just
do
just
exactly
the
same
reuses,
the
same
configuration
the
same
yaml
based
configuration.
A
You
can
do
that
in
github
actions,
there's
a
github
action
provided
by
the
piper
project,
which
allows
you
to
do
that.
Also
here,
you
just
need
to
provide
the
secrets
in
order
to
access
world
which
might
be
required
to
do
some
git
interactions.
What
have
you
right,
besides
that?
Again
it's
a
taking
the
checkout
action
and
taking
the
piper
action
and
running
the
versioning
step?
A
A
What's
next
I
mentioned
we
have
the
agnostic
configuration
layer
and
we
just
saw
how
this
works
across
the
various
orchestrators
right.
We
configure
once
and
run
it
anywhere.
We
configure
it
once
use
it
in
jenkins,
use
it
in
a
local
shell.
Shifting
left
things.
We
use
it
in
a
github
action.
We
use
it
in
tecton
the
power
of
it
and
the
beauty
of
it
is.
We
can
just
bundle
it.
We
can
run
certain
things
in
jenkins,
other
things
in
techno.
A
A
Now
you
remember
three
ingredients
right
common
configuration
layer,
step
library.
I
would
check
this
right.
That's
possible
right
now
in
an
infrastructure,
agnostic
manner.
One
thing
we
are
working
on,
which
is
not
really
there
yet
is
having
the
agnostic
ready-made
for
sure
we
would
wish
for
having
the
same
pipeline
the
same
ready-made
to
be
available
in
an
infrastructure
agnostic
way
on
a
jenkins
on
a
tecton
on
github
actions
on
whatever,
without
the
team
having
to
bother
about
it,
reduce
the
cognitive
load
of
the
team.
A
That's
what
we're
currently
working
on.
Maybe
in
half
a
year
a
year,
I
can
provide
you
some
update
with
that
or
you
just
follow
our
github
project.
You
find
access
to
documentation
and
some
more
information
on
project
piper
io
with
that.
Thank
you
very
much
for
joining
the
session
again,
and
we
have
some
time
for
q
a
thanks
a
lot
and
bye
bye,
hello,
everyone.
A
A
A
Any
more
questions,
if
not
maybe,
as
mentioned
you
you're
wondering
about
techton,
what
does
the
level
of
effort
look
like
to
write?
Integrations
thanks
sean
for
this
question
in
the
end,
what
we,
what
we
try
to
do
when
you,
if
you
look
into
the
project's
development
md,
we
are
trying
to
make
it
very
easy
to
write
a
step
in
paper
and
with
that,
make
it
very
easy
to
contribute
the
the
starting
point
for
it
is.
A
A
It
means
in
the
in
the
end,
you
you
get
the
configuration,
including
the
whole
configuration
hierarchy.
I
I
showed
in
the
session
for
free
inside
your
go
coding,
you
just
say
config
dot
and
then
the
step
name
you
define
and
you
you
can
consume
it
and
implement
your
step
logic.
We
try
to
make
it
as
simple
as
possible
and,
as
you
know,
developers
like
documentation
a
lot
and
like
to
document
things
a
lot
and
not
really
right
and
if
you
start
doing
documentation,
it's
typically
outdated.
A
A
A
That
means
there
is
a
step
which
essentially
updates
the
github's
repository,
and
we
then
leave
it
to
the
respective
tools
here,
like
argo,
like
flux,
in
combination
with
other
rollouts
or
flagger,
for
my
theories
and
so
on.
In
order
to
do
the
deployment
into
kubernetes
landscape,
we
we
try
to
stay
out
of
there.
A
A
A
A
Questions
is
integration
with
fd
in
the
near
future,
planning
for
terraform
fd.
We
don't
have
on
the
list
at
the
moment
and
terraform.
We
do
have
a
step
to
integrate
with
terraform,
yes
and
we're
looking
into
terraform
for
triggering
infrastructure
deployments,
for
example,
and
you
will
find
a
terraform
step
in
the.
A
A
A
Where
should
we
run
piper
container
function
as
a
service
vm
and
in
the
end
it
it
runs
directly
on
your
your
ci
environment
and
what
the
piper
steps
typically
do
is,
depending
on
the
step
they
will
will
be
kicked
off
in
a
container
all
right.
Let's,
let's
assume
you
do
a
kubernetes
deployment,
then
you
need
a
you,
need,
helm
or
cube
ctl.
A
A
Okay,
looking
at
the
time,
I
think
we're
at
the
end
thanks
a
lot
for
joining,
enjoy
the
rest
of
the
cdcon
and
I'm
happy
to
receive
feedback
from
you
guys.
Let
me
know
about
your
feedback
with
respect
to
piper
just
drop
me
a
line
on
by
linkedin
or
just
write,
something
one
issue
in
the
repository.
However,
you
wish
enjoy
the
rest
of
the
day
thanks
for
joining,
and
maybe
I
hear
from
one
or
the
other
one
of
you
sometime
in
the
future,
looking
forward
to
it
bye,
bye.