►
Description
Groovy, There's a Docker in My Application Pipeline [B] - Kris Buytaert, Inuits
In the era of Infrastructure as Code we strive to automate everything,
this talk will discuss our experiences in automating the deployment of
building of continuous delivery pipelines and solving testing and application packaging problems. We'll take a populare Open Source dashboard application and show how we build and test the platform using
containers, and we'll also discuss how we use the Jenkins DSL to
automate the generation of this pipeline so we can easily repeat this pattern for other applications.
Buzzword bingo : Docker, Jenkins, Ruby, Jenkins DSL, Puppet, Groovy,
Dashing.
About Kris Buytaert
Kris Buytaert is a long time Linux and Open Source Consultant. He's one of instigators of the devops movement, currently working for Inuits He is frequently speaking at, or organizing different international conferences and has written about the same subjects in different Books, Papers and Articles He spends most of his time working on bridging the gap between developers and operations with a strong focus on High Availability, Scalability , Virtualisation and Large Infrastructure Management projects hence trying to build infrastructures that can survive the 10th floor test, better known today as the cloud while actively promoting the devops idea ! His blog titled "Everything is a Freaking DNS Problem" can be found at http://www.krisbuytaert.be/blog/
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
As
a
title
says,
this
talk
is
about
putting
containers
in
your
pipeline.
This
is
an
introductory
talk.
It's
about
a
team
that
took
their
first
steps
to
using
containers
in
a
pipeline,
so
don't
expect
any
fancy
stuff.
This
is
the
cloud
native
track,
so
it's
there
still
room
time
to
leave
the
room
if
it's
gonna
be
too
basic
for
you.
My
name
is
Chris
Bart
I've
been
talking
at
conferences
for
the
past
two
two
decades,
I
guess
somewhere
along
that
history.
A
A
A
A
I
started
this
conference
by
accident
back
in
2009,
when
Catholic
boy
and
I
were
talking
about
how
he
went
to
conferences
where
we
talked
about
operation
stuff,
how
we
went
to
conferences,
how
we
met
a
lot
of
people
there
on
the
development
part,
but
there
was
no
conference
there,
where
we
were
actually
bridging
the
gap
where
people
from
both
sides
of
the
audience
were
present.
So
we
could
discuss
the
real
problems
we
had,
which
was
deploying
delivering
software.
A
There
was
philosophy
in
the
States,
but
in
Europe
there
was
pretty
much
nothing.
So
we
had
the
crazy
idea
to
run
this
really
small
conference
and
we
did
that
in
Ghent
in
October
2009.
We
had
liked
69
people
there
and
two
weeks
ago
we
went
to
Beijing
and
there
were
1200
people
there
and
so
completely
crazy.
That's
how
DevOps
days
could
start
our
DevOps?
The
movement
got
started
and
when
we
talked
about
this
thing,
there's
Damon
Edwards
and
John
Willis,
who
were
running
their
podcast,
the
DevOps
cafe.
A
They
were
interviewing
a
bunch
of
people
and
from
those
interviews
they
came
on
to
four
key
components
which
for
them
meant
DevOps.
It
was
about
the
culture
of
the
organization.
How
did
it
dealt
with
their
people,
how
they
took
on
projects
how
they
looked
at
working
together?
It
was
about
automation
and
a
lot
of
what
we're
going
to
talk
about
today
is
about
automation.
It
was
about
measurement
and
monitoring
and
metrics,
and
it
was
about
sharing
those
experiences.
So.
A
So
this
talk,
I'm
gonna
say
this
again:
it's
really
about
a
team
that
had
a
deployment
problem
and
figured
out
hey
what.
If
we
try
this
for
the
very
first
time
with
containers
and
was
a
team
that
was
pretty
advanced
in
doing
infrastructure
as
code,
mostly
puppet,
everything
was
automated,
they
could
spin
up
machines.
A
Ten
fifteen
identically
I
hit
clean
roles
and
profiles
patterns
for
the
people
out
there
who
are
familiar
with
puppet,
but
they
have
not
yet
used
containers
or
docker,
so
this
was
their
first
journey
in
their
figuring
out
why
they
did
it
and
how
they
did
that,
so
what
they
were
doing
was
basically
build
pipeline.
If
you
look
at
the
continued
delivery
pipeline,
if
you
look
at
the
AI
pipeline,
the
idea
to
check
in
code
in
version
control,
you
building
do
some
unit
tests.
A
If
that
fails,
you
basically
go
back
to
the
first
phase
and
you
keep
trying
till
every
single
party
screen.
Trust
me.
There's
people
who
just
hey
things,
didn't
go
further
and
forget
about
all
the
other
tests
and
then
figure
out
later
in
the
pipeline
that
they
actually
fixed
the
wrong
test
or
introduced
more
bugs
than
they
fixed.
If
you
do
this
with
Jenkins,
you
can
get
things
like
this
so
unit.
A
Another
thing
they
have
a
lot
of
Jenkins
in
place:
they
had
a
lot
of
manual
work
into
actually
setting
up
a
Jenkins
and
that's
also
a
problem
they
were
trying
to
tackle.
So
this
is
an
example
of
a
very
green
working
and
very
old
puppet
pipeline
in
Jamie's
world
screenshot
from
2012,
so
deploying
software
and
being
able
to
do
that
continuously.
A
If
you
look
at
the
release
notes
from
the
point
eight
or
from
Etsy
back
in
2010,
they
said
that
this
is
something
that
we
should
all
agree
on:
the
ability
to
deploy
software
stabili
quickly
and
safely.
That's
something
that,
if
you're
working
with
an
Operations
team
up
with
a
development
team,
you
should
not
be
discussing.
That
should
be
a
given
and
that's
the
main
problem
behind
continuous
delivery
points.
You
want
to
be
able
to
say
at
any
point
in
your
software
delivery,
tragic
push
to
production.
We
know
that
we
have
a
version
which
is
stable.
A
We
know
that
we
are
doing
this
we've
been
doing
this
before
and
we
don't
need
20
people
in
a
room
on
a
Friday
evening
to
actually
fix
this.
So
that's
kind
of
a
challenge
that
people
have
so
in
order
to
do
that,
people
are
looking
to
find
an
artifact
which
they
can
take
from
development
all
the
way
to
production
and
to
all
the
different
lot
of
stages:
shadow
production
acceptance,
disaster
recovery
and
that
artifact
should
be
unmodified.
A
It
should
be
the
same
all
over
it
can
be
config
there.
That's
added
to
that
artifact,
but
the
binary
should
be
identical.
So
from
an
ops
point
of
view,
we
like
to
package
stuff.
Typically,
we
like
to
package
software
as
an
RPM
Debian
package,
because
it
gives
us
that
security
that
we
know
that
that
package
has
not
been
modified.
A
The
number
of
organizations
our
walk
into
where
the
deployment
is
still
happening
like
so
we
generate
a
jar
and
then
we
copy
that
jar
on
through
a
file
share,
and
then
somebody
else
copies
that
file
to
another
file
share
and
then
it's
running
in
production
and
they're.
Absolutely
not
sure,
if
that
in
which
they've
just
copied
over
samba
file
share
to
a
server.
It's
actually
the
thing
that
just
got
tested
or
built
by
developer,
just
put
in
place
randomly
by
some
buddy.
It's
still
current
reality.
A
This
team
was
already
a
bit
more
advanced.
They
could
actually
build
packages,
deliver
packages
and
make
sure
that
they
got
deployed
and
they
got
by
using
packages.
They
got
consistency,
they
killed
security,
they
got
the
dependencies
and
if
a
file
was
modified
on
a
file
system,
your
package
management
system
can
tell
you
they
could
uniquely
identify
where
the
package
was
coming
from
how
it
was
built,
because
the
metadata
had
information
about
how
most
of
the
packages
were
built.
A
There
was
a
bunch
of
other
reasons
why
they
do
that.
So
when
we
started
that
project
there
had
a
lot
of
things
in
place
already,
but
the
biggest
challenge
they
had
was
tools
like
Ruby
packages,
Python
packages
PHP
where
they
were
not
having
consistent
built
where
developers
were
frequently
randomly
taking
stuff
from
the
internet.
They
had
huge
dependency
change
and
we're
trying
to
fix
that
and
one
of
those
packages.
One
of
those
tools
was
actually
dashing
who
knows
dashing
who's
using
it.
A
Okay,
so
dashing
likes.
This
picture
show
allows
you
to
build
dashboards.
Allows
you
to
take
information
from
a
lot
of
data.
Sources
is
actually
a
screenshot
from
one
of
our
production
stacks,
which
shows
a
number
of
things
about
Jenkins
built
a
number
of
things
by
a
different
Foreman
stacks,
a
number
of
picking
up
platforms,
and
this
is
actually
data
coming
right
out
of
graphite.
A
So
you
can
build
that
and
give
every
team
dashboard
which
they
want
to
use
which
they
like
to
look
at,
so
we've
been
using
dashing
for
quite
a
number
of
years
now
and
suddenly
we
came
to
the
realization
well,
this
project
is
that
there's
no
development
on
it
anymore,
but
nothing
is
more
true.
It's
actually
been
forked,
it's
been
renamed
by
now,
and
development
is
still
going
on,
but
it
was
kind
of
the
at
the
moment
that
we
started
this
project
to
automate
the
deployment
of
dashing
completely
that
this
happened.
A
So
it's
kind
of
weird
there's
a
couple
of
things:
I
really
like
about
dashing
there's
a
couple
of
things:
I
really
hate
about
dashing
the
good
part.
Is
there
there's
a
huge
community
out
there
with
a
lot
of
widgets
with
a
lot
of
things
you
can
just
find
on
the
Internet?
It's
easy
to
debug,
it's
pretty
simple,
to
write
additional
modules
in
that's
good.
The
batting
is
in
order
to
deploy
it
you're
in
ruby,
gem
hell,
there's
really
weird
ways
they
think
about
deployment,
and
a
lot
of
the
configuration
is
actually
in
the
code.
A
If
you
look,
for
example,
at
the
way
these
different,
a
kinga's
are
being
monitored,
they're.
Actually
the
list
of
API
endpoints,
where
they
have
to
query,
is
in
the
code
that's
pretty
ugly,
and
then
it
goes
up.
I
mean
you
do
gem
install
dashing
and
suddenly
five
to
ten
years
ago,
said:
hey!
If
you
do
maven
build
them,
you
get
the
old
internet.
Now
the
same
thing
is
happening
with
work
Python,
which
Ruby,
but
simply
packages
with
composure.
All
of
those
things
adjust
the
new
internet
and
the
new
maven.
A
Sorry,
so
we
wonder
about
reproducibility,
we
wonder
about
how
can
we
even
ensure
that
if
we
build
it
tomorrow,
it's
gonna
be
exactly
the
same.
So
in
his
organization?
Typically,
their
style
of
deployment
was
we
package
everything
there
were
a
rel
central
shop
and
a
lot
of
those
packages
were
not
up
to
distribution
standards.
They
have
no
incentive
of
building
their
own
software
and
shipping
it
to
an
upstream
distribution.
So
they
build
those
packages
with
fpm.
A
A
So
they
pretty
much
lived
up
to
the
PCs
pattern,
pts
being
packaged
config
service,
but
now
the
thing
was
they
needed
to
have
a
build
environment
for
a
Ruby
package,
and
we
knew
upfront
that
this
was
not
gonna,
be
the
only
Ruby
project
and
for
dashing
we
had
a
bunch
of
specific
dependencies.
We
had
really
we
needed
to
that
one.
We
already
knew
there
was
another
project
coming
up.
That
was
gonna
need
a
totally
different
Ruby
version.
A
A
We
can
build
everything
in
there
and
when
it's
done,
we
just
throw
it
away
and
you'd
actually
took
about
a
week
and
a
half
of
discussion
to
to
get
people
to
convinced
that
this
was
maybe
the
first
project
to
start
trying
this
in
a
container,
because
they
have
not
really
a
use
case
to
use
containers.
Yet
so
we're
gonna
do
this
in
containers.
A
So
we
need
to
build
a
bunch
of
pipelines,
a
pipeline
for
dashing
a
pipeline
for
the
actual
dashboard
so
that
we
could
deploy
the
dashboard
I'm
dashing
itself
independently,
because
the
dashboards
people
were
working
on
we're
gonna
be
more
frequently
updated
than
actually
dashing
as
a
software.
And
what
we
saw
previously
is
that
people
will
they
were
deploying
dashing,
but
then
they
were
logged
onto
the
box
and
they
modified
the
dashboards
and
the
templates
and
all
the
scripting
in
between
and
somebody
else
then
used
version
control
and
everything
got
overwritten.
A
So
we
needed
to
have
a
way
that
when
we
put
something
and
get
it
was
being
committed,
was
being
tested
and
moved
to
production,
because
the
other
thing
we
figured
out
is,
while
those
people
were
hacking
in
production,
they
often
made
simple
Ruby
errors
or
missed
out
gems
that
they
started
depending
on
and
suddenly
the
whole
dashboard
started
failing.
So
we
need
also
to
have
a
test
environment
which
we
could
easily
spin
up
and
test.
The
application
with
the
Jenkins
stack
when
we
started
out
was
pretty
simple.
A
It
was
new
brand
new
Jenkins,
because
this
one
was
a
moment.
We
were
gonna
use,
containers
on
and
together
with
introduction
of
containers.
We
also
said
we're
not
gonna,
allow
manual
job
creations
on
this
anymore.
I'll
come
back
to
that
later,
and
we
also
said:
there's
gonna
be
a
development
Jenkins
where
we
build
jobs
and
once
those
jobs
are
really
stable,
we're
gonna,
move
them
to
production
Jenkins,
where
we're
gonna
have
completely
different
applications,
all
fully
generated
building
those
things.
A
A
How
did
you
start
started
out
with
basically
an
empty
container?
We
took
the
upstream
CentOS
container
because
well,
the
shop
was
running
CentOS
and
we
were
gonna
package
rpms,
so
we
needed
all
of
those
dependencies.
So
that's
what
we
started
from
we
added
fpm
through
it
with
the
Ruby
dependencies.
We
had
a
repositories
for
eople
and
all
the
building
for
all
the
Ruby
packages,
and
then
we
started
experimenting
we're
actually
getting
these
to
work
from
from
Jenkins.
A
A
One
of
the
things
that
didn't
work
was,
for
example,
was
a
pretty
enterprise-e
environment,
actually
a
government
agency,
and
they
required
HTTP
proxies
to
be
passed
to
everything.
So
even
in
the
container,
they
need
to
go
through
an
HTTP
proxy
to
get
the
gems
from
everywhere,
and
there
was
no
way
we
could
actually
configure
that
from
Jenkins
from
the
UI
from
plugins.
A
A
A
He's
already
insecure
registries
and
the
registries
edit,
which
I'll
come
back
home
later,
so
they
built
a
basic
empty
CentOS
container
as
the
basic
start
for
everything
we're
going
to
build,
then
you
wonder
from
an
Operations
point
of
view:
I
need
our
VM.
How
am
I
gonna?
Have
our
VM
installed?
There's
no
packages,
there's
documentation,
which
basically
says:
oh
just
curl,
this
from
the
internet
and
you're
looking
at
like
now.
A
This
is
not
how
I
want
to
deploy
software
Andrew
clay
Schafer
at
conflict
management
camp
two
and
a
half
years
ago
called
this
having
unprotected
sex,
but
the
Internet
and
that's
kind
of
what
they
were
doing
and
we
said
okay.
So
why
are
we
gonna
work
around
this
completely
or
we
figure
out?
Well,
it's
a
container,
we're
gonna,
throw
it
away.
You
know
Yolo,
let's
just
do
this
and
we
ignored
it,
and
so
we
had
the
first
container,
the
second
step
already
the
second
layer,
which
was
a
container
image
with
our
VM.
A
A
So
now
we
had
like
four
layers
on
top
of
each
other
and
we
rebuilt
this
thing
like
once
or
twice,
and
we
figured
out
well
what,
if
we
put
all
the
steps
in
there
we
get
a
smaller
image
will
get
less
layers.
It's
gonna
be
much
more
economic
to
do
so
so
we
killed
a
bunch
of
those
layers
of
and
actually
did
most
of
those
steps
and
won.
A
So
now
we
add
an
empty
container
running
dashing
next
thing:
is
we
needed
to
have
a
reproducible
way
of
getting
all
the
small
widgets
from
dashing
into
that
environment?
And
then
there
was
more
the
way
you
get
a
widget
and
a
way
people
publish,
widget
and
github,
it's
basically
by
publishing
a
guest
and
get
a
guest
ID,
and
that's
how
people
share
their
code.
You
see
the
double
facepalm
there
right,
that's
even
more
and
protective
case
really
Internet.
So
we're
like.
We
cannot
do
this.
We
need
to
version
this.
A
We
need
to
actually
get
those
files
in
there
create
local
repositories
fix
all
of
this,
and
that
would
be
yet
another
way
how
to
do
those
pipelines.
So
that
was
another
container
that
was
based
on
the
same.
We
took
the
container
we
just
built
and
we
started
actually
deploying
the
code
for
the
dashboards
into
that
container.
A
We
cleaned
up
a
bunch
of
things
because
we
didn't
want
to
default.
The
Ruby
libraries
for
Twitter
there
and
again
the
same
exercise
new
code,
new
gist
new
Ruby
dependencies.
So
we
need
to
have
bundle,
install
get
all
the
dependencies
from
the
internet
and
build
that.
So
we
have
two
packages.
Now
we
had
user
local,
our
VM
with
all
the
dashing
code
in
the
dependencies,
and
we
have
the
local
dashing
directory
with
the
actual
packages.
A
So
what
we
could
do,
then,
let's
take
those
rpms
install
them
on
a
traditional
server
until
developers
hey,
we
just
deployed
us
go
to
that
link
and
test.
If
it's
all
right,
that's
what
most
of
the
Java
developers
were
doing
back
then
with
all
of
their
applications.
They
just
deploy
to
the
next
phase,
but
we
figured
what
we're
doing
this
container
thing
now.
What
about
we?
A
A
We
built
that
container
with
the
most
recent
dashboard
based
on
the
actual
rpm
artifacts
that
were
built
and
we
just
ran
it
and
we
figured
out
if
it's
gonna
work.
The
first
test
was
just
the
double
you
get
on
the
port,
and
if
that
gave
a
correct
return,
then
everything
was
working
and
we
could
actually,
we
weren't
sure
about
layout.
We
weren't
sure
about
the
content,
but
at
least
we
knew
that
there
was
a
dashboard
showing
and
I
was
already
an
improvement
for
that
team
based
on
the
previous
steps.
A
So
not
only
they
were
using
container
to
build
their
artifacts
that
were
going
to
ship,
but
we're
also
going
to
now
test
their
artifacts
to
in
that
container.
The
actual
deployment
of
the
artifacts
was
still
done
by
I'm
collective
from
different
vertical
machines
that
were
still
completely
managed
by
puppet.
So
when
an
artifact
was
built,
those
two
artifacts,
the
gems
in
the
dashboard,
what
they
did
for
first,
the
acceptance,
the
environment
and
then
the
production
environment
they.
So
this
is
for
the
production
environment.
A
So
they
had
solved
a
bunch
of
those
problems,
but
not
all
of
them.
I
told
before
there's
a
Jenkins
master
with
multiple
slaves
and
after
a
couple
of
days
they
add
up
more
slaves,
because
the
initial
setup
had
like
one
slave
and
everything
worked
fine
and
then
there
bumped
basically
into
the
next
problem.
A
If
you
build
the
container
on
one
note
and
then
you
from
the
test
ship
on
the
other
note,
you
don't
have
the
same
image.
Always
you
might
not
even
have
that
container
locally
on
that
machine,
so
we
figured
out
that
we
needed
to
introduce
a
local
repository
because
a
local
repository,
because
this
was
not
open-source
code.
This
was
not
code
that
we
were
going
to
publish
somewhere
on
docker
hub.
This
was
really
code
that
we
wanted
to
have
internally
and
not
being
shipped.
A
A
So
in
staging
environment
they
upload
to
one
repository
in
a
production
environment
they
upload
to
another
repository
and
they
wanted
to
keep
doing
that
same
thing
with
the
docker
images,
so
they
needed
to
have
a
way
that,
on
the
jenkins
level,
the
jobs
were
identical,
but
still
the
blogger
push
would
end
up
on
the
right
repository
and
that's
what's
in
this
config.
These
are
puppet
parameters.
This
one
is
hard-coded
as
an
example,
but
these
were
basically
pulled
out
out
of
Hira
and
depending
if
the
Jenkins
was
a
production
or
an
acceptance
box.
A
The
default
registry
to
where
push
was
happening
was
being
changed.
This
is
interesting
because
upstream
docker
doesn't
like
that
upstream
docker
thinks
you
should
not
be
using
an
internal
repository
upstream.
Locker
actually
thinks
that
you
should
be
using
their
repository
and
pay
money
for
that.
But
so
we
needed
a
local
repository
and
we
looked
at
a
couple
of
alternatives.
We
always
had
pulping
place,
but
when
we
did,
the
research
Pope
was
not
capable
of
actually
allowing
you
to
push
images.
A
We
looked
into
nexus
artifactory,
but
given
that
this
was
the
Linux
team,
not
the
Java
team,
those
people
were
really
not
that
interested
in
actually
adopting
Nexus.
For
that
there
was
a
docker
registry
which
could
run
as
a
container
and
the
question
from
a
lot
of
the
people
there
was.
We
were
just
slowly
getting
into
this
journey.
Do
you
really
want
to
have
a
piece
of
software
where
we're
going
to
heavily
depend
on
already
run
on
a
platform
that
we
don't
really
know
yet
that
we
don't
really
know
how
to
manage
yet?
A
So
there
were
a
couple
of
things
where
we
bumped
into
that
weren't
really
funny.
The
search
part
for
images
I
want
to
push
through
a
local
repository.
I
want
to
get
those
things.
First,
I'm
configuring
docker
to
by
default,
go
to
my
registry
first
apparently
docker
Inc
has
pretty
solid
IDs
on
that.
That
should
not
be
done.
Red
Hat,
however,
things
that
that
is
something
you
should
do
and
I'm
a
lot
of
other
people
are
kind
of
in
the
field.
For
that
we
say:
well:
corporate
networks
don't
always
have
full
access
to
the
outside.
A
We
want
to
have
full
control
over
what's
happening.
So
that's
another.
That's
a
fun
thing:
the
parameter
is
to
give
to
a
container
to
use
proxies
internally
said
those
environment
variables
have
been
changing
over
the
different
versions:
the
docker
and
the
Red
Hat
implementations.
They
differ.
So
those
were
a
couple
of
things
that
people
have
been
struggling
with
works
on
my
machine
as
opposed
to
works
on
the
infrastructure,
because
well
there's
a
different
version
and
there's
different
parameter
to
be
used.
We
got
bitten
by
a
bunch
of
those
quite
a
lot.
A
Can
you
spit
up
a
new
version
with
PHP
this
six
or
seven
and
try
this,
and
what
we
now
can
do
is
actually
have
containers
running
next
to
each
other
running
tests
of
future
versions
based
on
the
same
codebase
and
even
look
at
what
the
next
version
is
gonna.
Do
we
did
it
for
puppet
code?
We
do
that
for
PHP
code.
So,
rather
than
having
different
virtual
machines,
different
full
images
were
capable
of
running
those
tests.
A
We
now
have
containers
that
spin
up
and
where
the
tests
are
running
and
which
we
decommission
off
once
we
don't
need
them
anymore,
so
that
actually
brought
us
to
another
problem
which
I'm
gonna
try
to
go
over
really
fast.
It's
that
much
time,
which
is
the
manual
clicking
in
Jenkins
and
creating
of
those
pipelines
and
the
adoption
of
pipeline
is
codes
which,
however,
you're
gonna
start
building
pipelines
if
you're
gonna
build
them
straight
in
containers
or
if
you're
gonna
build
me.
A
Otherwise,
it's
kind
of
one
of
the
new
challenges
you
really
need
to
be
able
to
just
regenerate
pipelines,
regenerate
codes
and
pipelines
code
is
one
of
the
new
health
topics.
Now,
there's
a
couple
of
alternatives
to
do
that.
The
two
most
popular
today
are
the
Jenkins
drop
DSL
and
the
pipeline
plug-in
pipeline
plug-in
is
jenkins
file
and
we
looked
at
the
both
of
them
to
do
this
and
we
kind
of
ended
up
with
the
diesel
because
we
figured
out
it
was
much
more.
A
It
could
do
much
more
reuse
of
the
code
and
when
we
started
out
using
any
that
much
more
feature
than
was
much
more
elaborate
and
then
the
pipeline
plug-in
pipeline
plugin
is
slowly
moving
forward,
it's
becoming
more
and
more
popular,
but
what
we
did
with
this
project
was
the
job
diesel.
So
that's
one
where
the
DSL
is
right.
Here
we
had
a
full
Peppa
dies,
Jenkins
sit
up,
so
what
we
did
is
we
basically
would
that
job
DSL
have.
A
A
Pretty
much
all
of
these
are
generated
in
a
typical
job.
There's
the
things
you
expect
in
Jenkins,
real,
quick.
How
many
artifacts
do
you
keep
where
the
source
code
is
when
the
trigger
to
build
labels
on
where
to
run
them,
and
then
typically,
there's
also
steps
which
could
be
maven,
which
could
be
L
steps
which
could
be
all
the
typical
build
steps
in
a
Jenkins
job
and
then
also
the
different
publishers
and
those
publishers
are
typically
published,
build
trigger
another
downstream
build
archetype,
the
artifacts
and
all
of
that
stuff.
A
So,
in
short,
this
is
example
of
what
a
dashboard
build
looks
like
it
takes
a
good
checkout.
It
triggers
every
5
minutes,
it
runs
only
unloads
with
docker
and
it
actually
triggers
these
build
publishers,
clones,
the
work,
shape,
space
archives,
the
artifacts
and
then
triggers
the
next
build
the
next
test,
that's
how
they
now
completely
generate
pipelines
and
they
completely
generate
all
kinds
of
pipelines.
A
They've
eliminated
now
stuff,
like
the
promoted
bill
Brooklyn,
which
was
really
painful
now
to
get
a
clear
visual
on
where
to
click.
What
the
next
step
is
in
a
pipeline,
one
of
the
huge
problems
they
had
was
one.
You
have
one
project
you
make
a
small
modification,
you
forget
about
those
modifications
than
all
the
other
projects,
and
by
doing
this
in
code
now,
they've
actually
moved
forward
to
just
regenerating
all
the
pipeline,
and
it's
all
now
version
tuning
yet
and
that's
a
huge
advantage.
A
So
that's
in
short,
what
they
solve
to
the
Jenkins
DSL
and
what
they
solved
with
the
containers
is
that
now
they
can
actually
build
multiple
versions
of
their
applications.
They
now
have
smashing
and
dashing
next
to
each
other
testing.
They
have
different
PHP
versions
for
other
applications.
There
are
slowly
adopting
to
pull
more
functional
tests
and
run
those
functional
testing
containers
and
they
can
just
trigger
those
pipelines
automatically.
A
So
next
to
that
the
same
artifacts
that
are
built
the
same
containers
that
are
built
to
actually
run
the
tests
in
those
containers
are
now
also
slowly
being
adopted
by
the
developers
to
run
their
testing.
They
were
using
vagrant
before,
but
not
all
of
them
were
happy
with
vagrants,
mostly
because
of
speed,
mostly
because
of
running
vagrant
virtualbox
their
max,
while
all
the
Linux
guys
were
basically
running
vagrancy
and
didn't
see
a
performance
issue,
but
the
Mac
and
Windows
users
weren't
really
happy
with
it,
and
now
they
can
actually
run
them
the
same
containers.
A
So
the
big
step
forward
for
this
project
was
that
a
lot
of
people
got
involved
and
got
exposed
in
using
containers
for
the
first
time
they
saw
the
benefits
they
saw
the
drawbacks.
They
also
saw
the
fact
that
a
bunch
of
servers
still
need
to
be
rebooted
every
month,
every
month
or
actually
even
every
week,
currently
because
of
file
system
issues
and
kernel
issues,
but
at
least
now
they
know
before
they
move
completely
to
production
with
it.