►
From YouTube: Making your CI/CD Pipelines Speaking in Tongues with Open... Ivan Fernandez Calvo & Victor Martinez
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Making your CI/CD Pipelines Speaking in Tongues with OpenTelemetry - Ivan Fernandez Calvo & Victor Martinez, Elastic
Building and delivering software faster and better gained a different meaning with the introduction of pipeline-based technologies like Jenkins. Today, developers can automate the whole software development lifecycle by programmatically implementing build, testing, and deployment to achieve development agility. While this is great on the one hand, it poses an important question to be answered: what if the pipeline has a bug? For this reason, pipeline maintainers ought to have a strategy in place capable of verifying the pipeline code's accuracy, correctness, and reliability. Luckily for us, Jenkins allows this by providing a plugin compatible with OpenTelemetry — a technology that grants developers the ability to evaluate their code using an observability backend. This session will explain how this works and demonstrate how to get value from this.
A
A
B
A
Okay,
here
we
are
so
I'll,
give
you
a
brief
summary
about
where
we
are
so
the
cicd
or
continuous
integration.
Continuous
delivery
produce
a
key
foundation
in
any
software
development
in
your
area
that
you're
probably
familiar
with
sometimes
understanding.
What
are
the
resources
that
you
need
for
running
your
build
or
test?
A
So
in
the
end,
it's
the
same
idea.
You
have
your
binary
that
you
generated
previously,
you
compile
you
test
and
you
deploy.
So
it's
simple
right,
but
how
you
present
the
data
is
not
easy
right.
Every
vendor
does
something
different,
but
the
ultimate
goal
is
because
the
behavior
is
similar.
There
are
operations
to
compile,
so
it's
easy
to
visualize
with
observability
all
the
logs
that
you
are
receiving
from
the
bills
that
you
run.
A
The
deployments
you
run
and
so
on
are
also
something
that
you
can
correlate
them
to
know
that
the
operation
you
run
actually
represent
this
particular
log
with
all
the
information
and
also
the
metrics
that
are
important
because
give
you
a
first
glance.
What's
going
on
right
with
your
system
for
this,
we
believe
that
distributed
tracing
is
a
key
part
for
this,
even
for
the
cicd,
because
it
cannot
be
just
used
for
when
the
system
is
down,
and
you
want
to
recover
the
system
to
put
it
in
production
and
healthy
again.
A
So,
regarding
ability
there
are
three
pillars
and
I'm
going
to
use
an
analogy,
so
you
think
about
metrics.
You
have
your.
Let's
talk
about
jenkins
as
one
of
the
cicd
systems.
We
use
that
elastic
known.
How
many?
How
big
is
the
build
queue
to
be
a
metric
that
you
you
need
to
understand
right
because
that's
affecting
your
capacity
plan,
all
the
bid
logs
that
is
coming
from
the
run
or
the
different
pipelines
or
freestyle
jobs
in
terms
of
jenkins
are
information
that
is
important
and
you
want
to
debug
deeply
right.
A
What's
going
on
in
your
system
and
traces,
as
I
mentioned
earlier,
the
different
operations,
like
you
check
out
the
source
code,
you
run
a
maven
compile
or
you
upload,
an
artifact
to
google,
storage
or
s3,
and
so
on.
These
steps
are
pretty
much
the
information
you
you
can
understand
deeply
what's
going
on
in
your
system,
so
those
are
the
three
pillars
for
receivability
and
open.
Telemetry
is
just
pretty
much
an
implementation
of
actuality,
so
it's
a
kind
of
tools,
apks
apis
that
that
are
neutral
vendor.
A
So
everyone
could
use
that
because
the
main
goal
of
these
is
you
can
choose
the
best
vendor
for
what
is
your
use
case,
so
you
want
to
best
use
the
best
vendor
for
traces,
and
you
think
that
vendor
is
better,
because
if
the
speed
is
better
and
so
on,
because
you
just
open
telemetry,
then
you
can
easily
change
from
one
vendor
to
another
depend
on
the
use
cases.
So
this
is
just
an
idea
of
everything
that
runs
in
your
system,
your
platform
and
so
on.
A
Can
ship
data
for
these
three
pillars
I
mentioned
earlier:
traces,
metrics
and
logs.
There
are
different
vendors
that
they
support,
open
telemetry.
These
are
some
of
them.
Elastic
is
the
one
we
work
with
jager,
grafana,
honeycomb
and
so
on.
These
are
some
of
them
that
they
natively
support,
open,
telemetry.
A
So
now
thinking
about
the
cicd
ecosystem,
how
you
compile
how
you
test?
What
tools
you
use
all
those
are
potentially
things
or
systems
that
you
can
integrate
with
open,
telemetry
and
send
data
all
the
telemetry.
So
what
we
did
back
in
the
days
is
build
different
integrations
that
send
data
with
open
telemetry.
Let's
talk
about
the
first
one,
which
is
in
jenkins,
so
this
is
a
representation
of
what
be
built.
A
A
A
So
maven
is
the
build
system
for
java,
it's
a
well-known
opinionated
system
and
it
works
based
on
goals
and
every
goal
can
be
a
meta
all
the
run,
other
subset
of
goals,
so
the
same
view
that
you
have
for
the
maven
package
that
pretty
much
is
compile
test
and
generate
a
binary,
so
it's
represented
as
a
blue
expanse
there,
which
are
pretty
much
that
particular
minimal
goal
that
run
like
compiled,
took
154,
milliseconds
and
so
on
and
so
forth.
So
that's
extension
we
made
as
well
regarding
open
telemetry
other
integrations.
A
We
made
ansible
integration
as
well
and
something
more
for
testing,
but
I
want
to
talk
more
because
tomorrow
here
at
2pm,
there
is
another
talk
about
open,
telemetry
and
test,
and
I
will
give
you
a
vision
on
how
you
all
together
test
data,
could
be
collected
from
the
telemetry.
I
don't
want
to
talk
more.
A
You
can
jump
in
this
tomorrow.
So
now
it's
time
for
the
demo.
I
roughly
touch
a
little
bit
of
the
three
concept
of
open,
telemetry
and
officiality.
So
our
main
goal
is
with
the
demo
is
a
canary
deployment,
quite
opinionated,
simple
for
the
demo.
So
if
it
works
bear
with
us,
if
not
we'll
do
our
rest,
so
it's
dockerized.
It's
going
to
run
in
our
machine.
A
It's
a
spring
job
application,
pretty
much
hello
world
and
that's
where
we
are
going
to
iterate
with
it
send
data
with
open
telemetry,
because
there
is
an
agent
open
telemetry
for
that
particular
screen.
Job
application
and
you
send
data
to
the
open,
telemetry
collector,
similar
with
jenkins.
There
is
a
plugin
configured
to
send
all
the
traces
metrics
for
maven,
as
well,
as
I
mentioned
earlier,
and
then
ansible
to
deploy
the
service
in
a
new
version
in
a
new
system
and
pi
tests
to
run
some
kind
of
health
check.
A
So
we
want
to
validate
if
the
service
that
has
been
deployed
is
good
to
be
promoted.
So
this
is
the
idea
of
traces
and
logs
and
metrics
that
we
send
jenkins
will
send
all
everything
log
magician
traces
maven
will
run
afterwards
and
there
is
always
a
context.
Propagation,
so
jenkins
run
a
modern
bill,
so
we
will
be
able
to
see
the
two
traces
together
and
it
will
help
us
to
understand
holistically
how
all
this
cicd
workflow
works
similar
with
the
other
tools.
A
So
for
us,
the
canary
deployment
I
mentioned
quite
opinionated,
so
it's
just
trying
to
illustrate
how
all
together
work.
But
the
idea
is
we
push
changes
that
we
made
some
changes
in
the
source
code
and
eventually
a
jenkins
bill
will
run
and
if
it
compiles,
then
it
will
deploy
and
if
the
canary
service
is
good,
because
there
is
not
any
errors
in
the
transaction.
So
you
know
like
accessing
to
the
entry
point.
No
errors,
then
we'll
be
able
to
deploy
the
version
to
the
other
services
the
same
version.
A
What
are
the
different
use
cases?
Well
we're
trying
to
do
four
chain
hello
world
by
by
war
in
the
ui,
then
a
sneak
dependency
snake
is
a
security
layout.
We
run
for
maven
to
validate
the
dependency,
doesn't
have
any
security
impact
like
the
night
of
service
and
so
on.
The
other
one
is
we're.
Gonna
synthetically
introduce
an
error
in
the
application,
how
the
rollback
work
and
a
password
leak,
like
probably
everyone
is
familiar
with.
We
are
not
gonna
present
much
with
jenkins
ui.
B
B
Victor
say
we
have
a
jenkins
running.
We
have
a
nexus
for
the
artifacts,
the
two
applications.
That's
this
simple
application
that
only
shows
a
message
in
in
a
browser
and
a
yankees
that
will
trigger
all
the
builds.
So,
let's
start
with
the
width,
so
we
will
receive
some
notifications
like
to
to
know
that
the
the
there
are
changed.
So
we
will
start
with
making
change
in
norcold.
We
have
prepared
some
patches
to
make
things,
don't
spend
more
time
in
it,
so
give
apply
demo
demo,
the
first
change.
B
B
B
B
So
we
have
pushed
the
change
to
the
git
repository
and
we
does
trigger
a
bill.
We
have
to
change
recently
the
the
post
hook,
because
we
have
problems
with
the
checkout,
but
it's
fine.
So
here
we
have
the
the
the
given
instant
that
is
collecting
all
the
all
the
data
related
with
open
telemetry
and
at
some
point
we
saw
that
there
is
a
slack
notification
that
the
bill
has
finished.
B
B
B
B
B
So,
let's
fix
the
theme
we
have
a
patch
for
that
gate,
apply
the
moon
demo,
the
second
change
and
git
div,
and
we
fix
the
issue
basically
in
the
specifications
that
sneaks
say
to
us,
that
is
a
bump
in
the
dependencies
we
bump
the
dependency
of
spring
boot
and
another
dependency
on
the
spring
that
resolved
the
daniel
circuit
ever
that
was
in
the
in
the
call.
So
we
do
us
again.
B
I
commit
that
is
a
fix,
fix
and
is
fine.
We
make
the
the
push
and
we
make
the
post
hook
to
trigger
the
bill.
So
we
push
all
the
changes
and
we
trigger
another
bill
the
mean
time,
because
this
bill
will
take
a
little
bit
longer.
We
see
some
some
stuffing
or
we
show
some
stuffing
in
the
given
aside.
So
here
we
see
the
the
three
three,
the
three
services
that
we
have
right
now
then
refer
out.
This
is
the
application,
the
jenkins
and
maven.
That's
the
traces
from
the
bill.
B
There
is
no
errors,
we
don't
see
any
error
in
the
in
the
transition
rate,
so
yeah
we
can
show
more
stuff
here,
services
we
go
to
the
let's
see
the
the
mailing
service.
Meantime
that
we
see
the
the
bill
goal
that
we
have-
and
here
we
see
the
same-
we
see
some
some
traffic
inputs
and
the
this
the
traces
from
from
the
maven
bill.
We
see
the
the
main
goal
and
the
the
goals
that
we
have:
gdp
requests
and
so
forth
sneak
test.
B
B
Let's
check
jenkins,
it's
there,
okay,
so
the
bill
finish
and
say:
that's
too
fast,
let's
check
the
the
the
traces
to
see
how
it
looks
so
here
we
have
the
the
the
deploy
that
we
say,
that
is
a
canary
deployment
and
we
see
the
the
the
traces
that
we
have
in
in
this
build.
Let's
go
to
the
beautiful
field
trace,
because
this
is
only
the
the
deployment
because
we
call
a
job
a
yankee
job
from
yanking
jokes
and
distributed
and
give
out
the
the
the
latest
part.
B
B
We
continue
in
mainland
building
the
the
docker
image
we
deploy
docker
image
in
in
the
nexus
repository
yeah,
then
c3,
wherever
blah
blah
blah
blah
blah
blah,
then
we
are
right
to
the
deploy
part
that
is
another
european
champion.
So,
in
the
distributed
tradition,
we
saw
that
all
the
traces
that
all
the
parts
of
the
of
the
build
that
we
are
triggering
has
many
pieces.
It
has
two
jobs
in
jenkins
and
the
maven
part,
the
uncivil
part
and
everything.
B
B
That's
at
some
point
here
we
see
that
make
call
ansible
and
run
the
the
deploy
canary
playbook
that
we
have
financial
and
we
saw
the
tasks
from
ansible,
the
files,
the
load,
the
docker
hub,
whatever
the
the
health
check.
That
is
the
the
test
that
we
have
in
python,
that
run
with
betas
and
make
make
a
check
in
the
in
the
stack
that
the
error
rate
in
the
last
five
minutes,
it
doesn't
doesn't
pass
a
threshold
if
they
pass
the
threshold.
We
make
the
row
back
in
this
case.
B
There
is
no
errors,
because
the
application
doesn't
return
an
error.
So
what
we
make
is
a
pass
to
the
next
stage.
That
is,
make
the
full
deployment
again
with
ansible.
We
run
another
another
playbook.
That's
deploying
the
two
instances
that
we
have
deployed
this,
the
the
02
version.
So
if
we
go
now
to
the
the
two
instances
that
we
have
now,
instead
of
hello
world,
they
say
buy
wall.
That's
it
simple,
nothing
special!
B
Okay,
we
move
the
chains
we
trigger
the
the
boss
hook
and
this
will
make
the
change
trigger
another
job
and
so
on
and
so
forth.
In
the
meantime,
let's
go
back
to
kibana
and
let's
see
what
we
have
right
now,
because
we
are
running
more
services
in
the
last
bit
in
las
vegas.
We
see
more
services.
Here
is
failure.
B
No,
this
is
another
thing.
Okay,
we
see
more
services
here
we
see
the
the
the
ones
that
we
have
before
the
anti-fraud
jenkins
amazing,
and
we
have
a
couple
of
of
a
couple
months:
the
ansible
one
and
the
pythagoras
one,
the
ansible
one.
We
can
show
how
looks
at
the
execution
of
a
playbook
if
we
go,
for
example,
for
the
full
deployment
the
probabilities
is
bigger.
B
We
see
how
a
playbook
looks
like
a
transaction.
We
see
the
the
the
playbook
and
all
the
tasks
that
are
in
the
playbook.
We
can
check
the
the
metadata,
for
example,
of
the
of
the
main
main
playbook,
and
we
saw
some
information
related
with
the
with
the
play
with
the
id,
the
name
and
the
user
that
launched
a
team
the
session
for
pi
tests.
We
have
more
or
less
the
same
thing.
B
B
B
Okay,
that's
I
don't
know
if
we
can
make
lay
with
the
wall
the
wall
and
then
but
it's
fine.
So
we
have
the
the
next
thing
version
three.
Is
that
one
is
there
yeah?
So
we
go
to
the
bill
that
should
fail
and
we
check
what
is
fail.
This
is
the
change
that
we
remember.
That
is
the
the
changes
that
we
made
to
make
a
synthetic
error
and
see
the
the
rollback.
So
again
we
have.
B
B
B
B
If
we
see
the
the
traces
we
see
that
the
then
in
the
health
checking
points,
we
have
an
error
rate
of
23
percent.
That
is
the
the
root
cause
of
what
we
make
the
dreaders
roll
back
and
everything
is
on
that
in
open
telemetry.
We
are
doing
everything
in
open
television
and
we
see
the
errors
that
we
have
and
we
see
503
errors
in
the
services
that
we
have
in
both.
So
something
is
really
wrong.
B
A
Right
so
for
the
future,
every
single
span
you
saw
there
will
contain
metadata.
It
depends
what
information
you
gather
is
something
that
you
probably
want
to
standardize.
So
how
you
use
maven,
how
you
use
jenkins
github
anything
like
send
data
for
the
cicd,
so
that's
important
to
mention
like
we
need
to
standardize
like
every
vendor
that
you
use
should
provide
probably
the
same
kind
of
naming
and
attributes.
So
that's
something
we
are
going
to
start
working
on,
and
there
is
this
actually
in
the
city,
there
is
a
sick
events
about
actually
standardizes.
A
We
want
to
encourage
people
to
add
more
integrations
with
open
telemetry
like
gradle.
I
don't
know
any
other
build
system
that
you
would
like
to.
It
could
be
also
sending
data.
We
are
planning
to
support,
correlate
locks
so
for
maven,
so,
rather
than
sending
traces,
also
correlate.
What
is
the
bill
output
log
to
be
able
to?
Actually,
you
know
debug
with
something
wrong
and
finally,
all
the
machine
learning
right.
So
we
want
to
start
thinking
about
how
we
can
make
this
easy
to.
A
You
know
djs
data
that
is
massive
to
discover
patterns
like
probably
hard
to
discover
unless
you
are
a
specialist
you
want
to
know
more.
These
are
some
of
the
references
that
you
can.
You
know
read
more,
thank
you
and
I
don't
know
we
have
time
for
some
questions
like
two
minutes.
So
a
few
minutes.
Okay,
okay,
so
we
went
in
a
rush.
We
couldn't
show
you
the
password
leak,
so
it's
just
pretty
much
discovering
regex
for
all
the
locks
that
are
coming
from
open
telemetry.
I
give
you
just
that
present.
A
A
So
it
works
pretty
much
dockerized
and
you
can
easily
interact
with
so
my
recommendation.
You
want
to
start
with.
First,
the
open
telemetry
collector
might
help
you,
because
it's
the
place
where
you
send
data
and
automatically
you
can
configure
with
some
xml.
What
is
the
vendor?
You
can
use
elastic.
Specifically,
you
can
use
jager,
you
can
use
prometheus
and
so
on.
So
you
can
specialize
where
so
having
that
particular
open
telemetry
collector
close
to
where
the
data
is
coming
from.
A
Obviously,
because
if
you
want
to
reduce
latency
and
so
on,
it's
simple
and
then
the
other
thing
it
will
be
related
to
janky's.
Plugin
is
a
global
settings.
If
you're
familiar
with
jenkins,
pretty
much
fill
in
the
form.
What
is
the
password
user,
the
open,
telemetry
entry
point
and
then
it
will
start
working
for
maven.
You
use
a
pretty
much
environment
variables
that
we're
trying
to
standardize
for
everyone
like
the
open
telemetry.
I
think
they
use
header
open
telemetry.
A
I
don't
remember
now
it's
a
http
header,
but
it's
pretty
much
two
environment
variables
that
you
define
entry
point
password
and
then
it
will
start
working
on.
So
you
just
need
to
change
the
pom
file
with
the
extension
and
then
the
magic
happens.
So
it's
trying
to
instrument
implicitly
rather
than
explicitly
so
it
should
work
out
of
the
box.
A
Right,
that's
a
question,
obviously
the
so.
The
question
is
about
the
machine
learning.
So
in
this
case,
as
we
work
at
the
elastic,
we
can
use
the
machine
learning
because
it's
one
of
the
features
capabilities
we
could
use.
But
again
it
is
already
integrated,
because
all
the
data
is
analysis
search.
Then
the
machine
learning
is
a
node
that
you
specialize
to
do
make
you
know
analysis
of
the
data,
probably
other
vendors,
might
have
something
similar
or
the
good
thing
is
open.