►
Description
Is Continuous Delivery, a Chimera? - Olivier Vernin, CloudBees
Speakers: Olivier Vernin
The Jenkins project maintains a significant amount of services for its community. Since the beginning, those services have been transparently maintained by the community through Git repositories and we heavily rely on automation to ensure smooth collaboration with contributors around the globe. In this session, I'll talk about the challenges to operate an open infrastructure at scale. I'll review what went well in our continuous delivery journey and what didn't reach our expectations. I’ll present the processes and the tooling we put in place. As almost everything is public, the audience will be able to navigate through the Jenkins infrastructure project with the right mindset to understand how to use or not use the same path that we took.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Hi
and
welcome
today
I'm
gonna
talk
about
continuous
delivery
and
I'll
use
the
jenkins
project.
As
an
example,
my
name
is
olivier,
I'm
the
infrastructure
officer
for
the
jenkins
project.
If
you
have
any
questions,
you
can
still
contact
me
on
twitter
or
any
I
mean
I'm
available
on
other
channel
as
well.
A
Before
we
go
into
the
topic,
I
would
like
to
take
few
minutes
to
clarify
a
few
important
elements,
so
we
all
agree
on
the
same
thing
to
serve
the
first
one
is
continuous
delivery.
What's
continuous
delivery,
different
people
have
different
definition
of
continuous
delivery
and
in
my
case
I
really
love
the
one
done
by
jason
bell
and
david
farley
in
their
book,
where
they
define
it
as
iteratively
and
incrementally
deliver
value
to
the
customers.
A
So
for
me
there
are
very
four
important
words
here,
iteratively
and
incrementally,
so
we
just
want
to
move
step
by
step
and
finally,
finally,
that
notion
of
values
that
you
bring
to
customer.
So
whatever
the
tools
that
you
are
doing,
whatever
the
process
you
are
following
in
the
end,
you
want
to
make
your
customer
happy.
A
A
The
improvement
made
on
the
tool,
the
studies
using
the
metrics
that
you
can
use
like
time
to
market
time
to
market
is
how
long
does
it
takes
you
between
the
moment,
you
code,
something
you
commit
that
change
and
it
benefits
the
end
users
and
obviously,
if
you
want
to
to
increase
the
speed
of
delivering
values
to
your
customer,
what
yeah
it's
on
in
the
process.
So
again,
the
question
is:
not.
Are
you
doing
continuous
delivery,
but
compared
to
the
other
in
your
heart,
in
your
space?
A
Are
you
the
best
or
not,
because
what
was
acceptable
10
years
ago?
It's
definitely
not.
Today,
especially
on
the
time
to
market
matrix.
I
saw
one
mentioning
that
we
should
focus
to
deliver
changes
within
15
minutes,
which
is
a
nice
goal
not
achievable
by
every
industries,
but
at
least
we
try
to
to
improve
the
process.
A
Another
major
component
that
we
have
to
clarify
is
what's
the
jenkins
infrastructure
projects,
so
the
jenkins
infrastructure
project
is
a
sub-project
of
jenkins
and
the
way
you
have
to
see
it's,
the
jenkins,
like
any
organization,
rely
on
services,
and
so
we
just
provide
infrastructure.
We
provide
services
and
we
want
to
apply
the
same
approach
than
jenkins.
So
we
are
open
source.
Everything
is
open,
obviously
accepted
credentials.
At
least
we
hope,
but
everything
is
open.
People
can
review.
A
People
can
contribute
change
audit
whatever,
so
we
try
to
be
as
open
as
possible,
so
we
have
some
specificities,
so
the
first
one
that
we
have
to
highlight
are
the
customers.
So
in
the
project
we
have
three
kind
of
customers,
jenkins
users.
So
the
jenkins
users
are
the
people
who
just
use
jenkins
websites
to
have
information.
Let's
say
how
to
install
jenkins,
how
to
use
jenkins.
A
So
we
have
many
different
ways.
There
are
many
different
ways
to
contribute
to
jenkins,
not
only
about
coding,
and
so
we
also
provide
services
and
processes
to
help
them
to
to
improve
jenkins.
And,
finally,
the
third
kind
of
customers
that
we
have
not
jenkins
of
our
projects
are
jenkins
instances
themselves.
So
when
jenkins,
let's
say
want
to
update
a
plugin
want
to
install
a
plugin,
we
provide
the
services
that
tells
you
which
plugin
version
is
available
for
your
specific
jenkins
score,
either
it's
stable
or
weekly
and
many.
A
A
So
usually
the
way
it
works
is
if
someone
is
interested
to
either
help
on
a
specific
service
or
deploy
and
build
a
specific
service
that
would
benefit
the
jenkins
community.
We
usually
provide
the
infrastructure,
the
process,
the
tooling,
so
that
person
could
maintain
that
service,
and
so
we
mainly
rely
on
volunteers,
and
we
have
a
few
full-time
people
who
help
coordinating
the
different
initiatives
and
try
to
be
sure
that
everything
runs
smoothly,
or
at
least
we
try.
A
The
content
that
you
see
on
git
repositories,
but
also
try
to
keep
in
mind
that
those
services
were
designed
with
a
specific
knowledge
available
at
that
time
and
with
a
specific
time.
So
not
everything
should
be
done.
The
same
way
today
so
always
try
to
understand
if
it's
still
the
right
approach
or
not.
And
finally,
as
I
said,
everything
is
available
on
git
repositories.
So
we
rely
on
the
jenkins
infra
organization
on
github,
where
you
can
find
more
than
100
kit
repositories.
A
So
now,
let's,
let's,
let's
look
at
what's
the
framework,
how
we
do
continuous
delivery.
So
in
the
jenkins
project
we
have
a
lot
of
different
kind
of
components:
either:
custom
application
infrastructure
codes
and
and
many
other
kind
of
components,
but
whatever
git
repository,
we
always
have
focus
on
those
five
areas
and
usually
the
way
it
works
is
we
have
make
fine,
we'll
run
make
tests
make
deploying
and
so
on.
So
we
we
have
a
mix
file
as
a
default
interface,
and
so
those
are
five
main
areas.
So
the
first
one
is
test.
A
A
It's
really
important
because,
because
the
the
infrastructure
team
is
composed
of
volunteers,
those
people
are
working
from
different
time
zones,
different
places
on
the
globe,
and
so
it
does
not.
I
mean
the
person
who
merged
and
deployed
change.
It's
not
it's
not
necessarily
the
same
one
who
wrote
the
change,
and
so
we
want
to
be
sure
that
we
can
cast
test.
We
can
catch
as
many
errors
as
as
fast
as
possible.
A
A
We
have
security
policies
in
place
and
we
have
different
areas
that
we
would
like
to
improve.
The
third
area
is
about
continuous
deployment.
That's
really
important
for
the
project
to
be
sure
that
we
don't
rely
on
a
single
contributor
to
deploy
a
change.
So
we
want
to
be
sure
that
we
have
a
process
to
deploy,
change
automatically
securely
and
as
fast
as
possible.
A
A
So
while
we
don't
deploy
specific
components
in
that
at
that
moment,
we
just
want
to
be
sure
if
it's
possible
to
have
logs
correct,
matrix
or
trace
where
we
work
on
a
git
repositories.
So
we
rely
on
different
tools
like
data
dog,
graphena
and
others,
and
so
we
want
to
be
sure
that
when
we
introduce
change
when
we
automate
something,
we
have
ways
to
measure
that
to
know
if
we
are
doing
better
or
worse.
A
So
we
always
try
to
automate
that
full
process
and
for
us
we
really
see
as
automation
as
a
good
way
to
document
the
procedure,
because
in
the
end,
that's
what
what
the
same
system
will
do.
So,
overall,
we
try
to
increase
the
trust,
so
the
first
part
of
the
continuous
delivery
workflow
is
about
looking
at
the
tests,
and
so
here
in
the
test.
As
you
can
see
on
this
slide,
we
have
different
kind
of
components.
We
have
puppet
code,
we
have
hand,
files,
hand,
sorry
hand
codes
so
to
define
communities
application.
A
We
have
push
collin
and
many
other
components.
We
usually
always
start
with
a
linter.
A
linter
is
a
small
tool
specific
to
a
language
language,
and
the
goal
of
an
interval
is
to
catch
basic
errors
as
fast
as
possible.
It's
usually
pretty
it
runs
very
quickly,
and
so
by
default
we
always
try
to
not
identify
what's
the
right
linter.
A
We
would
like
to
be
sure
that
we
have
integration
test,
so
we
started
on
using
teratest
on
the
other
side,
when
we
have
golang
or
bat
bash
script,
we
we
just
focus
on
one
specific
function,
and
so
we
we
we
rely
on
unit
test,
so
it
really
depends
on
the
right
side.
You
have
git
repositories
where
you
can
look
at
the
most
recent
place
where
we,
where
we
work,
was
the
docker,
the
workflow,
to
release
to
build
publishing
test
docker
images.
A
So
it's
a
it's
a
shared
library,
so
you
can
easily
copy
copy
copy
that
that
process
test
will
run
obviously
in
continuous
integration
tool
like
I
like
jenkins,
and
we
have
many
different
jenkins
depending
on
the
team,
relying
so
the
difference.
The
default
one
is
ci,
the
jenkins
that
I
own,
that
you
can,
where
you
can
find
information,
and
we
now
start
to
have
other
jenkins
instances
running
from
the
vpn,
where
we
test
some
specific
components.
A
So
the
goal
of
policies
is
not
to
catch
errors,
but
instead
to
increase
the
clarity,
the
security
and
the
observability
of
the
code
that
we
are
writing
here.
So
we
define
different
conventions
like
when
we
can
we
use
conventional
commits.
We
use
semantic
versioning
as
much
as
possible.
We
define
we
started
using
oci
label
convention
in
our
docker
images
if
we,
if
there
are
other
conventions
that
we
should
follow,
feel
free
to
propose
them
to
suggest
them
and
and
we'll
integrate.
A
But
it's
really
important
that
in
the
convention
that
we
all
talk
about
the
same
thing
so
as
a
basic
example
is
when
you
deploy
resources
on,
let's
say
on
on
azure
or
amazon,
you
can
provide
a
label
and
that
label
could
be
their
production
uproad.
That's
really
important
that
we
use
the
same
label
everywhere.
So
when
we
are
looking
for
specific
information
in
our
observability
tool
like
tata
dog,
then
we
can
retrieve
every
lock
or
matrix
or
information
related
to
a
specific
service.
A
So
the
the
policies
is
really
important
and
once
you
define
the
policy,
so
these
those
policies
are
just
manual
convention,
a
manual
manual
convention,
you
can
use
tools
to
enforce
those
policies.
So,
regarding
security
policies,
we
are
investigating
the
electric
security
provided
by
the
linux
foundation.
A
A
The
next
step
we
usually
after
doing
some
tests,
ensuring
that
the
policies
are
pressing
is
about
what
the
continuous
deployment
look
like
and
the
continuous.
If
the
reason
why
we
want
to
do
continuous
deployment
is
because
we
want
to
be
sure
that
we
don't
rely
on
a
specific
maintenance
machine
to
deploy
something
like
jenkins
release
or
other.
So
we
usually
have
two
main
kind
of
tools,
so
what
I
would
name
generic
tools,
ci
like
jenkins
or
github
action
or
whatever
the
tool
you
want
to
use.
But
in
the
case
of
jenkins,
we
use
jenkins.
A
You
change
something
to
a
git
repository
and
then
jenkins
pick
up
those
changes
and
we'll
apply.
So
typically,
we
have
a
jenkins
file
where
we
run
terraform
or
hem
file,
and
so,
in
the
case
of
terraform,
we
manage
our
datadog
account
or
amazon
account
or
azure
account.
In
the
case
of
communities
we
use
hand
file
the
the
benefit
of
relying
on
jenkins.
Is
it
brings
you,
flexibility?
A
You
can
just
combine
the
different
commands.
The
way
you
want
you
can
run
tests,
you
don't
have
to
maintain
additional
services.
You
don't
need
a
specific
expertise.
You
just
rely
on
the
tool
that
you
already
deployed
anyway
just
be
sure
to
protect
your
credentials
because
then
become
a
nice
target,
but
anyway
that's
a
different
story.
So
either
we
have
generic
tools
or
we
have
what
I
would
name
specialized
tools.
So
specialized
tools
are
tools
that
were
designed
built
just
to
fulfill
one
specific
job.
A
In
the
case
of
puppet,
you
have
the
puppet
master,
you
deploy
the
puppet
master,
and
so
the
puppet
master
will
be
sure
that
your
puppet
agent
have
the
right
codes.
Have
the
right
definition
of
what
the
service
should
looks.
Like
so,
in
this
case,
the
process
is
kind
of
similar.
We
push
changes
to
a
git
repository
and
those
changes
are
propagated
to
the
puppet
master
and
the
puppet
master
run
the
agent.
A
A
We
could
also
see
kubernetes
as
a
specialized
tool
to
deploy,
because
you
define
communities,
resources
and
then
communities
will
be
sure
that
you
have
the
right
amount
of
containers
running
on
the
right
on
the
right
nodes
and
it
can
deploy
like
load,
balancers
services
and
so
on.
So
we
could
also
see
as
communities
kind
of
those
two
locations.
A
A
The
next
major
update
is
about
continuous
updates,
and
I
think
it's
really
interesting,
because
not
every
so.
This
is
something
that
we
started
doing.
I
would
say
one
year
or
two
years
ago
and
we
learned
a
lot
in
that
area
and
it
helped
us
a
lot.
So
the
first
major
benefit
of
doing
continuous
updates
is
about
identifying
changes
in
downstream
dependencies,
so
either
feature
or
bug.
A
We
detect
that
change
open
a
pull
request.
We
try
to
to
provide
a
change
log
if
it's
possible
and
if
it
is
yeah,
that's
how
we
identify
the
improvement.
Another
useful.
The
next
useful
topic
is
about
highlighting
obsolete
dependencies
or
prioritizing
the
task.
So
typically,
what
happens
is
we
have?
We
maintain
a
project,
an
application
using
harm
and
we
have
a
new
major
version.
So
there
is
a
request
that
open
telling
us
that
there
is
a
new
major
version
available,
but
we
have
to
work.
A
We
have
to
follow
the
the
upgrade
procedure,
but
we
don't
have
the
time
to
work
and
that's
at
that
moment
and
then
we
wait
a
little
bit
and
there
is
then
a
second
major
version
arrive
and
the
third
major
major
version
arrive,
and
we
know
that
we
have
two
options
here:
either
we
really
want
to
do
the
upgrade.
So
we
have
to
be
sure
that
in
the
near
future,
we
can
prioritize
correctly
that
task.
So
we
can
take
the
time
that
needed
to
just
catch
up
the
different
version
updates
or
on
the
other
side.
A
If
we
don't
have
the
time
we
haven't
updated
the
service
because
we
don't
use
it.
Maybe
that's
also
the
right
time
to
to
remove
that
service
for
from
our
infrastructure.
So
this
is
the
same.
It
works
in
both
ways.
In
the
case
of
the
jenkins
project,
sometimes
we
remove
services.
Sometimes
we
just
plan
some
work,
so
it
really
helped
us
to
identify
when
some
components
of
our
infrastructure
is
getting
outdated
and
that
we
will
have
to
work
on
that
to
improve
the
situation,
because
we
also
regularly
update
our
infrastructure
using
pull
requests.
A
It
helps
us
to
validate
the
delivery
process.
We
open
a
pr,
we
validate
the
pr,
merge,
the
pr
it
deploy
a
change.
Everything
went
smoothly
so
yeah,
that's
perfect,
you
increase
the
trust,
so
that's
that's
usually
the
way
we
see
it
and
if
we
update
the
service
it
fail,
then
we
also
learn
in
the
process,
because
that
means
that
we
need
more
tests.
So
that's
the
way
it
works.
A
It
brings
system
awareness.
So
this
point
is
also
really
important,
not
necessarily
clear
to
understand
initially,
but
when
some
time
you
have
you
automate
an
application.
The
process
is
very
smooth
working
very,
very
well,
and
you
have
newcomers
to
indulge
to
the
projects
who
work
and
with
you.
They
don't
really
have
to
work
on
that
specific
system,
because
it's
working
everything
is
working
correctly,
but
by
automatically
opening
version
update,
let's
say:
okay,
you
see
that
there
is
a
new
version
for
postgresql.
You
see
that
there
is
a
new
version
for
nginx.
A
It
bring
awareness
on
that
specific
system,
because
people
just
review,
pull
requests,
validate
the
change
and
even
if
they
don't
have
to
contribute
to
that
specific
service,
they
still
build
some
knowledge
and
they
understand
how
the
service
is
behaving
because
because
of
the
different
components
we
have,
my
one
major
downside
of
the
continuous
update
process
is
that
it
introduces
a
lot
of
noise,
can
bring
stress
as
well.
We
try
to
run
let's
say,
to
update
the
system
several
times
a
day.
A
The
last
topic,
which
is
at
the
same
time
very
important
to
me,
but
also
we
don't
spend
a
lot
of
time
here,
is
about
observability.
So
when
we
work
on
a
git
repository,
we
want
to
be
sure
that
we
have
ways
to
measure
if
the
change
that
we
are
doing
is
goods
or
bytes.
So
usually
it
works
by
defining
convention,
but
we
also
want
to
be
sure
that
we
have
labels
or
tags
depending
on
the
resource.
A
There
are
different
names
to
that,
but
we
want
to
be
sure
that
later,
when
we
need
to
find
information,
we'll
know
what,
where
to
look
for
that
specific
information.
So
again,
for
instance,
we
rely
on
the
tadag.
We
don't
have
to
maintain
that
the
service,
but
we
we
need
to
be
sure
that
we
feed
it
with
the
right
information.
A
So
that's
why
I
like
to
keep
it
in
mind
here.
So
this
is
what
the
process
look
like
for
every
git
repositories.
So
again,
not
every
git
repo
that
we
maintain
have
the
same
level
of
quality.
So
if
you
look
at
one
of
them
find
some
hole
feel
free
to
report
them
either
to
me
or
another
changing
infrastructure,
maintainer
and
we'll
try
to
do.
But
in
the
end,
we
also
rely
on
on
people
to
help
us
maintain
jenkins
infrastructure
projects.
A
The
the
final
part
of
my
presentation
is
about
update
cli,
so
update
like
that
is
a
tool
that
we
built
to
help
us
maintain
the
update
our
infrastructure.
So
on
the
project
we
rely
on
dependable,
because
it's
working
very
well
in
github
but
depend
debug
is
an
as
kind
of
a
generic
workflow
will
identify.
A
Docker
file
are
very
well
find,
but
it's
really
difficult
when
you
have
custom
yaml
file,
for
instance,
or
dockerfile,
with
a
custom
syntax,
and
so
I
wanted
a
way
to
to
update
those
and
to
define
strategies
to
update
those
files,
and
so
that's
that's
how
I
started
working
on
update
cli.
So
I'm
going
to
to
show
you
two
different
demo.
The
first
one
is
how
it
works.
So
update,
cli,
as
you
can
understand,
is
a
small
cli,
where
you
specify
an
update,
an
update
strategy.
Fine.
So
in
this
case.
A
Let
me
show
you:
I
was
not
on
the
demo.
Sorry,
so
let
me
restart
this
demo,
so
update
cli
is
a
small
cli,
so
you
use
it
to
so
in
combination
with
update
strategies
and
updates,
we
ensure
that
your
you
will
find
your
docker
file.
Your
hem
charts
are
up
to
date,
so
in
this
case
I'm
on
the
jenkins
infra
jenkins,
dashing
from
github
organization,
on
the
git
repository
jenkins,
infra
and
inside
you
have
a
directory
name
updatelight.
A
So
that's
where
we
regroup,
update
cli
configuration,
and
so
I'm
going
just
to
give
you
an
overview
of
what
it
looks
like
config
update,
cli.
Let's
take
jenkins
s,
we
can
specify
some
values,
so
values
are
just
parameters
that
will
be
injected
in
the
code
templates
and
if-
and
so,
if
I
run
here,
update
cli
will
download,
we
will
check
out
the
git
repository
into
a
temporary
location
and
then
run
a
bunch
of
operations.
So
the
first
one
is
it's
search
for
an
information
what's
the
source.
A
So
in
this
case
we
are
looking
for
the
latest
jenkins
lt's
version,
which
is
this
one.
As
of
today,
we
get
the
change
log,
which
is
here.
We
are
fetching
that
information
from
github
releases.
We
run
to
run
basic
condition.
So
in
this
case,
what
we
want
to
do
is
we
want
to
be
sure
that
the
puppet
codes
as
a
directory
error
data
and
inside
command.tml
file-
and
we
want
to
be
sure
that
the
command
the
tml
file
as
a
key
profile,
the
current
current
current
build
master
column,
current
docker
image
set
to
jenkins.
A
So
we
just
want
to
be
sure
that
we
are
using
the
correct,
docker
image
name
and
finally,
the
target
will
update
that
key
docker
docker
tag
so
profile
profile,
current
column,
build
master,
docker
tag,
and
so
in
this
case
it
it
see
that
we
are
running
the
previous
version.
So
we
can,
we
can
update.
So
this
run
was
just
a
dry
run,
so
I
haven't
changed
anything,
and
so
it
allows
that
attention.
We
have
to
update
the
update
cni.
A
A
So
how
updatey
is
working
before
showing
you
what
a
template
looks
like?
We
just
have
to
understand
the
big
pictures,
so
we
just
want
to
know
what
we
want
to
change
where,
where
that
information
is
located,
let's
say
on
the
docker
file
file,
yaml
hem
shot.
We
can
apply
a
bunch
of
conditions
like
do
we
do
do
we
have
a
specific
git
tag
available.
Do
we
have
a
specific
heat
release?
A
So
if
the
condition
is
not
passing,
we
stop
here
and
finally
the
what
where
what
what
the
what
source
we
want,
what
information
we
are
looking
for,
and
so
when
we
run
update
cli
it
worked
the
opposite.
It
first
search
for
the
source
information
inject
that
value
into
the
condition
in
the.
If
the
condition
is
passing
it
inject
that
into
the
targets
that
that's
the
big
picture.
A
A
A
A
We
could
also
test
that
the
the
docker
image
with
that
specific
version
exists
on
on
undocker
on
the
github
and
finally,
if
the
condition
are
passing,
we
update
the
target.
So
the
target
in
this
case
is
a
yaml
file
and
we
specify
the
file
the
key
and
the
value
is
injected
based
on
the
source,
and
we
then
update
the
git
repository
using
the
pull
request.
So
we
open
up,
we
commit
the
change,
we
push
a
change,
we
open
up
a
request,
someone
validate
and
we
continue
and
we
move
forward.
A
A
That's
pretty
fast,
and
so
because
it's
a
cli,
it
integrates
very
well
in
jenkins
or
your
ci
environments.
So
we
just
run
this
command
once
a
day
twice
a
day
depending
and
so
in
this
case
we
see
that
it
retrieved
the
latest
weekly
version
as
of
today
vegeta
for
change
log
and
then
we'll
update,
because
we
are
changing
from
a
stable
version
to
a
weekly
version.
A
A
A
A
A
A
A
Yes,
so
the
area
to
contribute
really
depends
on
your
interest.
We
have
communities
we
would
like.
I
definitely
would
like
to
automate
more
around
policies.
So,
as
I
mentioned
in
my
presentation,
so
we
have
we
have
kubernetes
cluster,
so
we
can
easily
deploy
application
there.
So
it's
on
jenkins
and
for
us
charts
that
would
be
an
area
where
we
can
improve.
A
So
the
the
challenge
is
the
context
said
switching
context
all
the
time,
because
we
have
a
lot
of
contributors
who
contribute
out
to
a
specific
area.
They
are
around
for
several
years
and
then
for
some
reason
they
are
not
available
anymore,
and
so
you
need
to
either
build
knowledge
on
that
specific
undo,
specific
application
or
identify
contributors
interested
to
improve.
So
a
typical
example
is
the
plugin
site.
A
A
So
the
second
question
is:
what
would
you
lose
by
standardizing
on
specific
tool?
That
question
is,
I
think,
quite
easy.
So
people
contribute
to
the
jenkins
infrastructure
project
because
they
want
to
learn
on
a
specific
topic,
and
so
obviously,
when
you
have,
I
would
say,
a
hot
topic
in
your
infrastructure:
it's
easier
to
identify
contributors
because
they
want
to
practice.
They
want
to
learn
at
the
same
times.
You
sometimes
have
application,
which
are
really
stable
using
two
things
very
stable,
but
people
don't
don't
want
to
contribute
to
those
anymore.
A
So,
for
instance,
we
have
we
use
puppets.
We
use
puppet
in
our
infrastructure,
it's
working
great,
I
mean
it
has.
It
has
downside
too,
but
it's
working
great
and
we
have
less
people
at
the
moment
interested
to
contribute
to
work
on
that
specific
area,
but
it
really
depends.
Usually
it's
usually
like
one
contributor-
is
interested
by
specific
area,
pick
up
tasks
and
just
build
this
knowledge
on
that
on
that
area.
A
That
question
is
okay,
so
the
jenkins
infrastructure
projects
rely
on
charlie
on
sponsoring,
so
we
don't
have
budget.
We
don't
I
mean
the
jenkins
project
is
yeah.
Everything
is
based
on
sponsoring,
so
we
have
azure.
We
have
amazon,
we
have
rack
of
space,
we
have
infrastructure
running
on
suse,
I
mean
we
have
quite
a
lot
of
infrastructure.
The
challenge
is
sometimes
sponsor.
A
Stop
sponsoring
stop,
and
then
we
have
to
find
someone
else
to
pay
either
the
bill
or
or
just
to
find
another
sponsor,
and
when
we
have
another
sponsor,
we
have
to
move
the
part
of
the
infrastructure
to
a
different
location.
That's
how
it
works,
because
yeah
finding
someone
to
pay
the
bill
can
be
difficult
and
just
to
gives
you
an
idea.
A
The
budget
for
tutorial
for
2020
was
around
two
thousand
dollars,
and
that's
only
for
the
part
that
we
can
estimate,
because
many
sponsors
don't
even
give
us
access
to
the
to
the
billing.
So
we
have
a
meticulous
strategy
because
we
don't
really
have
the
choice
and
and
that
that's
right.
Sometimes
it's
frustrating,
because
we
have
to
make
create
application
that
we're
working
very
well
on
a
specific
cloud
vendor.
But
just
because
we
don't
have
the
money
to
run
there.