►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
25 Years of (mistakes) Learning in CI/CD - Laurent Tardif, Zenika
From clearcase to modern deployment. In this talk Laurent will present a overview on how tools and practices evolve over the last 25 years. He will cover of we move from a monthly centralized team build to a distributed and continuous deployment model. How tests have impacted deployment model, how devops, docker, kube have influenced the evolution. How automation is critical today and why we continue to do the same error like depending of dynamics external dependencies in 'secure' projects.
A
Hello,
hello,
everybody,
I'm
lauren,
I'm
very
happy
to
be
there
to
talk
about
continuous
integration.
In
this
talk,
I
will
try
to
share
what
I've
learned
from
25
years
now,
basically
of
conscious
integration,
continuous
deployment
and
every
practice
related
to
have
a
better
feedback
loop
for
developers.
A
A
During
this
quick
evolution,
I've
learned
a
lot
of
stuff,
and
after
that
I
work
for
agilent
technology.
I
work
also
for
zenika
today,
and
I
saw
a
lot
of
engineering
team
a
lot
of
continuous
education
platform
and
from
this
learning
I've
tried
to
summarize
the
key
points.
I've
learned
during
this
time.
A
So,
basically
the
older
system,
I've
shown
I've
seen
so
in
my
life,
was
clearcase
and
basically
the
idea
was
to
to
to
see
from
clearcase
to
now
what
have
changed
in
conscious
integration
and
oh
marvel
and
docker
have
changed.
A
lot
got
this
integration
process
at
my
starting
I
was
a
back-end
developer,
so
it
the
talk
will
be
java
related,
basically,
and
but
I
will
reference
other
technology
during
the
talk,
so
do
not
hesitate
if
you
are
not
java
familiar.
A
So
before
starting,
let
explain
a
bit
how
my
slide
will
be
organized
at
the
top
of
the
slide.
I
I
will
cover
the
time
period.
I
split
the
time
in
in
sixth
period.
This
is
approximately
so
do
not
blame
me
for
that,
and
I
will
look
first
at
their
own
aspect.
Soldering
is
everything
related
to
the
one
aspect
of
the
system?
It
can
be
a
docker
cabinet,
kubernetes
ansible,
this
kind
of
technology.
A
I
will
have
a
look
also
at
the
main
language
at
this
time.
As
an
example,
at
the
beginning,
it
was
mainly
c
and
c
plus
plus
so
the
beginning
was
the
80s,
so
nearly
40
years
now
just
to
to
illustrate
the
beginning,
not
the
beginning
of
the
software
but
beginning
of
constitute
the
question
like
system.
A
A
So,
just
to
give
you
all
the
stuff
will
be
related,
so
at
the
beginning,
in
the
80s,
I
would
just
remove
my
face
for
one
minute
just
to
allow
you
to
to
see
nicely
the
the
timeline.
So
the
idea
is
in
the
80s.
We
were
working
with
c
plus,
plus
bank
file,
cvs
per
force
and
clearcase.
Also
clearcase
is
for
the
photos.
If
you
don't
know
it,
it's
a
mix
of
scm,
build
mechanism,
interface,
graphic
also
for
authoring
the
the
source
file.
It's
everything
embedded.
A
A
A
A
Why
the
third
wednesday
of
the
month,
because
it
took
him
nearly
one
weeks
to
merge
the
branch
to
try
and
to
try
to
compile
successfully
the
software,
not
even
having
a
bug
free
and
a
running
software,
just
to
compile
it
just
to
give
you
an
idea
where
we
start
40
years
ago,
and
despite
that,
the
binary
were
not
portable
from
one
server
to
another
one.
So
that
was
very
difficult
to
share
binaries
and
to
to
deploy
the
software.
A
A
The
key
idea
of
the
java
was
compiled
once
only
everywhere,
so
the
that
was
very
important
because
it
tried
to
remove
the
dependency
with
the
system.
That
was
not
perfect.
That
was
not
the
magic
solution
to
all
the
issue,
but
at
least
when
you
build
a
jar
file
on
your
server,
you
are
able
to
run
it
somewhere
else
without
too
many
problems,
so
it
reduced
a
lot.
The
effort
to
make
it
renewable
on
several
cells
and
side
effect
of
that
it
was
also
the
beginning
of
continuous
integration.
A
Not
what
I
call
the
beginning
is
the
first
version
of
continuum
cross
control,
this
kind
of
tool
that
allows
a
team
to
build
on
a
regular
basis,
their
work.
It
was
not
only
a
side
effect
of
java.
It's
also
the
team
starting
to
become
bigger
and
bigger,
even
sometimes
distribute
across
the
world,
and
the
teams
understand
that
having
something
difficult
to
install
or
to
deploy
is
a
mess.
So
we
start
to
build
on
regular
basis
to
have
something
running
somewhere
else
done
on
our
server.
A
As
example,
cvs
was
a
source
control
management
system.
It's
it's
many
bears
at
the
file
level.
What
I
call
the
fire
level.
It
was
quite
common
to
forget
to
commit
one
file
and
the
system.
Don't
just
tell
you
a
little
warning
if,
if
we
look
at
git
today
did
a
work
at
the
repository
level,
so
you
commit
the
world
system
and
the
wall
repository
makes
sense.
Did
it
was
the
file
level
and
it
was
not
easy
to
forget
to
commit
one
file
or
to
push
one
file.
A
Just
make
file
was
very
designed
to
build
binaries.
Basically,
you
have
a
set
of
c
files.
You
build
object
files,
you
built
libraries
and
that's
it
without
you
start
to
add
some
extra
step
like
tools
like
pmd
feinberg
check
style,
to
check
either
the
syntax
or
to
identify
some
potential
bug
or
bad
coding
practice
it's
the
beginning
of
solar
and
bi,
and
it
was
so
complex
that
it
took
nearly
a
full-time
engineer
to
do
that,
and
we
call
that
the
build
master
at
this
time.
A
A
A
A
So
that's
also
the
beginning
of
outside
the
father
of
jenkins.
For
for
for
those
of
you,
it's
also
the
beginning
of
the
devops
movement,
development
teams
start
to
become
more
and
more
efficient
and
we
start
to
to
share
libraries,
not
only
source
code
with
archive,
for
example,
and
we
start
to
automate
deployment
and
we
see
different
kind
of
tools.
Coming
from
my
point
of
view,
some
of
the
tool
came
from
the
development
team.
A
A
Now
with
docker
financiable,
we
see
that
both
team
use
the
same
tool,
but
at
the
beginning
it
was
quite
common
to
see
development
team
using
one
tool
and
operation
team
using
another
tool.
It's
a
good
waste
of
time
so
and
it's
also
the
beginning
of
sonar
so
using
a
static
code
analysis
to
become
more
and
common,
and
we
start
to
have
a
global
view
of
the
quality
of
the
project
or
the
set
of
project
file
company
and
of
course,
I
start
as
a
build
master.
A
I
start
to
customize
everything
because
the
tool
allowed
me
to
customize
everything.
So
I
did
it
and
I
think
that
build
is
very
specific
to
my
project.
I
download
tools
I
download
dependency,
I
compile,
I
run
tests
and
package
and
generate
the
package
and
I'm
running
code
quality
tools
and
in
fact
every
everyone
do
that,
and
maven
was
the
first
time
that
we
start
to
promote
a
convention
and
standardization
versus
too
much
customization.
A
A
Maven,
you
can
add
thousands
of
plugins
to
a
fancy
report
and
whatever
you
want
in
jenkins,
you
can
add
also
the
plugin
to
do
the
same
stuff,
but
you
need
to
have
everything
in
sync.
So
that
means
that
if
several
teams
use
the
same
jenkins,
the
several
teams
need
to
be
in
sync
and
you
add
a
bottleneck
between
all
your
team.
That's
not
a
good
idea,
generally
speaking,
try
to
be
more
independent
as
possible
from
your
infrastructure.
A
At
the
beginning,
the
beginning,
it
was
already
nearly
20
years,
but
we
are
still
dependent.
There
is
a
height
strong
coupling
between
the
gdk
and
the
tool
itself
and
because
we
were
massively
java
this
time.
In
fact,
you
had
a
strong
dependency
between
the
java
version.
You
are
using
on
your
project
and
the
java
version
of
your
outside.
A
A
A
That's
the
beginning
of
jenkins,
because
of
the
split
between
edson
and
jenkins.
It's
time
when
we
start
to
have
motivation
of
the
tooling.
So
in
jenkins
we
start
to
be
able
to
specify
multiple
gdk
and
to
specify
which
gdk
we
want
for
each
project.
So
we
start
to
cut
the
strong
dependency
between
the
tooling
of
jenkins
itself
and
the
your
project.
A
A
That
was
the
beginning,
as
example,
of
the
the
the
versioning
of
the
binaries
in
mother,
with
the
pump
parent
for
example,
and
where
we
can
stick
the
version
like
the
log
file
in
javascript,
so
it
appeared
only
five
years
after
marvin.
Basically,
so
it
took
time
to
understand
that
it
was
important
to
fix
dependency
between
project.
A
The
the
test
was
difficult
to
unit
tests
are
easy
to
deploy,
of
course,
but
when
you
have
integration
tests,
when
you
have
a
performance
test,
when
you
have
functional
testing,
it's
it's
become
difficult
to
deploy
the
environment
because
you
need
to
deploy
gdk,
you
need
to
deploy
a
tomcat,
as
example.
You
need
to
deploy
your
short
file.
Your
configuration
file
and
automate.
A
This
this
installation
become
more
and
more
complex
and
we'll
see
that
the
next
step
after
this
period,
the
beginning
of
francis
docker,
which
was
an
easy
way
for
developers
to
deploy
infrastructure
and
to
use
the
same
tool
than
production
of
tips.
That
was
important
and
also
for
me.
One
of
the
key
points
at
this
point
of
time
was
the
beginning
of
circle.
Ci.
We
were
the
first
to
introduce
the
concept
that
the
the
the
job
description
was
part
of
the
source
code.
That
was
very
important,
jenkins
and
its
own
and
everything.
A
A
You
impact
all
your
branch,
all
your
version
and
when
you
are
something
in
production,
and
you
want
to
update
you-
need
to
update
the
future
the
present,
but
also
the
past,
and
either
you're
not
able
to
build
anymore
or
you
do
a
duplication
of
your
build
system
to
be
able
to
beat
the
past
and
the
present
that
was
a
mess
secret.
Cia
was
the
first
teams
that
basically
introduced
the
concept
that
the
configuration
file
itself
itself.
A
A
So
now
it's
quite
common
to
have
all
the
build
mechanism
use
a
descriptor
inside
the
code.
That's
very
important,
that's
a
very,
very,
very
important
key
point
just
to
to
make
it.
If
we
look
at
the
past,
we
have
that
in
clear
case,
40
years
before,
so
we
start
to
isolate
everything,
but
that
was
not
a
good
idea
for
some
point
and
we
start
again
to
to
link
stuff
that
need
to
be
linked.
Oh
you
read.
The
code
is
part
of
the
code.
A
It's
part
of
the
life
of
the
code,
that's
very,
very
important,
so
just
to
have
a
quickly
now
in
jenkins.
So,
basically
a
bit
more
than
five
years
ago,
we
were
able
to
have
a
different
gdk
version
for
runtime
for
dependency
management
and
we're
able
to
run
docker.
So
we
are
able
to
isolate
every
process
nicely.
A
A
So
also
the
the
key
point
is
now
it's
quite
common
to
have
a
lot
of
tools
that
do
not
require
a
lot
of
customization,
and
that
was
one
of
the
key
points.
If
your
project
needs
customization,
you
need
to
to
to
spend
five
minutes
to
ask
why
I've
seen
hundreds
of
projects.
I
work
on
large
systems,
small
system
fastens,
faster
scale-up
system.
What
in
fact
you
it's
very
rare
that
you
need
a
strong
customization
and
over
time,
every
team
that
need
that
did
the
story.
A
A
So
to
try
to
make
a
quick
summary
of
what
we
see,
keep
in
mind
that
if
you
want
to
do
customization
integration
is
to
work
in
parallel
and
it's
not
because
you
want
to
to
be
able
to
commit
in
a
future
branch
where
you
are
alone
for
six
months
now,
conscious
infiltration
is
integrating
code
with
the
team
on
a
regular
basis.
Several
times
a
day
you
share
with
the
team,
and
you
update
from
the
team.
That's
very
important.
A
A
A
One
tool
is
simple,
but
you
may
stick
at
some
point.
Several
tool
is
easier
and
you
can
do
fancy
stuff,
but
you
need
to
get
a
consistency
between
all
the
tools.
That's
balanced
between
the
two
projects,
you
you
need
to
take
care,
and
the
key
point
is
have
try
to
be
look
at
that
to
have
a
local
link
between
all
your
tools
and
your
code
to
make
it
more
easy
easier
to
to
evolve.
A
The
pipeline
should
be
easy
to
diagnose,
to
restart
it
should
be
able
to
run
in
parallel,
so
it
should
also,
for
example,
if
you
move
to
monorepo,
your
pipeline
should
be
able
to
handle
that
easily,
and
so
that's
a
key
point
to
keep
in
mind
so
in
summaries.
In
summary,
sorry,
this
is
a
subset
of
the
tool
and
if
you
look
on
internet,
you
may
find
thousands
of
tool
involved.
I
just
put
some
key
points
here,
so
it's
a
system
that
evolved
a
lot.
A
Now
it's
more
an
acceleration
of
the
challenge
in
the
deployment
process
with
the
ansible
that
makes
stuff
easier
to
develop.
It's
continuous
changing
mechanism.
Also,
there
is
a
new
challenge
so,
for
example,
big
data.
You
do
not
build
a
big
data
project.
I'd
like
to
build
a
software
project.
There
is
also
a
lot
of
tools
that
try
to
make
the
integration
of
the
civil
programming
language
in
your
in
your
company
more
easier.
A
If
you
want
to
look
a
look
at
the
basil,
candy
core
launcher,
there's
a
lot
of
tools,
so
that's
it
for
today.
I
think
I
took
25
minutes
so
it
let
us
sometimes
for
question
so
feel
free
to
ask
and
thanks
for
your
time,
I
hope
you
have
learned
something
and
my
slide
will
be
available
at
the
end
of
the
conference.