►
Description
In early 2018, Porsche set itself the goal of becoming a digital company. At that time, however, neither our corporate culture nor infrastructure supported modern software development. From a developer’s point of view, change was needed. As developers, Dennis and Alberto sat in the front row of this transformation. Among others, they adopted GitLab. Today, more than 200 developers happily rely on GitLab to provision the complete stack of cloud infrastructure and services to create their products. Porsche invested heavily in automation and offer templates to product teams to get them started quickly. The introduction of GitLab at Porsche also led to increased collaboration between product teams. It was a turning point for software development at Porsche. In this session, Porsche's Dennis Menge and Alberto Gisbert share their journey with attendees.
Speakers:
Alberto Gisbert, Software Engineer @ Porsche AG
Dennis Menge, Software Engineer @ Porsche AG
Slide deck: https://drive.google.com/open?id=1QGCWuyLdydixDFUZ855uNb4x8HraxTwZ
A
Thanks
Ralph
hi
everyone
good
morning,
it's
quite
exciting
to
be
here.
Let's
talk
about
how
we
try
to
adopt
how
we
did
indeed
a
type
of
culture
at
Porsche
and
how
gitlab
helped
us
soon
get
in
there,
but
first
things.
First,
this
is
who
we
are
here
with
me:
it's
Dennis
I
am
Alberta.
We
are
both
civil
engineers.
We
work
for
as
my
mobility
at
Porsche
and
for
those
of
you
not
familiar
with
a
company.
A
Well,
here's
some
figures,
we're
quite
a
lot
of
people
and
to
be
honest,
we
are
not
the
software
company
I
guess
you
don't
really
figure
it
out,
but
in
the
recent
years
IT
and
its
mobility
are
becoming
one
of
our
main
pillars
and
the
company
it's
really
committed
on
developing
father
of
those
businesses.
So
indeed,
what
is
it
that
we
do?
Well,
nice
cars
are
not
only,
and
in
particular
this
one,
it
really
represents
a
lot
to
us.
It
was
a
really
game
changer
for
us,
together
with
this
vehicle.
A
Oh,
it's
our
first
Olympic
vehicle
Porsche
committed
on
further
developing
and
really
investing
a
lot
of
resources
on
building
a
portfolio
of
digital
services,
and
not
only
worrying
about
making
nice
cars,
but
also
fulfilling
the
experience
of
our
customers
with
additional
digital
services.
So
what
are
these
digital
services?
So,
for
instance,
one
of
our
latest
ones
is
Apple
music
integration
in
your
car.
So
you
need
your
phone
to
play
your
music
or
phone
applications
that
allow
you
to
honk
and
flash
or
unlock
your
car
check
the
battery
level.
A
These
are
sharing
and
subscription
services
that
allow
you
to
drive
Porsches,
even
not
owning
them,
and
also
things
that
are
not
so
visible,
foreign
customers
or
equally
needed
for
making
all
these
products
be
where
they
are,
such
as
our
gravity
platform.
This
is
our
micro
services
platform
and
it's
what
Dennis
and
I
work
most
of
our
time.
So
so
far,
so
cool
right
I
mean
just
cool
stuff
and
why
there
is
a
story?
Well,
the
truth
is
it
wasn't
always
like
this?
A
There
was
a
time
in
which
it
was
really
painful
to
do
to
work
on
these
products
because
they
said
that
that
we
had
in
place
didn't
really
cope
with.
I
would
need
so
so
for
development
at
Porsche.
Didn't
start
few
years
ago,
when
we
committed
on
developing
these
digital
services,
so
for
development
existed
for
a
while,
and
we
had
after-sale
systems,
we
have
production
systems.
We
had
HR
systems
a
lot
of
things
coming
from
big
company.
I
guess
you
can
relate
and
ask
him
for
these
needs.
A
There
was
an
central
department
taking
care
of
all
these
things,
so
they
looked,
and
they
say,
let's
set
up
an
infrastructure
for
this
project
infrastructure.
For
these
projects.
They
set
up
code
repository.
Let's
set
up
a
build
tool,
let's
make
everything
for
them
taking
care
of
the
units,
and
they
did
so
so
they
built
the
whole
infrastructure
and
whole
situation
based
on
the
existing
needs
for
like
some
years
ago.
What
you
would
understand
as
regional
server
development,
then
what
happened
well
indeed,
there
was
nothing
wrong
with
this
right.
A
I
mean
it
worked
for
a
while
and
for
these
projects,
and
for
these
things
it
was
enough,
but
then
software
development
started
changing
and
people
like
us
started
joining
the
company
and
we
started
going
into
new
businesses
such
as
the
digital
services.
I
talked
about,
and
so
teams
started
popping
up
and
we
came
with
nice
ideas,
new
requirements.
We
wanted
to
go
to
the
cloud
we
didn't
want
to
deploy
on
Prem.
A
We
had
different
ways
of
thinking
how
the
artifact
should
be
built
and
what
we
were.
What
were
our
requirements
with
regards
the
build
tools
and
so
on?
So
the
thing
is,
we
came
back
to
this
IT
department
and
we
said:
hey.
We
have
these
needs,
so
how
can
we
do
it?
And
then
this
happened
conflict?
Of
course
they
were
not
prepared
for
that.
A
Many
teams
come
in
asking
new
things
and
we
quickly
ended
up
in
a
burden
trap
that
basically
led
us
to
just
frustration,
poor
performance-
and
we
basically
were
investing
most
of
our
time
in
fighting
against
this
traditional
department
that
were
reluctant
to
change
rather
than
focusing
on
our
products
and
our
services.
So,
just
to
make
you
bit
more
detail
on
how
did
it
look?
This
is
a
very
simple
diagram
of
our
infrastructure
and
on
the
right,
you'll
see
our
property
platform.
It's
a
micro
micro
services
platform
that
I
talked
about
before
and
I
never
left.
A
It
was
the
CI
CDE
build
cover
repository
set
up
that
we
had
on
Prem
one
of
the
problems
we
had,
for
instance,
were
availability.
They
were
going
down
at
least
twice
a
week
and
it
would
take
even
half
an
hour
to
go
up
again.
We
had
a
very
limited
set
of
agents
for
running
our
compilations
in
our
builds,
and
that
wasn't
the
only
problem.
A
It
was
also
each
of
the
agents
were
differently
configured,
so
you
were
not
sure
whether
if
your
bill
will
was
going
to
be
successful
or
not,
depending
on
the
aging
that
was
picked,
we
didn't
have
any
admin
permissions
for
configuring
as
well,
so
we
basically
were
sold
on
top
of
that.
We
wanted
to
deploy
on
a
cloud
platform
from
an
on-premise
structure
and
we
were
enforced
to
go
through
a
reverse
proxy
that
also
had
a
lot
of
performance
and
availability
issues.
So
basically
we
said
this
is
not
the
scaling.
This
will
eventually
kill
us.
A
A
But
the
thing
is
we
looked
around
and
we
couldn't
find
any
other
team
that
did
something
different.
They
were
all
accepting
the
travels
and
live
with
them,
so
we
didn't
want
to
do
that
and
we
decided
to
build
it
ourselves
and,
of
course
we
didn't
build
yet
another
CIC
tool,
but
we
decided
to
set
it
ourselves.
A
We
wanted
also
a
reduction
of
toolings
because
we
had
a
set
of
tools,
each
of
them
for
a
very
specific
need,
but
we
felt
that
they
were
not
properly
integrated
with
each
other.
There
were
some
logins
that
were
not
share
and
it
was
painful
to
use
as
well.
We
wanted
to
set
up
an
open-source
concept
in
like
approach
at
the
company,
but
the
truth
is
and
I
guess
you
figure
it
out
as
well.
We
are
a
very
traditional
company.
A
We
are
very
big,
so
going
to
open
source
takes
time,
at
least
what
we
achieved
is
getting
into
any
source
model
and
now
currently,
unless
someone
is
really
against
that
or
there
are
some
confidentiality
aspects
that
we
don't
take
into
account,
all
people
can
check
some
other
teams
code,
which
is
pretty
cool.
We
wanted
to
have
a
single
source
of
truth.
We
didn't
go
to.
We
didn't
want
to
go
to
different
tools,
to
check
whether
who
committed
what
or
when
was
deployed
or
what
was
the
version
or
what
was
the
18
running?
A
What
and
also
wanted
the
stateless
builds
because
well,
as
you
remember,
with
the
problem
with
the
agents,
we
got
differently
configured
agents,
we
got
entry,
producible
builds.
We
got
some
random
behavior
that
we
could
not
control
so
stateless
feels.
It
was
basically
answered
that
problem
that
we
had
and
then
as
well.
We
were
tired
of
seeing
people
clicking
through
you
eyes
for
configuring,
the
bills.
We
thought
that
wasn't
scalable.
A
Whenever
you
have
to
create
another
project,
you
couldn't
look
to
a
code
or
to
a
file
and
kind
of
get
ideas
from
it,
but
you
had
to
go
to
a
web
UI
and
eventually
means
a
check
box
and
yeah.
There
was
a
mess.
So
with
this
set
of
features
we
get
again
looked
around
and
this
time
we
did
find
what
we
thought.
It
was
a
really
good
fit
and
that's
basically
the
beginning
of
the
story
of
how
we
jumped
into
kit
lab
now.
B
B
Think
they
also
here
in
the
audience
today
today
and
props,
to
them
they're
doing
a
really
nice
job
and
what
we
did
in
the
beginning
was
just
setting
up
a
plain
instance
with
a
static
set
of
runners
and
just
playing
around
with
it.
So
we
we
just
took
a
relatively
easy
or
simple
project
and
migrated
to
get
lab
and
try
to
get
used
to
the
concept
of
mid
lab
and
that
went
really
well.
B
It
was
really
nice
for
us
and
we
then
soon
started
to
migrate
all
our
core
projects,
there,
our
platform
projects
and
also
we
got
a
high
demand
from
the
external
project
which
building
those
apps
or
services,
you've
seen
at
a
warehouse
presentation-
and
it
was
a
really
nice
experience
for
us.
So
then,
afterwards,
we
reopened
this
instance
up
for
for
the
project
and
we
quickly
realized
that
we
can't
build
another
silo
system.
B
So
we
had
to
somehow
think
about
how
can
we
integrate
gitlab
with
the
existing
on-prem
infrastructure
and
talk
to
the
guys
which
operate
the
infrastructure
on
Prem
and
got
a
really
nice
solution
to
integrate
their
IDP?
So
we
provided
a
single
sign-on
forged
lab
and
we
don't
had
to
mess
with
user
management,
creating
users
deleting
users.
It
was
all
like
given
to
us
and
we
also
enabled
repository
mirroring.
So
all
the
projects
could
just
try
out
and
still
use
the
old
tooling
they
had,
and
it
was
really
smooth.
I
mean
for
us.
B
It
was
done
in
like
one
to
two
weeks
with
about
10
projects
and
the
feedback
from
from
the
external
third-party
project
was,
was
amazing
and
then,
after
more
and
more
people
came
to
the
particular
instance,
we
quickly
realized.
It
really
makes
a
lot
of
sense
to
think
about.
How
can
we
share
tooling,
because
our
tech
landscape,
as
we've
seen
before,
is
based
on
Cloud
Foundry
and
most
of
the
projects
use
Java
and
spring
boot,
and
that's
why
it
was
really
beneficial
that
we
introduced
some
shared
built
images
and
thereby
also
shared
scripts.
B
So
everyone
could
participate
and
dead
was
the
first
occasion
where
we
really
could
enable
this
idea
of
having
an
inner
source
model
and,
firstly
in
collaboration-
and
it
really
worked
out
nicely
because
every
day
and
another
project
came
and
say
we
want
to
have
this,
can
we
build
it
and
we
just
said
Piazza
welcome
and
they
did.
It
was
really
nice.
B
Afterwards,
more
and
more
projects
joined-
and
we
really
invested,
invested
a
lot
of
time
into
infrastructure,
automation
and
user
creation
and
providing
technically
users
all
that
stuff
and
we
heavily
invested
in
automating
all
our
infrastructure.
So
we
came
up
with
an
idea
that
we
just
provide
a
configuration
file
for
a
project
which
fill
in
their
data
and
then
everything
is
set
up
automatically
then
Bill
job
on
get
levels
triggered
and
all
the
space
creation
on
Cloud
Foundry
is
done.
B
But
then
the
greater
firewall
came
around
the
corner
because
when
you
try
to
deploy
an
artifact
with
like
30
mix
of
size
to
China,
it
could
take
hours
if
it
goes
through.
So
it
was
a
huge
problem
for
us,
but
we
could
manage
it
somehow
by
doing
night
shifts
and
trying
to
deploy
and
then
leveraging
the
cloud
foundry
caching
mechanisms,
but
for
the
project
is
it
didn't
work?
So
we
had
to
think
about.
B
How
can
we
transfer
data
reliably
to
China
and
we
tried
a
lot
and
we
wanted
to
avoid
setting
up
a
different
or
parallel
develop
instance
there,
because
all
the
Chinese
colleagues
are
also
collaborating
and
working
with
us
in
all
European
instance,
and
that
works
quite
good.
And
then
we
came
up
with
the
idea
that
we
just
transfer
this
source
code
and
set
up
some
dedicated
runners
there,
which
worked
all
of
the
books.
B
So-
and
this
is
what
it
looks
now-
it's
not
completely
different-
you
can
still
see
the
on-prem
infrastructure
which
is
used,
for
instance,
as
IDP.
We
still
use
static
code
analysis
tools
from
on-prem
infrastructure
artifacts
to
an
issue
tracker,
but
the
cool
thing
is:
we
have
our
central
instance
in
Frankfurt
and
set
up
this
environment
of
runners
for
the
European
region
to
deploy
to
the
European
gravity
instance,
and
also
the
connected
runners
in
China,
which
enable
us
to
deploy
easily
within
China.
B
So,
let's
talk
about
some
results.
These
are
the
components
we
are
heavily
adopted.
We
use
the
scale-up
instance
for
one
year
now
and
one
really
nice
features
the
permissions
model
to
set
up
a
group
structure
and
share
secrets
and
share
permissions,
and
also,
what's
really
nice,
to
give
an
expiry
for
the
permissions
and
because
oftentimes
we
have
changing
personnel
and
its
really
nice
to
to
have
this
permission
model.
Also,
we
store
all
our
source
code
within
gitlab.
We
built
everything
in
get
lab.
We
completely
use
that
feature.
B
It
all
comes
down
again
to
integration
like
not
having
an
additional
tool
for
monitoring
your
services
and
for
a
secure.
We
really
would
like
to
use
these
static
security
and
code
analysis
features
of
gate
lab,
but
they
are
unfortunately
behind
the
IDE
you
made
paper
and
we
just
have
premium,
so
we
can
talk
later
and
yeah.
That's
it
if
you
have
questions
or
anything
else,
just
come
to
us.
Thank
you
very
much.
Thank
you.