►
From YouTube: Case Study Conrad Electronic – From a Static Infrastructure to Continuous Delivery and the Cloud
Description
Case Study Conrad Electronic – From a Static Infrastructure to Continuous Delivery and the Cloud in One Step [B] - Tobias Baumgart, Conrad Electronic & Sebastian Scheele, Loodse
For many years, the absence of scalable QA environments has been a bottleneck within the development flow at Conrad Electronic – with major impact on overall speed and efficiency of the production lifecycle. To increase flexibility and scalability, Conrad Electronic decided to move from a static infrastructure to a dynamic scaling based on Google Cloud and Kubernetes. In this case study, Tobias Baumgart and Sebastian Scheele will show how the new cloud native infrastructure and Continuous Delivery is being implemented, what major challenges have been met throughout the process, how they have been solved, and how the new cloud set-up looks like.
About Tobias Baumgart
Tobias Baumgart is the team lead of Platform Management & Architecture at Conrad Electronic SE. He is in charge of the infrastructure transformation process. Tobias Baumgart joined Conrad Electronic in 2005 and held various positions in software development, i. a. as Senior Software Developer eCommerce.
About Sebastian Scheele
Sebastian Scheele is a co-founder of Loodse, a software company that has developed a solution for the management of multiple container clusters and provides consulting and training services in the area of cloud native strategies. He has been a major contributor to the development of K8SNIff. Prior to founding Loodse, Sebastian worked as a software developer for SAP. He holds a degree in Computer Science from the University of Applied Science and Arts of Dortmund.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Yeah,
hello,
everyone,
so
we
want
to
talk
today
about
what
we
built
together
with
Conrad
and
how
we
move
them
from
a
static
infrastructure
to
a
continuous
delivery
in
the
cloud,
especially
with
Q
Benitez.
My
name
is
Sebastian
Sheila
I
am
the
co-founder
of
Lutzer.
We
are
startup
from
Hamburg
who's,
mainly
working
on
Q
Benitez,
yeah,.
B
A
On
cloud,
we
started
at
the
beginning
with
a
POC
to
see
okay,
how
we
can
move
the
existing
application
into
the
cloud
came
up
with
the
idea,
containerized
everything
and
run
this
on
Cuba
neatest.
Do
a
pre
POC
to
test
if
this
is
a
valid
way
to
go
and
also
pushed
on
the
side
that
it's
not
only
about
a
technology.
A
So
you
also
must
talk
about
how
to
optimize
your
process,
how
to
support
your
developers
to
moving
in
a
new
environment
and
that
the
new,
flexible
infrastructure
can
be
really
used
and
because
it's
not
enough
to
only
have
a
new
infrastructure
and
you
follow
your
old
processes.
And
so
we
start
also
thinking
about
how
we
can
optimize.
The
process
is
how
we
can
change
the
development
flow.
A
So
this
this
was
a
common
situation
at
conrad
at
at
that
time,
when
we
started
the
project
in
general.
Of
course,
each
developer
had
his
local
environment,
but
then
there
was
one
integration,
sister
or
two
integration
system.
Integration
system
was
mainly
only
used
to
see
if
everything
is
built,
they
were
on
a
really
data
on
it,
so
you
could
not
really
run
tests
on
it.
A
Then
there
was
two
consolidation
systems
where
all
the
tests
will
happen,
and
then
you
had
one
pre-production
and
one
production
mention,
and
she
was
mostly
one
from
the
integration
test
and
one
from
the
consideration
was
every
time
blocked
for
bug-fix
releases
for
important
fixes.
So
at
the
end
for
really
going
forward
with
your
development,
you
only
really
had
one
line
for
for
integration
and
consolidation,
so
it
was
everytime
hard
or
it
was
every
time
the
case.
Okay,
first,
you
must
merge
all
your
features
together
and
then
it
was
not
really
possible
to
test
features
independently.
A
Everything
was
first
merge
together
and
when
it
comes,
it
needs
also
a
lot
of
time
from
going
from
integration
to
consolidation
and
only
really
on
the
consolidation.
The
real
testing
could
happen.
The
developer
were
already
on
a
stage
or
on
a
net
next
feature,
and
then
he
gets
a
feedback
or
say:
okay,
something
is
not
working,
so
he
must
go
back
to
his
previous
task.
Continuous
development
and
yeah
pushes
again
wait
a
long
time
get
at
some
point
the
feedback,
so
the
moving
forward
with
the
features
was
quite
slow
and
the
idea
was
okay.
A
Of
course,
we
need
one
production
and
one
staging,
but
to
get
to
a
setup
that
we
have
like
n
development
landscape.
So
for
each
feature
we
want
to
have
a
separate
landscape
so
that
we
can
also
involve
test
us
more
early
and
do
automated
tests
on
it
and
that
we
can
really
ensure
as
soon
as
a
feature
or
as
soon
as
a
branch
is
created
with
a
feature
the
SP.
There
will
be
also
the
possibility
to
have
a
landscape
for
it
and
not
waiting.
A
Ok,
hopefully,
I
can
test
this
soon
and
not
like
testing
it
in
in
1
months.
So
yeah
this
a
little
bit
more
in
detail.
So
we
had
the
local
development
with
all
the
features.
Then
we
merge
everything
together
and
have
already
early
release,
but
integrations
was
only
ok,
its
merged.
We
can
build
it,
but
that's
it.
So
there
was
not
really
testing.
A
There
were
only
really
a
small
amount
of
data
not
much
to
test
so
then
it
goes
to
consolidation
and
then
the
wheel
testing
starts,
but
here
also
was
a
problem
at
that
time
there
was
no
really
automated
or
not
much
automated
testing,
so
it
was
really
a
lot
of
manually
testing.
The
people
were
all
the
testers
in
the
process
were
coming
in
quite
late
in
the
process
and
then
it
goes
on
staging
and
there
was
also
on
it
ability
to
do
manual
testing
and
when
you're
looking
at
from
a
lease
offer.
A
So
you
have
the
local
development
to
some
units
test,
probably
and
then
you
go
into
the
integration,
but
the
real
work
comes
on
the
on
the
accept
an
hour
or
the
consolidation
system.
So
then,
when
something
is
moving
from
integration
to
consolidation,
the
test
has
really
start
and
they
dilute
huge
block.
What's
a
must
test
and
that
they
had
like
a
week
to
test
where
they
more
or
less
were
overbooked
with
test
load,
and
then
they
had
when
X
done
and
everything
was
successful.
A
It
goes
into
production,
but
then
they
had
like
again,
one
or
two
weeks
more
or
less
nothing
to
do
and
waiting
for
the
next
feature
or
next
release
which
comes
to
the
acceptance
phase.
So
the
idea
was
also
really
we
must
move.
This
forward
must
automate
this
to
be
more
flexible
in
the
future
and
to
push
more
features
into
production,
faster.
A
A
In
the
meantime,
you
do
some
other
features
and
then
at
some
point
it
coming.
It
comes
back
and
you
first
must
lie
creasing.
Okay,
what
did
I
do?
I
did
at
this
time,
okay,
going
in
to
beg
in
this
process,
okay,
how
to
continue
so
that
you
really
can
focusing
first
finishing
one
feature
completely
to
the
end
and
then,
when
it's
tested,
it's
done.
A
You
can
pick
up
a
new
feature
and
focusing
on
the
new
features,
and
you
know
most
of
the
time
your
old
features
will
not
come
back
because
of
any
issues,
probably
because
of
new
enhancements
new
requirements,
but
not
like
okay,
doing
ping-pong
so
really
to
have
moves
the
acceptance
test
and
move
everything
more
to
the
beginning
and
have
more
tests
at
the
beginning,
so
that
move
over
from
testing
and
from
the
feature
when
it
except
all
the
tests.
It's
quite
easy
to
get
this
into
staging
and
production
and
yeah.
A
B
Okay,
how
does
it
looks
like
for
the
developers
now?
First
of
all,
I
want
to
show
you
the
network
setup
as
it
is
for
our
project.
On
the
left
side.
You
see
there
are
our
old
startle
centers.
One
is
a
lot
of
battles.
Mom,
there
is
our
main
data
center
in
all
of
our
there.
Terror
development
is
placed,
and
the
next
and
the
other
data
center
is
Conrad.
B
So
there's
our
sub
daughter
inside
it
and
both
of
them
are
connected
with
a
satellite
connection
to
a
network
network
here
to
a
VPN
network
and
also
in
that
VPN
network,
we
provided
Open
VPN
server
for
our
developers
to
get
a
secure
connection
to
that
network
and
to
our
networks
inside
that
cloud
project
and
now
to
the
cloud
project
on
we
have
one
we
have
three
another
and
that
works
there.
The
one
is
third
party
that
worked
there.
We
have
a
tour
and
a
conference
placed
in
and
that
network
is
open
and
available
over
ssl.
B
Then
we
have
our
vm
network,
that's
our
application
network
and
in
that
application
network
we
create
VMs
or
components
from
our
ato,
for
our
odds,
total
center
to
reach
out
and
one
immigration
is
finished.
We
try
to
containerize
that
things
and
move
it
into
our
kubernetes
cluster
yeah,
and
on
top
we
have
our
main
network
in
that
network.
There
is
a
Champions
and
our
Jenkins
is
for
managing
yeah.
B
The
two
is
in
there
and
also
the
births
and
deployment
scripts
are
placed
in
the
champions
and
yeah,
and
also
we
have
our
kubernetes
cluster
in
that
network.
So
about
our
cluster
setup,
we
use
our
namespaces,
we
name
our
name
spaces
as
our
develop
as
our
kids
branches,
so
every
develop
every
developer
has
is
on
the
future
branch
and
he
has
his
own
namespace
for
with
all
the
pods
on
that.
He
want
to
use
where
he
used
to
tested
things.
So.
A
The
developer
can
say:
ok
how
long
it
should
live,
and
then
we
run
the
complete
infrastructure
and
he
can
decide
ok
what
type
of
applications
so
which
feature
I
want
to
run
on
which
feature
I
want
to
be
run
on
the
middle
way
on
which
feature
I
want
to
run
the
webshop
itself
and
can
combine
this
dynamically
together.
How
the
developer
needs
it
for
his
tests
and
also
like
the
caster,
is
set
up
in
that
way
that
it's
automatically
scale
up
so
based
on
a
load.
A
It
will
scale
up
and
like
in
the
evening
or
night.
Most
of
the
namespaces
are
deleted
and
the
cluster
is
downsize,
so
that
can
ensure
all
that
we
insure
also
to
save
cost
in
that
way,
and
in
the
morning
the
developer
says:
ok,
deploy
it
again
and
then
a
few
minutes
later
he
has
his
new
testing
infrastructure
again.
Yeah.
B
And
you
also
see
we
have
a
connection
from
name
one
name
space
to
another
and
space
so
like
in
there's
the
search
pot,
we're
smoothing
in
the
right
name
space.
That's
because
nothing
changed
in
there
in
that
spot
and
we
don't
need
to
deploy
that
every
time.
So
the
developer
has
the
possibility
to
to
connect
to
a
default
ya
component
of
the
other
things
yeah.
B
B
First
of
all,
we
we
use
pit
pocket
as
soon
as
for
our
repositories,
work
it
repositories
as
management
and
in
that
a
bit
pocket.
We
have
a
post.
We
have
a
founder
plug-in
to
create
buttons
and
notifications
behind
that
buttons
at
buttons
and
notifications,
yeah
we're
not
if
you
notifications-
and
he
will
do
some
stuff.
So
here
we
have
five
buttons
there
and
on
the
right
side
we
have
our
Google
cloud
platform
and
our
Jenkins
with
boot
chops
and
our
chops.
So
when
the
developer
wants
to
compile
is
his
is
his
branch
he
it
works.
B
He
pressed
compile
button
and
Jenkins
chops
yeah
a
running,
and
after
the
build
is
finished,
the
image
is
pushed
to
the
container
registry
of
Google
snow
now,
when
they
want
to
deploy
that
thing
to
kubernetes
supressor
come
deploy,
buttons
also
have
the
possibility
to
compile
and
deploy.
So
they
don't
need
to
wait
to
the
compiling
is
finished
and
stats
deployment.
B
Scripts
were
grabbed
that
you
are
used
at
image
in
the
container
registry
and
deployed
at
to
kubernetes
so
and
then
after
the
deployment,
the
developer
will
get
an
email
with
all
the
information
she
needs
and
can
test
now,
as
and
his
as
his
branch,
then
we
also
have
to
remove
the
airport.
That's
also
possible
to
migrate
your
pull
request
and
then
the
namespace
is
also
too
heated.
Then
we
have
our
automated
testing
in
here.
Also,
that's
had
no
notification
to
our
champions
in
our
old
infrastructure
and
that
Jenkins
had
a
connection
to
our
keyword-driven
test.
B
B
So,
first
of
all
we
go
to
to
our
pit
pocket
and
in
our
bit
pockets
there
you
see
a
pro
request
from
some
developers
from
and
now
he
wanna
deploy
that
thing.
So
he
goes
through
that
to
the
buttons
and
you
see
there
there's
a
new
new
version
of
our
buttons.
Yep.
That's
changed
the
last
days.
So
now
the
developer
has
the
possibility
to
to
check
what
system
you
want.
B
So
I
wanna
have
of
my
whole
front
ins
in
it,
and
also
a
middleware
of
prize
engine
and
runtime
and
data
set
for
dead
things
and
in
another
set
I
want
to
have
our
testing
users,
our
Cuba
driven
test
users
and
our
integration
test
users
and
here's
the
time
to
live
so
I
will
place
it.
We
set
it
to
one
hour
because
I
don't
want
to
have
that
thing
of
the
day
presentation
so
here,
I
want
to
pack.
I
can
create
a
custom
namespace,
but
normally
they
were
the
next
verses
named
by
the
feature
branch.
B
So
here
I
type
custom
name
space
kook
on
demo
and
will
deployed
it.
So
nothing
will
happen
here.
So
the
developer
will
get
an
email.
That's
the
Diploma
is
started,
but
we
can
look
into
our
our
Jenkins,
so
here's
the
chop
that
will
get
a
notification
when
when
that
thing
is
finished
and
here's
he
that
Jenkins
job
the
started
on
top
you
see
a
button
is
triggered
and
Middlebury
plans
already
finished
and
the
content
employment
is
started.
B
B
Ok
and
I
want
to
see
the
front
end
deployment
will
take
a
while.
It
takes
10
to
20
minutes.
So
I
can't
show
you
the
success
of
that
deployment,
but
we
can
look
into
our
kubernetes
UI
and
look
how
the
deploy
is
going
and
let's
take
a
quick
refresh,
so
the
namespaces
it's
placed
in
there-
and
here
are
my
yep.
Yes,
technical
demo.
B
So
let's
see
two
deployments
and
you
will
see
57
seconds
ago
in
a
minute
ago
the
Diploma
started
and
yeah
it's
all
up
and
running.
So
after
all
that
thing,
I
will
get
an
email
at
email
from
Jenkins.
The
deployment
is
finished
and
I
can
test.
Now.
That's
that
thing.
So
in
that
email,
there's
a
fast
link
to
our
shop
and
I
will
check
that
really,
that's
not
the
right
name,
space
which
was
cube,
come
demo,
and
so.
A
B
Okay,
I
would
go
to
to
resides
a
namespace
I
created
before
that
presentation,
because
the
the
front
that
needs
a
little
while
to
finish
the
deployment
inside
so
I
can't
show
you
that
now,
but
I
created
the
demo.
Also
on
that
thing,
before
I
can
show
you
the
creation
date
of
testing
and
yeah.
On
that
side
you
can
see
the
shop
is
use
usable
and
the
developer
can
now
test
that
thing
and
also
our
testers
can
test
it
and
he
he
can
start
automated
tested
from
the
poor
request
back
there.
B
Our
hex
tree,
we
had
to
get
all
that
things
running
correctly.
So,
as
I
said
before,
we
had
a
satellite
connection
from
our
Google
cloud
project
to
our
old
data
centers,
and
that
thing
was
yeah
was
quite
long.
We
get
that
thing
because
our
service
providers
had
old,
firewalls
and
all
the
things,
so
it
takes
a
while
and
we
needed
to
wait
there,
but
we
don't
want
it
to
wait.
A
A
So
we
can
use
our
Express
version
for
the
test
environment
and
run
in
this
inside
the
namespace
and
in
this
kind
it's
also
not
critical
to
run
databases,
because
when
it's
question,
okay,
we
will
redeploy
it
and
it's
nothing
which
must
stay
for
long
for
lower
production,
but
it
was
yeah
along
this
Cashin
and
also
a
long
way
to
figure
out
okay.
What
we
want
to
do
with
the
database
that
is
now
the
next
step
will
be
bringing
some
production
into
it.
B
A
Especially
we
we
had
like
three
networks
to
maintain,
of
course,
on
the
Google
cloud.
It's
quite
easy,
but
we
must
get
a
commitment
from
the
economic
data
center
and
from
the
service
provider
to
get
all
connected
together
and
to
align.
This
also
align.
How
we
do
this
because,
of
course,
we
also
don't
want
to
like
use
several
things
to
manage
this
so
to
get
in
alignment.
They
have
to
say,
okay,
how
we
manage
this.
How
we
do
this
also
on
a
proper
set
up
for
the
future,
took
some
time
to
do.
Yeah.
B
And
the
next
thing
is
that
a.m.
is
pain,
so
we
use
a.m.
as
a
front-end
system,
and
that
a.m.
has
a
huge
repo
size
in
our
case,
that's
more
like
100
gigabytes
to
200
gigabytes
at
that's
all
the
assets
that
are
placed
in
there
and
every
component
of
I
am
needs
his
own
repo,
a
repo
and
yeah.
It
can't
be
shared
with
the
other
publishers
or
Altos,
and
that's
a
big
yeah
and
not
so
cool
anything
so.
A
We're
not
familiar
with
a.m.
its
Adobe
Enterprise
Content
Manager.
Currently,
it's
not
really
built
or
designed
for
running
in
container.
We
must
did
some
hacky
sings
with
a
new
version,
they're
planning
to
support
docker,
and
we
hopefully
get
also
get
rid
of
the
huge
image
size,
but
there
was,
we
have
also
had
a
discussion
doesn't
make
sense
to
containerize.
This
doesn't
really
make
sense,
or
should
we
use
plain
VMs
with,
but
at
the
end
we
decide.
Okay,
it
makes
no
different
if
we
ship
a
huge
container
or
if
we
should
ship
a
huge
image.
A
We
must
ship
this
big
size
of
data
and
it's
not
really
a
way
around.
So
we
decide.
Ok,
probably
it's
not
best
practice
for
our
containers
to
do
this,
but
yeah
images
also
will
not
bring
a
better
way.
So
we
say.
Ok,
then,
let's
do
is
this
with
bigger
images
on
on
docker,
but
then
we
have
a
line,
work
flow
for
all
the
systems
we
are
using
in
our
workflow
and
we
can
for
the
deployment.
We
can
completely
use
queue.
Bonitas,
yeah.
B
And
also,
we
have
a
thing
that
we
used
to
had
a
purse
of
that
front
end
with
our
whole
assets
restored
and
that
built
takes
more
like
more
than
8
hours.
And
so
we
we
just
can
run
that
thing
on
the
weekend
and
had
fresh
base
image
on
an
every
Monday
yeah
and
another
thing
we
did.
We
wanted
to
secure
our
network,
our
Open
VPN.
A
Because
we
started
with
all
this
Catan
rising
the
complete
application,
also,
the
developers
picks
it
up
quite
fast
and
started
using
container
in
there
local
development
workflow,
but
especially
with
a
huge,
a
repository
size
of
am
and
all
this
other
images.
We
figured
out.
Okay
downloading
every
time
the
images
from
the
Google
registry
locally-
it's
probably
not
the
best
best
way.
So
what
we
set
up
is
also
a
local
mirror
for
the
images
for
the
registry,
so
that
we
only
downloaded
once
and
not
ever
every
developer.
Everything
goes
over
the
Internet
to
download
it.
A
You
know
and
yeah
that
that
was
it,
so
that's
mainly
I
mean
mainly
the
ideas
really
one
for
each
feature,
running
it
in
Cuba,
neatest,
namespace,
completely
separated,
and
then
it's
quite
easy
to
scale.
This
scale
is
on
the
cluster.
Wise
and
scale
is
also
on
the
feature
wise
and
really
help
to
enable
the
developers
to
to
concentrate
on
the
features
and
don't
waiting
for
infrastructure.
Is
it
if
they
are
available.
A
C
C
A
A
Currently,
its
production
is
still
separated.
Production
runs
still
the
old
way,
yeah
currently
upgrading
the
cluster.
It's
not
so
critical
because
only
the
feature
branches
on
it.
There
is
currently
the
process
to
move
to
move
production
also
into
the
Google
cloud,
but
there's
still
the
question
how
we
run
this
in
production.
Do
we
put
everything
in
in
container?
Probably
not
like
am
currently
it's
not
built
for
it.
So
definitely
this
is
definitely
learning
from
it.
You
cannot
run
am
and
productions
at
scale.
In
that
way
it
will
not
work.
A
A
C
A
A
That
was
on
the
one
slide
you
saw
here
are
two
two
Jenkins
on
the
left:
one,
you
have
the
old
Jenkins
and
this
was
completely
not
scripted
and
when
we
started
we
said
okay,
no,
we
don't
want
to
go
into
all
environment.
We
want
to
use
Jenkins
files
and
build
it
probably
and
that's
the
reason
why
we
have
a
separate
Jenkins
only
for
the
stuff
and
now
probably
moving
more
and
more
and
stuff
over,
but
don't
do
it
manually
so
really
do
use
Jenkins
files
and
script.
Everything.
A
A
I
mean
secrets:
don't
must
be
secret,
so
what
currently
home
was
not
at
that
stage
that
we
can
use
it.
So
we
do
some
wreck
X
and
replacing
some
value.
Probably
that
would
be
a
next
step
to
instead
of
using
Q
CTL
and
do
our
own
or
check
there
have
a
value
file
and
using
him,
for
it
could
be
a
logical
step.
But
when
we
started
when
we
started
roundabout
yeah.
B
A
Services-
and
this
is
also
the
one-
the
idea
behind
this-
why
to
do
this-
to
have
in
the
future
more
and
more
services
and
scale
the
services,
also
because
it's
coming
more
from
an
monolith
with
some
bigger
services,
but
not
really
micro
services.
Now
it's
getting
more
and
more
service,
so,
but
in
the
future
it
could
be
hundred
services,
and
this
you
don't
want
to
manage
manually-
and
this
was
also
one
integer
to
say.
Okay,
we
want
to
have
a
flexible
environment
for
this.
B
A
Really,
depending
on
which
services
you
are
working
so
like
when
you
like,
building
for
the
front,
and
we
only
build
the
image
new
for
the
front
and
so
all
the
other
things
we
use
the
existing
one.
Where
you
can
say.
Okay,
I
want
to
use
version
X
from
from
the
middleware
and
version
Z
from
the
search.
C
A
B
Im
we
have
on
jenkins
shop.
We
have
a
possibility
to
connect
to
another
namespace,
so
on
the
deployment
on
the
bird,
it
will
change
the
dependency
to
that
to
that
force
a
middleware.
What
does
yeah,
but
it's
not
possible
for
the
developers
right
now.
So
we
are
updating
that
thing
and
maybe
it's
possible
in
the
future.
B
A
A
B
C
B
So
the
plan
is
to
have
to
develop
on
an
up-to-date
state
and
always
a
runnable
on
production.
So,
as
I
said,
we
had
to
pull
request
to
develop
and
on
the
pull
request.
Everything
need
to
be
tested
and
fixed
to
the
end,
so
the
develop
is
always
open
for
hotfix
and
when
we
have
our
tricks,
it
always
it's
Kate,
you
get
the
same
pipeline
and
it
can
be
deployed
in
yeah
again
yeah.
A
B
B
A
Cowardly,
the
existing
Langston
is
also
running
in
parallel,
not
also
so
we
can
use
go
back
to
the
old
system.
This
is
mainly
focusing
is
currently
for
the
feature
but
yeah.
The
next
step
is
involving.
This
brings
us
completely
integrators
in
the
flow
so,
and
one
topic
is
also
where
we
coming
in
discussion
completely.
How
do
we
do
hop
fixing
how
especially
not
from
the
infrastructure
from
the
process
side?
Which
branch
will
be
up-to-date
branch
and
how
to
do
this
and
how
to
merge
this
in
every
branch
yeah.
B
Yeah,
as
we
said
that
that
process
is
still
in
process
edited,
yet
things
are
still
in
process
yeah,
it's
for
us,
it's
quite
hard.
We
we
come
from
old
way
to
work
and
that's
a
new
a
while
away
is
yeah
thing.
We
we
it's
hard
for
us,
so
we
don't
use
the
perfect
way
now.
So
we
are
in
the
migration.
Now
yes,
but
is
how
it
is,
and.
A
As
I
said,
it's
really
not
only
the
infrastructure,
so
we
must
do
really
marketing
internally
into
the
organization
to
say:
okay,
what
are
the
benefits
of
this
infrastructure?
Why?
It
makes
sense
to
use
this
and,
of
course
it
will
change
your
process
and
it
will
change
how
you
flow,
how
to
develop,
but
the
benefit.
A
Is
you
get
much
more
benefits
out
of
it
that
you
can
be
concentrate
really
on
a
feature,
develop
it
to
the
end
and
not
like
waiting
for
a
feedback
two
weeks
four
weeks
later
and
then
do
it
things,
because
this
was
every
time
in
the
past
as
a
feedback.
Okay,
we
must
wait
too
long
to
get
feedback,
and
then
we
are
in
a
completely
different
topic
and
must
go
back
to
the
or
topic,
and
you
mostly
don't
know
exactly
okay
or
you.
A
You
start
first,
while
singing
okay,
what
we
did
in
the
past
and
going
into
big
business,
and
now
it's
really
really
to
push
the
development
and
make
like
marketing
around
it
and
say:
hey!
That's
the
new
cool
thing
have
a
look
at
it!
How
we
can
we
help
you
to
improve
your
ways,
and
now
we
it's
going
from
one
organization
to
another
and
try
to
pick
them
up
and
say:
okay,
use
this
as
a
new
way,
especially
when,
when
in
the
future,
the
developer
incomes,
okay,
I
think
we
are
now
also
yeah
at
the
end.