►
Description
Katharina Sick and Martin Singer from Dynatrace will show how they provision Jenkins instances on Demand with Kubernetes and Configuration as Code.
When developing a project, there are many things to consider. It's not just about the code itself, but also about building, testing and packaging everything. Making this process easier is the main goal for the Engineering Productivity teams at Dynatrace.
Join us in this talk to learn about how we are utilizing Jenkins to ease the process of building and delivering applications for hundreds of developers. You'll see how our Jenkins instances are running in a Kubernetes cluster, how they are provisioned via Configuration as Code with minimal overhead and which tools are used to get the most out of our workflow. Additionally, we'll add a live demo to show how all of these components can work together.
Speakers:
- Katharina Sick, Software Engineer at Dynatrace. Full stack software engineer at Dynatrace. Advanced from mobile to backend development and now putting more focus on full stack solutions as well as CI and CD environments.
- Martin Singer, Software Engineer at Dynatrace. Working on CI/CD topics since starting as a full time software engineer. Always eager to learn about new ways to automate processes.
A
And
we
are
live
so
just
in
case
I
will
start
recording
on
a
website,
okay,
and
we
are
good
to
go
so
thanks.
Everyone
for
joining
the
junkies
online
meetup,
as
you
might
have
noticed,
we
are
trying
out
the
new
platform
today.
So
instead
of
using
zoom
and
meetup.com
as
usual,
we
are
trying
out
community
cdf
resource,
it's
a
new
site
that
will
be
rolled
out
within
the
next
month
and
we
have
a
online
broadcast
on
youtube,
and
most
of
you
are
watching
us
on
youtube.
A
So
for
this
presentation
and
for
this
meetup
how
we
will
organize
so
first
we
will
have
a
presentation
by
catharina
and
martin.
They
will
do
all
the
presentation
demo.
If
you
want
to
ask
any
questions,
please
use
the
chat
in
youtube
and
I
will
be
collecting
these
questions
asking
during
the
presentation
or
afterwards,
and
then
we
will
have
some
time
for
open
corny.
After
the
end
of
the
presentation,
as
I
said,
we
have
a
back
end
on
baby.
A
B
Okay
then
hi
and
welcome
to
our
talk,
kickstarting
ci,
best
practices
with
jenkins
and
autonomous
teams.
My
name
is
martin
singer
and
today
I'm
joined
by
kardarinasik.
We
are
both
software
engineers
at
dynatrace
and
work
in
engineering
productivity
in
engineering
productivity.
We
focus
mainly
on
internal
tooling,
as
well
as
cinct
topics.
B
First,
let's
have
a
look
at
the
agenda
of
today's
talk.
We
want
to
start
with
the
current
state
of
jenkins
usage
at
dynamtrace.
Then
we
want
to
talk
about
the
build
environment
and
all
its
components
that
are
used.
We
want.
We
also
want
to
talk
about
how
we
deploy
and
test
our
instances
and
how
we
do
the
maintenance
of
them.
There
will
also
be
a
live
demo
and
at
the
end,
they
will
then
outlook
what
is
planned
in
the
future.
B
B
B
First
of
all,
the
sd
champion's
configures
code
instance.
This
is
just
a
kubernetes
spot
and
with
that
comes
also
a
dedicated
vault
engine
vault.
Is
our
secret
store
we'll
talk
about
that
later,
so
there's
also
the
kubernetes
namespace
for
spoiling
the
executors,
and
we
also
create
the
automatically
generated
dynamics
dashboard
with
all
the
relevant
metrics.
B
B
B
The
main
benefits
for
us
with
jenkins
configures
code
are
the
audit
log
the
for
ice
principle,
so
each
change
has
to
be
reviewed
and
approved
by
another
dev
and
also
the
easy
maintenance
for
the
ease
of
maintenance.
We
also
have
another
big
component
there.
The
project
initializer,
which
I'll
talk
about
later.
B
Then
there
is
humanities,
we
use
kubernetes
to
host
all
of
our
changes,
gasket
stances
as
well
as
all
of
our
jenkins
workers.
The
clusters
are
hosted
in
aws
and
on-prem
for
our
on-prem
clusters.
We
also
have
the
option
to
do
cloud
bursting
there.
So
if
the
load
is
high,
we
don't
want
to
stall
the
pipelines.
We
will
just
provision
additional
resources
from
aws.
B
B
It
allows
us
to
give
role-based
access
control
for
secret
engines
and
also
to
grant
secret
access
for
builds
via
an
api.
This
is
a
great
benefit
from
vault.
We
used
secret
server
before
and
with
secret
server.
We
had
the
problem
that
there
wasn't
any
api,
so
we
always
had
to
double
create
secrets,
which
means
we
would
first
create
them
in
secret
server
and
afterwards
always
create
them
in
jenkins
as
well.
B
B
Then,
let's
talk
about
the
star
of
our
show
the
project
initializer.
The
project
initializer
aims
to
make
the
bootstrapping
of
new
projects
as
easy
as
possible
to
achieve
that,
it
allows
users
to
generate
new
projects
from
templates.
It
is
a
self-developed
service
and,
as
already
said,
you
are
able
to
bootstrap
new
projects
from
templates.
B
Devs
are
also
able
to
just
create
new
templates
themselves.
If
you
think
about
the
template,
just
think
about
the
plain
bitbucket
repository
with
some
placeholders
in
it,
and
also
one
central
configuration
file
in
this
configuration
file,
you
are
just
able
to
define
beatback
repository
settings
jenkins
web
hooks.
B
That's
not
the
only
cool
feature
of
the
initializer.
One
of
the
key
features
is
also
to
keep
the
projects
at
the
newest
state.
So
once
any
projects
are
created
out
of
a
template,
they
will
automatically
get
updates.
When
one
of
the
template
file
changes,
we
will
do.
We
do
so
with
automated
pull
requests
open
the
bit
bucket.
B
B
B
B
B
As
a
fourth
step,
we
want
to
create
the
jenkins
jobs
to
test
and
deploy
the
instance
once
the
instance
is
deployed,
we
will
verify
that
everything
works
as
expected
and
hand
the
instance
over
to
our
devs.
We
will,
of
course,
also
provide
some
onboardings
for
our
new
check
supplements
to
scale
better
there.
We
have
pre-recorded
some
onboarding
missions
and
there's
also
the
option
to
do
a
q,
a
session.
B
B
Then
there
is
vault
configuration
and
the
secret
injection,
so
this
is
the
part
where
we
apply
our
world
configures
code
to
config
files.
As
already
said,
devs
can
create
their
own
secret
engines
or
grant
permissions
to
them
via
config
files.
All
of
that
is
implemented
with
terraform
and
yeah.
As
a
second
step.
We
also
do
the
secret
injection
there
so
secrets
that
are
needed
for
hid,
usage
or
male
server.
Current
fix
are
getting
dynamically
injected
to
our
humanities.
Namespaces
of
the
instance.
B
B
If
that's
all
checked
we'll
downscale
the
production
instance
and
we'll
set
the
new
dock
image,
as
well
as
the
human
use
configmap,
then
we'll
update
the
new
upscale,
the
newly
updated
instance
again
and
test
if
everything
works
on
our
production
instance.
So
of
course,
this
is
already
also
automated
again.
This
whole
process
of
testing
on
the
production
instance,
and
now
it
is
very
unlikely
that
something
fails
there,
because
we
already
did
the
whole
testing
on
our
test
instance.
But
if
that
would
be
the
case,
we
have
an
automated
rollback
in
place.
B
B
As
the
last
steps,
we
will
create
and
update
the
dashboards
and
do
some
cleanup
as
well.
So
first
we
automatically
create
the
dedicated
data
trace
dashboard
with
the
instance
matrix.
I
have
already
shown
you
that
dashboard
before
we
will
also
create
a
newly
created
instance.
We
will
also
add
the
newly
created
instance,
of
course,
to
our
overview
dashboard.
A
B
A
C
Okay,
so
thanks
a
lot
also
hello
from
my
side
and
martin
was
just
talking
about
how
we
are
deploying
our
jenkins
instances,
and
I
would
like
to
continue
a
little
bit
about
when
we
are
deploying
them.
So,
first
of
all,
we
are
doing
a
weekly
redeployment
of
our
jenkins
instance
each
week
on
sunday
night
and
the
reason
for
that,
or
the
main
reason
for
that
is
that
we
always
want
to
stay
up
to
date
with
the
newest
lts
version
of
the
jenkins
space
image
we
are
using
in
our
deployment
and
further.
C
We
also
want
to
keep
plugins
and
stuff
like
that
on
the
newest
state,
so
that
we
always
get
the
latest
security
fixes
in
and
are
on
the
safe
side.
With
this
one
further
we
are
considering
the
configuration
is
code
repository
on
git
as
our
single
source
of
truth
for
all
jenkins
instances,
and
therefore
we
are
making
sure
to
do
at
least
once
a
week,
a
sync
with
the
configuration
is
code
and
the
ui
somebody
may
have
configured
which
shouldn't
have
been
done
and
therefore
we
are
just
syncing
them
each
week.
C
Of
course,
if
you
are
deploying
a
feature,
it
may
be
quite
cumbersome
if
you
need
to
wait
until
next
monday
to
get
your
changes
applied,
and
that
is
why
we
have
second
job
running,
which
is
doing
an
automatic
redeployment
during
the
night
if
there
have
been
changes
to
an
instance
during
the
day.
Of
course,
this
is
not
redeploying
all
instances,
but
just
the
one
that
had
changes
or
the
few
ones
that
had
changes
in
that
case,
in
some
cases
that
may
also
last
too
long
to
get
all
your
changes
in.
C
So
we
also
allow
jenkins
instance
admins
to
manually
trigger
a
redeploy
for
jenkins
instance,
but
we
are
not
doing
immediate
redeploys
automatically,
because,
unfortunately,
we
are
not
able
to
redeploy
jenkins
without
a
few
minutes
of
downtime,
and
we
don't
want
to
stop
the
productivity
of
our
engineers
during
the
day
by
redeploying
the
jenkins
instance.
If
it's
not
really
necessary,
you
can
see
that
we
already
put
quite
a
lot
of
work
into
this
or
quite
a
lot
of
thoughts
into
this
workflow.
C
So
this
means
you
can
simply
merge
your
new
job
definitions,
and
then
you
run
this
job
and
you're
done,
and
you
can
already
work
with
your
jobs
before
developing
new
features.
You
may
also
want
to
test
them,
of
course,
and
that's
why
we
spawn
a
test
instance
for
each
branch
that
is
made
in
a
configuration
as
coding
instance.
C
What
you
can
do
in
this
test
instance,
is:
you
can
click
around
there?
You
can
view
the
configuration
you
can
even
run
the
seed
chip
to
see
if
your
jobs
are
loaded
correctly.
The
only
things
you
cannot
do
is
you
cannot
run
builds
because
we
don't
want
any
bills
to
be
run
on
test
instances.
We
all
want
them
on
the
production
instances
and
therefore,
also
no
kubernetes
cloud.
Definitions
are
available
on
our
test
instances.
C
But
we
don't
want
to
force
them
to
work
in
a
special
way
which
has
giving
them
some
defaults
and
some
training
in
the
beginning,
but
then
it's
up
to
them
how
they
want
to
use
their
jenkins
instance
to
educate
these
people.
We
also
created
a
new
community,
different
diner
trace.
It
is
called
the
build
guild
and
each
month
we
are
offering
some
sessions
and
workshops
about
ci
and
cd
related
topics
to
interested
people.
C
They
don't
have
to
be
jenkins
admins,
but
lots
of
them
are,
of
course,
in
the
build
guild
as
well
and
within
the
build
guild.
We
don't
only
want
to
educate
people,
but
we
also
want
to
people.
We
want
to
enable
people
to
learn
from
each
other,
and
also
we
want
to
learn
from
people.
We
want
to
hear
their
experiences,
what
problems
they
have
and
so
on.
C
Further,
we
are
always
trying
to
keep
the
questions.
People
have
very
well
documented,
so
we
are
encouraging
people
to
ask
the
monster
overflow
enterprise,
which
is
our
internal
stack
overflow
instance,
and
we
are
being
very
active
there
as
a
team.
So
we
are
watching
the
tags
that
affect
our
team
and
usually
within
a
few
minutes
or
hours,
people
get
answers
from
a
subject
matter
expert
if
they
have
questions
about
jenkins
or
related
topic,
and
the
other
nice
thing
about
this.
C
Further,
there
may
be
some
changes
that
are
not
made
by
the
jenkins
instance
admins,
but
by
us
as
a
team.
These
changes
are
usually
some
changes.
We
always
want
to
roll
up
to
all
jenkins
instances.
For
example,
the
seed
chip
we
mentioned
earlier
is
something
like
that.
We
just
implemented
it
a
few
weeks
ago
tested
it
on
our
own
jenkins
and
then
once
we
verified
everything
is
working
in
production.
We
wanted
to
roll
it
out
to
all
instances,
and
this
is
something
we're
doing
by
the
project
initializer.
C
So
all
our
jenkins
instances
have
either
been
created
from
a
template
there
or
have
at
least
later
been
linked
to
it
if
they
have
been
if
they
have
exit
existed
before
the
project
initializer
and
now
the
initializer
knows
about
all
our
37
configuration
is
code
instances
and
when
a
new
commit
to
the
template
is
made,
it
says,
hey
look,
I
got
37
childs.
I
will
update
them
as
well
and
instead
of
manually
cloning,
each
file
creating
a
new
branch,
changing
the
files
creating
a
pull
request.
C
The
initializer
will
do
all
that
for
us
and
the
whole
work
that
is
left
is
simply
merging.
This
pull
request
or
maybe
adjusting
it.
If
a
team
has
a
special
configuration
and
of
course,
as
martin
already
mentioned,
we
also
have
the
option
to
ignore
full
repositories
or
files
if
somebody
doesn't
want
to
have
automated
updates.
But
this
is
something
we
ask
people
to
always
think
with
us,
because
we
don't
want
them
to
run
into
some
problems
that
are
not
necessary.
C
Once
the
jenkins
instance
is
running,
it
is
configured
properly.
We
are
doing
some
alerting
and
build
analysis.
So,
first
of
all,
we
have
automated
alerting
setup
via
dyno
trace.
So
martin
showed
you
the
dashboard
earlier
and
by
this
http
monitor,
we
have
automated
alerting
as
well.
This
means,
if
a
jenkins
instance
feels
unhealthy.
C
We
immediately
get
a
select
message
and
can
react
to
it
further.
We
are
using
the
statistics
gatherer
plugin,
on
each
and
terry
jenkins
instance,
and
with
this
plugin
each
instance
is
reporting
its
build
and
test
results
to
our
pipeline
services
tool.
This
is
an
internal
tool.
We
are
using
to
collect,
aggregate
and
store
data
and
we're
having
a
few
features
that
help
us
work
efficiently
on
this
tool.
C
One
of
these
features
is
the
automatic
issue
generation.
This
means
once
a
build
fails.
We
immediately
generate
a
new
gyro
ticket
and,
if
needed
or
I've,
configured
a
select
notification
about
it
and
the
developer
will
be
immediately
informed
about
it,
because
the
ticket
has
been
created
if
the
same
build
fails
again
for
the
same
reason,
we
of
course
not
generating
the
same
issue
again
because
it's
not
our
goal
to
annoy
people,
we
just
want
to
inform
them
and
to
let
them
fix
the
bug
as
soon
as
possible.
C
Further,
as
you
can
see
on
the
top
right,
we
have
some
test
dashboards
in
there
in
the
test
dashboard.
You
can
filter
for
classes,
configurations,
branches
and
a
few
more
options,
and
you
can
see
the
test,
executions
and
statistics
about
them
for
the
last
two
weeks,
as
you
can
see
on
the
top
right
for
this
specific
test
class,
everything
has
been
green.
Everything
has
been
good.
C
C
We
are
also
showing
the
most
common
errors
in
a
test
class.
So
if
you
open
it,
you
will
see
that
this
and
that
exception
has
been
thrown
10
times
and
maybe
five
times
the
build
failed,
because
pod
couldn't
start
or
something
like
that,
and
it
makes
it
very
easy
to
analyze
things
like
that
on
the
bottom
right,
you
see
our
pipeline
cockpit.
This
pipeline
cockpit,
is
always
showing
the
state
of
our
five
most
important
pipelines
in
the
company.
C
Just
at
one
glance
you
can
see
if
everything
is
going
well
or
if
maybe
a
pipeline
has
a
problem
like
gets
in
the
case
in
this
big
picture.
If
a
pipeline
has
a
problem
or
if
a
build
has
failed,
you
will
see
it
here
immediately.
You
will
have
a
link
to
the
build,
but
also
to
the
issue
we
generated
so
check.
C
If
somebody
is
already
working
on
that,
we
have
some
more
features
within
that
that
we
found
within
our
pipeline
services,
but
I
think
it
would
explode
the
scope
of
this
presentation
to
show
them
all,
but
just
to
name
a
few
of
them.
It
is
flaky
test
detection.
We
have
some
build
duration
statistics,
we
have
information
about
configurations
and
so
on
yeah.
I
think
we
have
talked
a
lot
now.
Let
me
show
you
a
quick
live
demo
about
how
all
of
these
components
come
together
and
can
work
together.
C
C
So,
let's
quickly
change
to
the
jenkins
build.
So
we
have.
This
is
one
of
our
changing
instances.
It
is
the
innovation
day
jenkins
and
that's
the
instance.
We
are
using
for
new
projects
for
kind
of
test
projects
where
we
want
to
try
out
something
and
so
on,
and
you
can
see
I
already
created
a
folder
in
here,
which
is
called
jenkins,
meetup
demo.
It
doesn't
feel
too
healthy.
You
will
see
why
in
a
second
and
let's
just
open
that
one
here,
we
have
one
multi-branch
pipeline
in
here.
C
C
C
We
can
select
the
base
image,
the
one
that
I
just
showed
you
is
prefilled,
but
we
will
use
the
jdk.
Oh
it
doesn't
matter
jdk
7
latest
as
a
base
image
here.
I
also
opened
this
one
already
and
in
the
docker
image
you
can
see
in
the
docker
file,
you
can
see
that
there's
not
much
done.
It
is
using
the
same
base
images
as
I
showed
you
before,
and
then
it
is
installing
java
17
and
setting
the
end
variable
java,
home
17..
C
So
let's
use
this
one
as
a
base
image.
Now
we
have
to
choose
a
hardware
project
we
have
to
create
it
in.
This
will
be
ep
in
our
case,
because
that's
the
engineering
productivity
harbor
project
and
we
will
have
to
choose
a
image
name.
I
will
go
ahead
with
jenkins
meetup
executor
image
here
night
gets
a
little
bit
more
interesting.
C
We
have
to
provide
a
hoverboard
path
because
we
will
need
to
push
that
image
somewhere
and
where
we
need
to
push
it
is
to
hover
and
therefore
we
need
we
had
to
create
a
robot
account
for
that
one.
I
already
did
that
beforehand
to
not
bore
you
with
anything
like
that
and
simply
stored
it
in
our
vault
instance.
C
C
So
let's
copy
this
path,
go
back
to
the
initializer,
remove
this
show
thingy,
and
it
should
be
good.
Lastly,
we
need
to
need
jenkins.
We
need
to
add
the
jenkins
url,
where,
where
the
image
will
be
built
to
make
sure
that
the
web
book
is
configured
correctly,
so
let's
copy
the
innovation
dating
in
cll
and
build
here
and
click
next,
we
could
configure
some
default
reviewers
for
the
repository
to
create
now,
but
we
don't
need
them
for
the
demo.
C
So
I
will
simply
skip
this,
and
now
we
can
either
choose
to
download
the
project.
As
a
zip
archive
or
we
can
create
a
new
bitbucket
repository-
and
this
is
exactly
what
we
are
going
to
do
now-
let's
copy
the
image
name
from
over
here
and
paste
it
as
a
repository
name
as
well
and
with
the
ticket
number.
I
will
simply
enter
no
issue,
because
I
don't
have
a
issue
for
this
demo
now
when
clicking
create
repository.
A
C
Okay,
thanks
a
lot
now,
you
can
see
that
the
repository
hasn't
been
created
immediately,
but
the
creation
has
been
requested.
This
means
a
pull
request
has
been
created
which
is
linked
down
here
and
when
we
click
on
it,
we
can
see
that
that
somebody,
in
this
case
it
is
me,
is
requesting
an
approval.
C
When
we
check
the
diff,
we
can
see
that
I
want
to
create
a
new,
a
new
repository
from
the
jenkins
execute
the
docker
image
template
and
I
entered
this
placeholders
we
just
discussed
together
further.
You
can
see
that
I
want
to
create
my
project
in
the
bitbucket
project
jci,
and
I
want
to
call
it
jenkins,
meetup
executor
image.
My
ticket
number
is
no
issue
and
I
haven't
set
any
reviews.
C
Luckily
I'm
an
admin
for
this
jci
project,
so
I
can
just
go
ahead
and
approve
this
pull
request
myself.
Usually,
of
course
it
doesn't
work
like
that,
and
I
can
now
merge
it
and
as
soon
as
I
merge
it,
the
initializer
will
be
informed
about
it
and
will
create
this
repository.
So,
let's
head
over
to
bitbucket,
slash
project
jci
repositories
and
enter
the
reaper
name
again.
C
Yes,
so
here
you
can
see
the
newly
created
repository
and
what
we
have
in
here
is
a
very
simple
readme
that
should
be
extended
if
you're,
using
this
introduction,
of
course,
but
we
don't
care
about
that.
For
now,
we
have
a
jenkins
file,
a
docker
file,
a
initialize
ignore
file
where
we
can
ignore
the
updates
of
certain
files.
In
this
case
it
is
the
docker
file,
because
once
we
adjusted
it,
we
don't
want
it
to
be
overwritten
anymore
and
some
git
ignore
and
ci
folder.
C
Get
it
to
the
current
screen
and
now
I'm
opening
the
jenkins
file.
We
have
here
increasing
the
font
size
a
little
bit
and
you
can
see
that
this
file
was
automatically
generated.
We're
adding
this
header
to
lots
of
files
to
just
make
people
aware
that
we
are
using
the
project
initializer
down
here.
You
can
see
that
we
are
already
having
a
build
for
publishing
the
docker
image
in
place.
We
are
using
the
world
secret,
we
just
defined
here
and
we
are
tagging
and
pushing
the
image
down
here.
C
C
That's
it
already.
Let's
commit
this
with
like.
Let's
see,
adjust
background
image
and
probably
the
push
will
fail
in
a
second,
as
you
will
see
now
it
was
rejected
and
the
reason
for
this
is
that
the
initializer
does
some
repository
settings
on
default.
So
if
we
go
to
bitbucket
and
check
the
settings,
you
will
see
that
we
have
some
branch
permissions
set
up
here,
so
that
no
body
can
push
main
and
release
branches.
C
We
also
have
some
merge
strategies
and
merge
checks,
configured
and
this
all
can
be
configured
in
the
template.
How
the
repositories
that
are
created
should
look
like:
let's
go
back
to
the
branch
permissions
and
do
something
we
are
never
doing
in
production,
but
will
be
okay
for
the
demo.
Now
I
will
simply
add
myself
and
allow
myself
to
push
to
the
main
branch.
Now,
let's
also
go
to
the
repository
permissions,
because,
as
martin
said
previously,
each
jenkins
instance
has
a
dedicated
git
user.
C
C
So,
let's
go
back
to
our
jenkins
meetup,
execute
the
image,
try
to
push
it
again,
and
now
it
should
yeah.
Now
it
worked,
and
now
we
somehow
need
to
get
a
build
for
that
one.
I
showed
you
before.
We
have
this
folder
for
the
jenkins
meetup
demo
today
and
there's
the
demo
built
in
here,
and
I
also
created
pull
requests
to
the.
C
Martin,
luckily
already
merged
it
before
so
I
approved
it
before,
so
I
can
now
go
ahead
and
merge
it,
and
as
soon
as
this
is
done,
I
can
go
back
to
the
innovation
day.
Jenkins
click
on
the
seat,
job
which
reloads
our
job
definitions,
simply
need
to
build
it,
and
within
a
few
seconds
the
build
will
start
and
it
will
reload.
Our
job
definition
should
be
rather
fast.
Actually,
let's
watch
it.
C
C
In
the
meantime,
we
can
already
go
back
to
our
initial
repository,
which
was
the
demo
build
where
I
showed
you
the
jenkins
file,
where
we
are
just
doing
this
verify
java
home
thingy,
and
what
we
will
do
here
is.
We
will
change
the
pot
definition
of
the
custom
agent
because
we
don't
want
to
use
this
base
image
anymore,
but
we
want
to
use
this
newly
created
image
we
have
so
let.
B
A
A
C
C
Let's
push
this
and
trigger
the
other
build
again
I
showed
you
and
now
hopefully
everything
should
be
green
and
yeah.
That's
how
we
are
utilizing
our
tools
to
work
as
efficiently
as
possible.
We
can
with
jenkins
yeah
the
build
has
been
scheduled
and
once
it
is
here,
it
should
be
rather
fast
to
complete,
because
it's
there's
not
much.
It
does.
C
We
always
want
to
improve
the
way
we
are
working
with
our
tools
and
how
developers
can
utilize
our
tools
and
we
always
want
them
to
be
able
to
work
even
more
productive
and
that's
why
we
have
some
outlook
here
with
two
steps
we
have
from
the
very
near
road
map
and
the
first
one
is:
we
want
to
improve
the
deployment
of
our
jenkins
instances
by
utilizing
argo,
cd
and
crossplane.
This
is
something
we
are
currently
already
working
on,
so
it
will
be
done
very
soon
and
then
this
will
enable
us
to
automate
even
more
things.
C
A
Thanks
a
lot
for
the
presentation
and
demo:
yes,
we
got
quite
a
lot
of
questions
so
I'll
start
from
the
top.
So
one
of
the
questions
is
about
architecture.
So
spicen
says
that
he
gets
his
project.
Initializer
is
doing
all
junk
is
controller
setup
for
you,
and
did
you
also
consider
jk
separator
or
the
solutions
available
in
the
jinx
community.
B
Okay,
I
will
take
this
one,
so
sadly,
none
of
us
two
were
at
the
research
for
the
initial
approach,
but
we
already
created
the
first
template
like
about
two
years
ago.
So
it's
quite
quite
a
long
time
ago,
and
I
had
a
look
at
the
jenkins
operator
when
doing
the
meet
the
preparation
already
heard
about
it
before
as
well,
and
it
looks
really
cool
but
yeah.
We
now
have
our
own
setup
with
the
project
initializer,
but
it's
a
very
cool
project.
C
And
one
thing
to
add
here:
we
are
not
only
using
the
project
initializer
for
templates
for
jenkins,
but
also
for
lots
of
other
things
in
the
company
like
microservices
and
stuff,
and
we
want
to
give
our
developers
a
very
uniform
tool
they
can
just
go
to
when
they
want
to
create
a
new
project
and
then
see
what
are
my
possibilities.
Or
can
I
maybe
request
or
add
a
new
template.
A
C
A
A
A
C
Thanks
for
that
hint,
we
are
also
aware
of
that,
and
we
already
have
a
team
in
the
company
taking
a
look
at
that,
and
we
are
also
thinking
about
possibilities
how
to
use
these
two
together.
Maybe
so
it's
yeah,
nothing
of
our
work
is
set
in
stone.
We
are
always
trying
to
improve
our
workflow
and
also
use
the
newest
tools.
Of
course,.
A
B
A
B
A
B
Yes,
exactly
so,
for
our
whole
deployment
process
is
already
said,
we
use
a
pipeline,
shared
library
and
for
for
the
job
configurations.
We
also
have
some
shared
code
there.
We
have
also
our
knowledge
base
where
we
share
some
code
snippets
there,
and
there
are
also
some
plans
in
the
future
to
even
more
automate
this
and
to
more
generally
use
some
job
definitions.
B
A
A
A
C
A
We
usually
post
such
components
and
projects
in
the
benefits
open
source
repository.
So
if
you're
interested
for
in
various
integrations
or
configurations,
you
can
find
some
samples
there,
but
there
are
not
that
much
things
for
jenkins
at
the
moment.
So
I
think
that
we
need
to
push
for
that,
where
possible.
A
Okay,
so
I
think
we
ran
out
of
questions.
So
if
you
want
to
ask
something,
please
comment
in
the
chat
and
ask
questions,
and
meanwhile
I
have
a
generic
question.
I
keep
asking
everyone
participating
so
basically,
what's
your
experience
with
jenkins?
What
are
the
key
obstacles
you
experienced
when
setting
up
this
flow
for
your
teams
because,
of
course,
it's
very
important
to
know?
What's
not
working.
B
I
will
take
this
one
so,
since
I've
started
working
as
a
full-time
software
engineer
software
engineer,
I
think
I
always
worked
with
jenkins
on
the
ep
side
so
and
I
think
the
most
important
part
there
and
the
most
the
hardest
part
actually
is
to
do
the
knowledge
sharing
and
also
to
to
find
the
knowledge
gaps
there.
Because
for
you,
as
working
in
engineering
productivity,
you
know
about
all
the
stuff.
B
C
A
A
So
I
guess
the
question
so
when
you
run
juggles
and
kubernetes
one
of
the
first
questions
people
ask
is
whether
you
actually
want
to
use
jenkins,
or
maybe
you
want
to
use
something
else
like
argo
cd,
maybe
captain
for
some
use
cases
and
sebastian
asked
what
is
actually
your
approach.
So
what
do
you
consider?
The
other
tools.
B
A
A
C
A
Yes
makes
total
sense,
so
yeah
thanks
for
these
details,
I
mean
you,
don't
know
other
questions.
We
can
say
thanks
to
martin
and
katarina,
for
this
presentation
and
thanks
a
lot
to
everyone
who
provides
feedback
about
the
video
quality
etc.
We're
just
testing
the
platform,
so
sometimes
things
do
not
work
and
thanks
a
lot
for
patience.
A
B
B
A
A
So
thanks
again,
martin
martin
thanks
again
katarina
and
everyone
who's
working
on
this
system,
so
see
you
at
the
next
junkies
online
meetup.
We
don't
know
when,
but
hopefully
soon,
because
we
have
four
google
summer
of
code
projects
started
so
sooner.
There
will
be
more
topics
to
share
and
don't
forget
that
in
one
week
we
will
also
have
cdcon
and
there
will
be
a
lot
of
talks
about
jenkins
delivers
virtually
so
if
you're
interested
please
join
and
meet
the
community
there.