►
From YouTube: Patterns for Successful Large Scale Enterprise CD
Description
Description: SAP is building up a one-stop-shop service ecosystem in order to scale compliant Continuous Delivery processes across the company.
Learn from Dirk Luedtke (Head of SAP CI/CD Product-Management) and Oliver Nocon (Chief Product Expert and creator of project “Piper”) how the ecosystem is built up, and what ingredients you can also use yourself.
A
B
Thank
you
very
much
and
thanks
for
the
invitation,
this
sounds
like
the
beginning
of
a
big
adventure,
but
it
will
just
be
a
little
presentation
on
basically
the
experience
that
we
made
at
sap
introducing
ci
cd
at
large
scale.
So
today,
I'm
here
together
with
oliver
noucan,
I'm
dear
klutke,
I'm
at
sap
responsible
for
the
strategy
of
our
internal,
the
icd
service
and,
as
having
said
before,
we
would
like
to
share
some
of
the
learnings
we've
made
on
our
way.
B
B
I
guess
some
impressive
kpis
here
on
that
slide,
so,
for
example,
that
77
of
the
world's
trend
transaction
revenue
touches
an
sap
system.
Fair
enough.
I
guess
that's
that's
pretty
cool,
but
actually
what
really
counts.
If
we
talk
about
ci
cd
is
the
question:
if
our
customers
are
happy
right,
so
customers
we
have
440
000
customers.
I
looked
it
up
yesterday
being
working
on
sap
systems
in
in
180
countries
across
the
globe
and,
if
I
say,
customers,
440k
customers,
I'm
not
talking
about
end
users,
I'm
talking
about
enterprises
companies.
B
So
basically
the
forbes
global
2000
list
of
enterprises
is
on
sap
and
what
we
experienced
today
is,
of
course,
that
those
customers
are
currently
redesigning
their
business
right,
so
they
all
have
started
back
embarked
on
a
journey
called
digital
transformation,
so
they
changed
the
way
they
are
doing
business.
Today
and
honestly,
this
was
accelerated
very
much
last
year
due
to
the
fact
that
we
have
corona
and
with
corona,
everybody
basically
understood
okay.
This
is
just
the
first
thing.
B
I
need
to
prepare
my
business
for
the
next
crisis
to
come,
be
it
corona,
2
or
you
never
know,
and
in
order
to
get
prepared,
I
need
a
digital
supply
chain
and
therefore
what
we
experience
is
a
lot
of
speed
in
the
market.
So
people
really
our
customers,
shorten
their
project
plans
for
that
digital
transformation
partially
from
years
to
weeks.
B
So
we
have
a
huge
spectrum
and
portfolio
of
cloud
products
and
and
our
customers
use
that
to
win
their
own
digital
transformation,
and
that
is
why
the
icd
is
of
strategic
importance
today,
and
this
is
the
meaning
of
scale
from
a
customer
perspective
internally
for
looking
at
that
here
are
some
some
numbers
that
express
what
internal
scale
means.
So
we
have
all
together
30
bill.
More
than
30
billion
lines
of
code
in
our
production
system,
developed
by
more
than
30
000
developers,
really
coders
distributed
all
around
the
globe,
working
7
by
24.
B
yeah,
a
lot
of
repositories.
I
mean
the
key
point
here
is
that
those
30
000
developers
kind
of
spend
up
a
huge
range
of
different
requirements.
We
have
to
serve
different
development
technology.
Everything
you
can
imagine
that
you
find
on
the
market
somewhere
it's
used
in
sap.
We
have
different
levels
of
maturity,
shipment
cycles,
so
we
have
services
that
are
based
on
progressive
delivery
delivered
every
day,
and
we
have,
of
course,
bigger
products
where
a
thousand
developers
work
on
one
thing,
like
the
business
technology
platform
now
being
shipped,
I
guess
weekly.
B
B
And
I've
tried
to
express
it
here
on
that
slide.
So
what
is
key
for
us?
I
think,
from
a
business
perspective,
what
or
the
real
purpose
of
the
icd
is,
of
course,
to
reduce
time
to
market
okay
for
a
software
company.
That
might
mean
something
else
than
for,
for
example,
a
manufacturer
or
car
manufacturer
like
daimler.
So
I
don't
know
for
a
software
company
ci
cd
is
not
just
something
we
need
it's
a
at
the
end
of
the
day.
B
It's
a
differentiator,
because
actually,
what
we
need
to
understand
and
what
we
need
to
learn
is
that
to
make
a
deal
out
there,
it's
not
just
about
creating
the
next
greatest
feature
right.
It's
the
the
question
is
very
much
of
who
brings
the
idea
faster
and
better
to
the
end
user.
So
it's
not
just
about
designing
a
better
product.
It's
about
designing
a
better
process.
B
This
is
what
sap
needs
to
achieve
to
to
remain
competitive
and,
as
a
consequence,
it's
very
much
required
that
we
remain
flexible.
Honestly,
we
don't
know
which
kind
of
process
we
have
to
design
tomorrow.
We
need
to
be
fully
flexible.
We
need
to
stay
the
captain
of
the
process
and
this
flexibility
to
design
whatever
we
need
there
and
to
to
beat
our
competitors
on
the
process.
Level
is
absolutely
a
must
for
us
and
here's.
B
The
conclusion
that
we
took
the
conclusion
is
that,
as
sap
today
until
today,
we
didn't
buy
one
of
those
all-in-one
devops
platform
so
far,
and
there
are
many
good
devops
platforms
on
the
market,
so
we
rather
follow
a
strategy
where
we
go
best
of
greed.
That
means
we
look
at
the
market
and
we
rather
look
for
best
of
breed
single
purpose,
domain,
specific
tools
that
we
can
take
and
then
integrate
into
our
ecosystem
and
and
like
that,
we
remain
responsible
for
designing
the
process.
B
This
is
very
important
for
us,
so
this
whole
aspect
of
flexibility
and
I'm
allowed
to
say,
unfortunately,
what
we
observe
on
the
market
is
that
currently
the
trend
goes
into
the
opposite
direction,
so
we
we
typically,
you
know
we
have
many
vendors
and
they
started
with
a
domain
specific
service
somewhere
like
binary
management,
whatever
pretty
nice,
but
they
all
kind
of
set
sales
and
now
are
evolving
towards
becoming
platform
vendors.
This
is
good,
nothing
against
that.
The
problem
that
we
sometimes
have
as
a
company
is
that
evolving
towards
the
all-in-one
cicd
platform.
B
There
are
assumptions
built
into
the
platform
right
assumptions
or,
let's
say
hard-coded,
workflows
here
and
they're
hidden
here
and
there
and
they
might
not
fit
to
what
we
need
today
in
particular,
they
might
not
fit
towards
what
we
need
tomorrow,
and
this
is
why
we
will
stick
to
that
best
of
free
tool,
technology
and
we
build.
Let's
say
the
platform
on
our
own
second
aspect,
which
is
absolutely
critical
for
us
is
compliant.
So
what
does
that
mean?
B
We
sell
enterprise
software
and
in
order
to
sell
enterprise
software,
you
must
we
make
promises
to
our
customers,
so
we,
for
example,
promise
to
fulfill
legal
regulations.
We
promise
to
fulfill
industry
standards
and
all
these
promises
that
we
make
are
combined
at
sap
in
something
that
is
called
products
are
not
the
sap
products
and
through
internal
regulations
that
basically
are
valid
for
all
the
products
we
ship.
That's
our
promise
to
the
customers,
hey.
If
you
buy
something
here,
we
enterprise
ready.
We
promise
now
if
we
want
to
ship
daily.
B
The
consequence
is
that
those
kind
of
compliance
assessment-
hey
is
our
changes.
Our
still
our
features
still
complying
to
our
in
our
internal
regulations
is
becoming
part
of
the
pipeline
and,
as
that
is
becoming
part
of
the
pipeline,
it
needs
to
follow
the
same
paradigms
as
the
other
things
in
the
pipeline.
B
So
we
need
to
complete
the
automate
compliance
and
I
will
in
a
minute,
deep
dive
a
little
bit
on
this
topic,
and
last
requirement,
of
course,
is
I
guess,
that's
normal
shared
service
provider,
quality
or
requirement
is
that
we
need
to
as
well
fulfill
something
for
our
employer
sap,
namely
to
look
at
the
costs
right
so,
of
course,
chat
sales
provider.
We
need
to
look
at
long-term
cost
effectiveness.
B
Actually,
we
follow
many
patent
and
best
practices
with
an
sap
to
best
fulfill
those
requirements.
Those
are
four
patterns
that
we
now
took
for
the
presentation
to
deep
dive
a
little
bit
on,
so
I
will
talk
about
our
paved
road
ecosystem
best
of
breed
cicd
platform
and
how
we
automate
compliance
on
a
high
level,
and
then
we
take
a
deeper
look
into
shared
coded
knowledge.
I
think
this
is
the
most
important
aspect
and
therefore
will
take
some
more
time
here
and
here
I
will
hand
over
to
oliver
who's
in
the
call.
B
Let's
talk
about
the
paved
road,
and
actually
I
have
stolen
that
expression,
because
the
colleagues
from
netflix
found
a
nice
term
to
describe
as
well
our
service
principles,
our
service
mentality
and
the
way
we
as
an
as
a
shared
service
provider
within
sap
work,
and
this
term
is
paved
road
and
the
idea
behind
that
is
that
actually
we
typically
provide
out-of-the-box
turnkey
solutions
right.
If
a
team
contacts
us
they
get
a
ready-to-use
end-to-end
process
and
ready
to
use
means
this
is
a
process
which
is
the
best
we
know
today
right
so
it's
reliable.
B
It's
secure
it's
fast,
it's
based
on
the
latest
and
greatest
tools
you
would
find
on
the
market
and
all
that
stuff
right.
So
this
is
what
we
promise
and,
of
course,
we
promise
as
well
to
always
optimize
that
turnkey
solution.
That
page
grows,
that's
where
we
invest
in
and
if
we
are
good,
we
manage
to
have
80
of
our
stakeholders
running
on
the
paved
road.
That's
fine!
That's!
Basically
what
we
are
working
against!
B
It's
our
kpi
on
the
other
hand-
and
that
is
expressed
here-
we
as
well
motivate-
or
you
know
it's
important
for
us-
that
teams
can
break
out.
So
if
the,
if
the,
if
the
pay
throw
doesn't
fit
hey,
you
can
extend
it,
you
can
you
can
run
it
your
own
way
and
that's
actually
something
which
is
important
for
us
as
well,
because
if
teams
break
out
they
experiment,
they
innovate,
they
try
out
new
things
which
might
optimize
the
process
right.
B
However,
teams
know
that
if
they
break
out
that
comes
with
a
price
tag
right
so,
for
example,
if
you
use
your
own
tool
you're
as
well,
leaving
a
little
bit
the
supported
7x24
zone
right.
So
the
comfort
zone,
so
you
break
out,
you
carry
the
cost
and
therefore,
typically
teams
come
back
and
then
it's
up
to
us.
Then
our
responsibility
starts
as
a
shared
service
provider.
B
So
we
need
the
product
engineering
teams
to
innovate
the
process
they
can
do
that
much
better
than
we
and
they
need
us
to
scale
up
innovation
company
wide
and
that's
the
deal,
that's
how
we
work
pay
throat
so
and
and
by
the
way.
That
is
also
the
complete
idea
of
our
ecosystem
and
this
ecosystem,
our
cicd
stack
or
the
way
we
offer
it
is
illustrated
here
on
that
slide.
So
that
looks
might
look
a
little
bit
complicated,
but
it's
not
so.
B
We
offer
different
entry
levels
so,
for
example,
if
a
team
needs
a
ready-to-use
solution
fast,
which
is
the
general
case
for
us,
we
offer
end-to-end
pipelines
pipeline
templates
ready-mades,
as
we
call
them
or
reusable
pipeline
steps
that
you
can
simply
include
into
your
pipeline
right.
So
this
is
all
based
on
the
piper
framework,
again
deep
dive
in
a
minute
right.
So
this
is
what
we
typically
offer.
B
What
is
important
here
is
that
on
each
level
and
that's
expressed
here,
we
we
allow
teams
to
break
out
to
extend
so,
for
example,
the
piper
frameworks
is
extendable.
You
can
bring
your
own
orchestrator,
we're.
Having
teams
to
do
so
or
run
your
own
tools.
That's
all
allowed,
and
this
in
our
ecosystem
is
embedded
into
a
frame,
and
this,
this
frame
is
something
we
built
on
the
left
hand
side.
B
Our
teams
are
working
against
the
dora,
kpis
and
dora
kpis
are
team
kpis,
so,
for
example,
as
well.
We
we
have
kpis
like
we
want
our
reference
pipelines
to
do
a
technical
deployment
in
10
minutes,
so
things
like
that
and
and
the
teams
need
to
take
care
that
those
apis
are
met
right,
because
very
often
that
tightly
relates
through
the
product
architecture
and
so
on.
B
We
just
provide
teams
here
now
with
insights,
monitors
to
actually
assess
the
default
maturity
of
their
pipeline
and,
last
but
not
least,
the
the
level
down
here
or
at
the
bottom.
We
have
compliance
and
delivery
and
that's
something
I
would
like
to
explain
in
a
little
bit
more
detail
on
the
next
slide
next
slide.
Here
we
go
right.
B
B
The
first
recommendation
I
would
like
to
give
is:
don't
build
compliance
into
the
tools,
so
that
sounds
abstract.
What
I
mean
is
avoid
using
standard
tools
or
open
tools
in
a
proprietary
way,
and
this
is
honestly
something
we
did
in
the
past.
We're
trying
to
completely
get
away
from
that,
and
it's
as
well
a
pattern
that
I've
seen
many
many
times
talking
to
sap
customers
and
their
cicd
set
up.
B
So
you
would
find
everywhere,
companies
enforcing
certain
ways
to
use
maven,
for
example,
enforced
workflows
there
or
companies
enforcing
a
certain
repository
or
arc
structure
in
github
or
in
artifactory,
and
we
did
that
as
well
in
the
past.
But
honestly,
it's
the
start
of
many
problems,
because,
typically
such
things
don't
scale
because
as
soon
as
you
start
offering
tools
in
a
proprietary
way
just
to
comply
to
some
internal
standards,
developers
are
completely
confused.
B
They
don't
know
anymore
how
to
use
it,
and
google
doesn't
suddenly
doesn't
give
the
answer
anymore
right
so
and
then
the
developers
start
looking
around
okay.
Who
can
tell
me
how
to
use
that
tool?
Then
they
need
to
read
internal
wiki
pages.
They
are
not
readable,
then
they
need
to
find
the
expert
lots
of
time
right,
search
time,
wait
time
for
developers
to
actually
figure
out
how
it
should
be
used,
and
this
is
from
my
experience,
the
key
starting
point
for
a
lot
of
frustration
and
trouble.
B
The
second
recommendation
I
would
like
to
give
is,
if
you
have
internal
recommendat
regulations
like
we
have
don't
start
describing
them
on
a
wiki
page,
it's
okay,
to
have
them
on
a
wiki
page.
But
what
is
much
more
important
is
that
you
have
those
rules
documented
or
described
in
a
machine
readable
way,
because
compliance
is
something
like
an
airbag
in
the
car.
You
don't
want
to
see
that
right,
so
it
must
be
in
there,
but
you
don't
want
to
see
it.
B
B
That
must
be
completely
decoupled,
so
standards
define
qualities,
but
not
the
way
a
developer
should
work
and
which
tool
he
uses
the
contract
between
the
pipeline
and
the
compliance
system
is
a
data
contract
that
is
important,
hey
pipeline,
you
can
run,
however,
you
want,
we
don't
care,
but
I
need
to
make
a
compliance
assessment.
I
need
data
a
b
and
c
from
you
in
order
to
run,
and
this
is
the
contract.
This
is
handed
over
by
the
pipeline
to
our
compliance
system,
and
then
we
check
it.
B
B
We
create
a
github
issue
for
him
if
it's
transparency
that
is
required,
maybe
for
release
manager
working
in
the
runtime,
we
bring
transparent
to
the
relevant
tools
to
the
release
management
tools,
and
this
is
important.
This
is
how
we
work
today
and
that
heavily
speeds
up
our
the
way
we
are
producing
software
today.
Now
the
question
is:
how
do
we
provide
all
those
kind
of
principles
to
30
000
developers,
and
that
leads
to
the
topic
of
shared
coded
knowledge?
And
here
I
would
like
to
hand
over
to
to
you.
Oliver
stage
is
yours:
okay,.
C
We
have
something
which
we
call
piper
or
project
piper.
You
find
infos
on
www
dot
pipeline.
It
started
as
a
collaborative
project
already
sap
internally
in
a
source
involving
various
teams,
consuming
teams,
providing
teams
and
the
like,
and
as
in
collaborated
collaborative
approach,
collaborative
project
run
in
an
inner
source
manner.
We
very
soon
saw
it
could
be
beneficial
for
our
customers,
our
partners
for
other
people
in
the
cicd
ecosystem,
and
that's
why
we
open
sourced
it
towards
the
end
of
towards
the
end
of
2017..
C
What
is
it
about?
I
typically
say
it's
shared
coded
knowledge
or
shared
codified
knowledge
which
is
ready
to
use.
Why
do
I
say
that,
first
of
all,
we
have
a
layer
which
we
call
ready-made
pipelines.
Doug
mentioned
that
before
the
ready-made
pipelines
provide
essentially
a
complete,
continuous
deployment
pipeline
to
our
developers
from
code
commit
to
deploy,
it
can
run
fully
automatic,
including
functional
correctness,
checks,
security
checks,
compliance
checks
and
so
on
fully
full
automated
fully
automatic
from
code
commit
to
deploy
the
ready-made
pipelines.
They
use
the
hyperstep
library.
C
It's
a
pipeline
step
library
which
essentially
handles
the
interaction
with
the
various
systems.
It
handles
the
interaction
with
security
scanner.
It
handles
the
interaction
with
the
kubernetes
for
deployment,
with
a
cloud
foundry
for
deployment
and
with
various
other
tooling,
underneath
we
have
what
we
call
a
common
configuration
layer,
we'll
look
into
that
in
a
minute.
In
a
bit
more
detail,
this
common
configuration
layer
allows
us
to
configure
on
a
team
site
how
this
ready-made
pipeline
should
behave.
What
kind
of
steps
should
be
active?
C
What
kind
of
credentials
should
be
used
same
applies
for
the
steps
right.
We
we
need
certain
configuration.
We
still
try
to
keep
that
to
a
bare
minimum
to
reduce
the
cognitive
load
of
a
developer,
but
nonetheless
there
is
some
need
for
some
configuration
and
we
keep
this
in
a
common
configuration
layer.
C
C
Next
to
that,
we
have
a
config
file
in
a
young
format
which
essentially
describes
describes
what
you're
building
like
what
kind
of
build
technology
you're
using
what
kind
of
credentials
you
use
for
accessing
a
certain
security
scanning
system
and
the
light
very
important
this
we
do
have
these
separation.
We
have
these
ready-made
pipelines
which
are
provided.
That
means
it
allows
us
to
innovate
centrally.
C
C
As
you
may
know,
that's
one
of
the
core
ingredients
of
getting
into
the
elite
group.
When
it
comes
to
the
dora
research,
we
need
to
have
autonomous
teams.
That
means
we
have
this
configuration
in
a
team
on
fenner
manner,
as
well
as
the
possibility
for
doing
extensions
if
the
ready-made
pipeline
does
not
fit
in
all
cases.
The
team
is
capable
of
writing
some
extension.
A
certain
stage
can
be
extended
with
an
additional
step
or
if
a
certain
stage
doesn't
fit
at
all,
it
can
be
overwritten
by
a
team
for
sure.
C
C
C
Then
we
come
on.
We
come
to
the
team
level
on
a
team
level.
Teams
are
capable
of
defining
their
specific
configuration
for
certain
pipeline.
We
see
men,
we
see
some
areas
which
kept
this
team
specific
configuration
to
really
a
bare
minimum.
Most
of
the
configurations
are
already
provided
by
defaults.
Therefore,
the
teams
do
not
need
to
really
take
care
about
this
any
longer
and
can
focus
on
their
core
task.
C
C
Now,
let's
dive
into
an
example,
how
does
it?
How
does
this
feel
versioning
is
a
very
prominent
example.
If
you
do
very
high
frequent
deployment
to
and
high
frequent
builds,
you
need
to
have
some
kind
of
way
for
automatic
automatically
versioning
your
artifacts,
that's
what
this
artifact
repair
version
step.
Does
you?
Can
it
has
some
defaults?
The
default
is
a
cloud-based
like
versioning,
with
major
minor
patch,
adding
added
with
a
with
a
plus
a
full
commit
id.
C
C
C
Now,
not
every
not
every
team
is
going
to
work
in
the
cloud.
Some
teams
maybe
just
provide
libraries
which
need
to
have
some
versions
which
are
easily
consumable.
That
means
also
there
nothing.
You
need
to
change
to
your
flow
logic
of
the
pipeline.
It's
a
pure
configuration
setting
in
your
project,
specific
configuration,
versioning
type
library-
if
you
put
that
you
have
a
main
assembler
like
versioning
major
minor
patch.
C
Okay,
I
mentioned
we
built
heavily
on
jenkins
jenkins.
Has
a
big
market
share
in
the
area?
Therefore,
it
was
a
very,
very
safe
bet,
but
we
also
know
the
market
is
evolving.
We
have
the
continuous
delivery
foundation
with
projects
like
jenkins,
eggs,
like
tacton
and
so
on.
There's
also
proprietary
solutions
out
there
like
github
actions.
C
C
C
C
C
C
C
C
You
see,
artifact
prepared
version
called
wireshell
artifact,
prepared
version
called
wire,
jenkins
and
artifact
prepare
version
called
wire,
github
action
all
with
the
same
configuration,
and
we
call
this
agnostic
continuous
delivery,
which
should
allow
also
our
development
teams
to
act
autonomous
in
a
way
to
maybe
at
some
point
move
away
from
jenkins,
or
maybe
they
haven't
started
on
rankings.
Yet
they
want
to
directly
go
github
actions
or
techton
or
azure
devops
or
you
name
it.
C
C
C
C
We
do
we
need
to
have
it,
but
we
don't
want
to
see
it
and
then,
last
but
not
least,
having
shared
codified
knowledge,
shared
coded
knowledge,
which
is
ready
to
use
in
order
to
really
reduce
the
cognitive
load
of
the
developers.
Having
said
that,
thank
you
very
much
and
we
would
open
up
for
questions.
A
D
Your
question,
yes,
thank
you
very
much
for
the
demo
dirk
and
I
forget
the
other
gentleman's
name,
but
I
appreciate
the
demo
information
that
you
provided
to
us
question
for
you,
for
both
of
you
is:
how
long
did
it
take
you
from
from
going
from
zero
to
sixty
or
zero
to
a
hundred?
How
long
did
it
take
in
time
in
in
people.
D
D
C
C
We
do
deploys
multiple
times
per
day
into
into
the
source
code
teams
are
the
majority
of
teams
is
using
the
master
version
of
it.
Therefore,
it's
you
can
you
can
consider
it
like
like
a
sas
application
right
right,
which,
which
is
continuously
evolving,
based
on
user
feedbacks
based
on
metrics
and
so
on.
B
The
interesting
point
here,
maybe
a
week
to
add,
is
that
guess
how
many
people
actually
for
a
very
long
time
drove
that
project
piper
within
sap?
What
do
you
think
it's
exactly
one
person
and
he's
in
here
right?
So
that's
oliver,
so
it
was
for
a
very
long
time
a
one-man
person,
a
one-man
show,
and
the
point
is
that
I
don't
know
how
many
teams
contribute
to
it
or
whatever.
I
guess
yes,.
B
That's
the
key
right,
so
it's
an
inner
source
project,
it
started
as
an
inner
source
project
and
and
many
many
different
teams
contributed,
there's
a
high
number
and
then
we
decided
to
to
open
source
it.
So
it's
really
it's
even
I
wouldn't
say
it
has
an
owner
right.
I
mean
you're,
the
the
owner
officially,
but
it's
it's
a
highly
distributed
setup
within
sap,
and
this
is
the
key
of
the
success.
It's
collaborative
ownership
and
I
think
that's
that's.
That's.
D
No
single
owner,
it
can
ask
you
another
question,
sure
follow-up
question.
So
so,
when
you
started
this
project,
sap
is
big.
I
mean
I
can
only
imagine
how
many
people
in
the
in
the
company,
but
when
you
started
this
piper
project,
how
long
did
it
take
you
to
to
be
adopted
across
the
organization
you
know
so
that
it
becomes
the
gold
standard
on
how
software
is
delivered?
D
Can
can
you
give
me
some
color
around
that,
because
the
reason
I
ask
is
because
I
am
in
the
in
the
situation
right
now,
where
I'm
championing
championing
championing
a
a
for
a
common
field
framework
like
this
one.
So
that
way,
you
know
we
we
take
the
responsibility
away
from
the
developers
that
way
they
can
focus
on
delivering
features
to
our
customers.
D
So
I'm
I'm
building
a
a
common
framework
that
way
they
can
just
say
you
know
we
just
need
to
give
us.
The
entry
point
tell
us
how
you
want
how
you
build
your
code,
we
and
we
will
do
the
rest,
we'll
do
the
configuration,
the
infrastructure,
the
execution
and
the
delivery
of
the
results
so
and
and
there's
a
lot
of
mindsets
that
I'm
I'm
working
and
need
to
change
or
convince
that
this
is
the
right
approach,
because
many
development
teams
that
I'm
working
with
they
feel
like
you
know.
D
If
they
don't
have
control
of
everything,
then
they
get
they
get
worry
or
something
right.
So
my
my
job
is
more
more
around.
You
know,
yeah.
You
know
trust
me
that
you
know
your
your
code
is
is
safe
and
we,
you
know,
we
promise
you
we're
gonna
we're
gonna
provide
a
repeatable
process,
so
it's
a
little
convincing
and
I
started
this
journey
a
year
ago
and
that's
why
my
first
question
about
around
hallo.
C
In
the
end,
it's
a
multi-year
journey
right.
I
I
don't
have
the
numbers
at
hand
right,
but
we,
but
in
the
beginning
we
we
had
kind
of
an
exponential
growth
right.
We
don't.
We
don't
grow
exponentially
now
anymore,
but
because
there's
some
saturation,
but
we
started
with
a
few
teams,
essentially
the
ones
also
contributing
and
being
involved
in
the
first
area
in
the
in
the
first
developments,
and
by
now
we
are,
I
think,
between
450,
when
it
comes
to
number
of
executed
pipelines
between
400
and
500
000
a
month.