►
Description
Eiffel - An open-source event protocol for CI/CD pipelines - Emil Backmark, Ericsson
Eiffel is an open-source protocol specification for events to be used in CI/CD pipelines. The talk will describe the background to why the Eiffel protocol was first invented and it’s evolution. It will provide an overview of what the protocol looks like, what core parts it is made up of, and what use cases it is there to solve. The talk will also cover how the Eiffel protocol relates to the emerging CDEvents protocol, how it helps CDEvents on its path to success, and what lies ahead for the two of them.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
Thank
you
very
much,
okay,
so
welcome
back
everyone
from
lunch.
I
had
the
opportunity
to
keep
you
awake
first
hour
after
lunch,
see
if
I
can
manage
so
I
will
talk
about
eiffel.
You've
heard
the
name
if
you've
been
here
the
whole
morning.
You
heard
the
name
at
least
twice
this
morning
and
I
will
try
to
tell
you
what
it
is
about,
why
it
was
invented
and
created
what
it
really
is
and
what
we
think
could
be
the
future
of
isil.
B
B
in
ericsson.
At
the
time
we
had
hundreds
of
development
teams.
We
developed
mobile
systems
by
then
2g
3g
4g
systems,
in
parallel
hundreds
of
teams
with
thousands
of
developers.
In
them
we
integrated
our
products
in
multiple
levels,
from
low
level,
libraries
through
components
through
some
delivery
modules
and
to
to
load
module
containers
which
were
eventually
deployed
in
the
customers.
B
B
B
Continuous
integration
was
the
thing
at
that
time
and
agile,
and
we
started
to
use
those
practices
as
well
in
our
production,
so
our
production
system
had
some
needs.
We
needed
to
be
able
to
visualize
what
goes
on
in
these
builds.
We
called
it
the
production
system
by
the
way,
that's
the
whole
pipeline
from
source
commit
into
the
delivery
of
towards
the
customers.
B
B
B
B
B
B
Still,
I
would
say
we
have
this
multiple
integration
levels-
maybe
you
can
argue
if
they
are
still
actually
integrations
in
a
cloud
infrastructure,
but
bear
with
me.
I
think
that
we
do
integrate.
Of
course,
maybe
we
just
we
build
and
deploy
smaller
pieces,
but
so
the
integration
doesn't
maybe
happen
on
the
build
level
anymore,
but
it
more
happens
in
deployment
instead.
So
we
have
well
deployment
dependencies
and
and
and
integrations
of
our
builds
of
course
in
in
the
system.
Still
sorry
and
yeah.
We
started
to
use
argo.
B
Since
we
went
more
cloud
native,
we
started
to
use
argo
as
our
workflow
engine
instead
of
using
jenkins.
Well,
we
still
use
jenkins
and
we
used
at
the
time,
but
we
started
to
introduce
argo
a
few
years
back.
Actually,
when
we
did
that
tekton
wasn't
yet
a
thing.
So
that's
why
we
chose
argo
workflow,
still
a
lot
of
internal
tools
and
also
an
increasing
amount
of
open
source
software
to
handle
this
cloud-native
new
world
that
we
all
went
into
continuous
integration
delivery
and
also
continuous
deployment.
B
B
So
what
is
eiffel
then?
What
is
it
really?
Well?
There
are
two
aspects
to
it.
There
is
an
event
protocol,
a
specification
if
you
will-
and
there
is
also
an
ecosystem
of
tools
surrounding
this
event-
protocol
when
we
say
ifill,
we
primarily
mean
the
protocol,
but
there
is
also
an
ecosystem
that
the
community
is
working
with.
B
B
And
this
is
a
picture
of
a
famous
landscape
picture
and
this
is
the
eiffel
one
in
the
middle
here
you
can
see
the
eiffel
protocol
repository.
That's
the
eiffel
thing.
It
looks
very
small
in
this
picture,
but
it's
maybe
actually
the
main
part
of
the
community
surrounding
that.
We
have
a
lot
of
different
tools
in
this
eiffel
community
organization
in
github.
B
There
is
one
and
will
come
more
tools
that
are
eiffel
aware,
but
are
not
really
contained
within
the
git
organization
of
every
community,
but
instead
in
others.
This
is
the
jenkins
plug-in
where
we
develop
eiffel
support
for
jenkins
and
that's
then
located
in
the
jenkins
organization
in
github.
Instead,.
B
B
The
green
ones
relate
to
source
changes.
When
you
want
to
notify
that
something
has
happened
in
your
source
control
system,
the
blue
ones
are
about
activities
as
we
call
them
in
rifle
and
an
activity.
I
want
to
say
already
now:
an
activity
could
be
a
complete
pipeline
thingy,
it
can
be
a
step,
it
could
be
a
stage.
It
could
be
a
job,
a
build
anything
that
has
a
start
and
an
end
more
or
less
that's
an
activity,
it's
rifle,
and
they
can
then
be
hierarchical.
B
B
B
You
can
see
here
the
name,
the
activity
type.
For
this
sorry,
the
event
type
is
eiffel
activity
started
event.
That's
what
we
call
this
activity
started
event.
Really
all
the
events
in
eiffel
have
a
strict
syntax,
so
there
are
always
three
different
objects
on
the
top
level
of
the
meta,
sorry
of
the
json
blob.
B
B
B
Then
you
have
the
data
object,
which
is
different
for
each
event:
type
we
have
so
depending
on
event
type.
There
could
be
different,
mandatory
and
optional
properties
in
the
data
objects,
and
then
we
have
the
links
object
here,
which
I
will
explain
a
bit
more
in
detail
soon
to
the
right
here
you
see
the
same
event
type.
Actually,
the
activity
startup
event.
You
might
not
be
able
to
read
this.
B
B
So,
let's
take
a
small
look
into
some
of
the
event
categories,
then
so,
starting
with
the
activity
related
events,
this
is
about
starting
and
ending
a
pipeline
or
a
step
or
build,
or
something
like
that,
so
an
activity
trigger
event
is
what
you
would
send.
If
you
want
to
say
that
now
I
have
queued
an
activity
to
be
started,
something
to
be
built,
something
to
be
tested,
something
to
be
started
in
some
way
put
into
queue.
B
B
It
has,
though,
some
optional
parameters,
for
example,
at
least
as
you
see
here,
we
have
execution
uri,
which
points
to
the
execution
you're
performing
could
be
a
path
to
a
jenkins
host
where
your
build
is
running,
and
then
we
have
something
called
live
logs,
that's
more
or
less
where
you
can
see
live.
What
logs
are
currently
being
created
from
your
activity,
and
there
are
more
that
can
be
added.
If
you
like
an
activity
finished
event
then
has
one
mandatory
part
in
its
data?
It's
the
outcome.
B
So
now
we
see
three
different
events
here.
How
can
we
then
know
that
these
events
come
from
the
same
actual
execution
of
this
activity
and
that's
now
where
the
links
come
into
the
picture,
so
let's
go
back
to
the
activity
triggered
event
again
and
look
into
some
more
details.
There
I
mentioned
a
few
slides
back
that
there
is
an
id
field,
always
in
the
meta
object,
which
is
a
uuid
a
unified
id.
B
B
B
B
B
So
as
soon
as
your
build
system
has
built
this
artifact,
you
could
send
this
artifactuated
event
without
having
published
it
or
tested,
or
anything
just
want
to
say
that
now
I've
built
it
so
there
exists
in
the
system
somewhere
in
artifact,
with
this
specific
id
and
version,
then
maybe
you
have
some
test
activities.
You
probably
have
where
you
would
test
this
artifact,
probably
deploy
it
somewhere
and
test
it,
and
then
you
would
send
a
confidence
level
modified
event.
If
you
were
here
just
before
lunch,
eric
talked
about
confidence
labels
in
alpha.
B
B
B
And
the
link
type
here
is
artifact
not
subject,
so
it
means
I
mean
you
should
it
should
be
possible
to
read
just
looking
at
the
link
types
about
the
relationship
between
these
different
events,
so
the
artifact
that
is
published
is
the
created
one
in
the
conference
they'll
level
modified
case.
It's
the
subject
of
this
conference
level.
Is
that
artifact
it
could
be
something
else.
It
could
be
a
source
change
or
something
else.
B
So,
looking
into
a
bit
more
complex
example
with
these
links,
then
in
the
bottom
you
see
a
quite
simplistic
pipeline,
very
simplistic
pipeline,
where
you
first
see
that
your
source
code
has
been
merged
and
that
merge
would
then
trigger
a
build
of
some
kind
and
then
a
test
activity,
and
then
eventually
you
will
deliver
it.
If
it's
all
successful
to
notify
about
the
source
change,
we
send
a
source
change
submitted
event
rifle
containing
the
reference
to
the
actual,
commit
or
pull
request
or
whatever
you
want
to
notify
it
with.
B
Then
the
build
activity
starts
with
the
trigger
event,
started
and
finished
events,
and
then,
in
between
the
start
and
finished
events,
you
will
most
certainly
send
events
about
the
actual
artifact
being
built
here.
We
see
a
new
event
which
you
didn't
see
before
the
cd
event,
composition,
defined
eric
also
talked
about
compositions
earlier
today.
B
So
in
this
case,
it's
just
one
link
from
the
composition
to
the
source
change
event,
in
this
case
with
an
element,
but
the
composition
could
contain
arbitrary
number
of
other
artifacts
libraries
or
whatever
that
you
want
to
build
into
this
new
artifact
and
then
an
outfit
created
event,
descent
with
a
composition
there,
and
I
think
I
need
to
rush
this
a
bit.
Then
we
come
to
the
test
activity
triggered
started,
finished
again,
similar
thing.
We
have
some
test
suite
events
going
on
there
also
referencing
the
activity.
B
Then
there
is
also
the
course
link
here
stating
that,
for
example,
the
course
of
this
build
activity
being
being
triggered
was
that
there
was
a
new
source
change
submitted.
The
course
of
this
test
activity
being
started
was
that
the
build
activity
finished
successfully
and
so
on,
similar
for
publishing
or
delivery.
If
you
wish
something.
B
So
what
are
all
these
links
good
for
them?
Well,
and
why
are
they
so
important
to
the
eiffel
protocol?
Well,
they
are
needed,
since
the
events
are
quite
thin
and
eiffel.
We
don't
duplicate
data
between
events.
If
you've
already
said
in
norfolk
created
events,
what
id
the
artifact
is,
you
don't
add
it
again
to
the
artifact
published
event
or
the
conference
the
modified
event.
Instead,
you
reference
using
these
links
and
with
a
graph
of
these
linked
events.
B
B
B
We
can
also
trace
upstream
or
backwards
to
find
out,
for
example,
what
source
change
were
involved
in
a
certain
artifact
version
if
those
source
ranges
were
made
by
different
organizations
and
maybe
in
different
sem
systems.
Even
so,
this
traceability
is
crucial
when
you,
for
example,
find
a
bug
or
a
security
vulnerability
in
deployment
somewhere.
B
I
cannot
mention
it
all
due
to
time
restrictions,
but
there
was
a
recording
from
last
year's
silicon
in
2021
a
year
ago,
where
I
discussed
linking
a
lot
more.
So
please
go
to
that.
Recording
if
you're
more
interested
in
in
what
links
could
help
you
with
so
now.
You
might
have
wondered:
how
can
we
then
find
all
these
referenced
events,
as
we
don't
include
all
data
in
all
events,
but
instead
reference
previous
events.
B
B
B
Of
course
the
company
I
represent
is
there
access
communications,
a
company
in
the
camera,
surveillance,
business
and
volvo
volvo
group,
so
this
ericsson
and
axis
and
volvo
are
the
companies
that
are
involved
in
the
technical
committee
for
our
field
right
now,
and
just
a
few,
a
few
weeks
back,
we
learned
that
nasdaq,
the
stock
market
company
is
actually
using
eiffel
in
production
as
well,
which
was
news
to
ourselves
just
a
few
years.
A
few
weeks
back.
B
B
We
will
still
have
these
integration
levels,
but
they
will
probably
not
be,
as
I
said
before,
on
build
level.
They
would
rather
be
when
we
deploy
things.
So
we
will
have
the
integration
going
on
in
the
cloud.
Instead,
all
the
microservices
being
integrated
into
larger
applications
or
whatever
we
will
still
have
the
needs
in
our
production
system
to
calculate
lead
times.
Visualize.
B
B
B
So
what
about
the
thing
that
could
put
this
together?
Then
it
could
be
seed
events,
so
if
seed
events
is
successful
and
if
it
becomes
native
in
many
of
these
different
open
source
products
that
we
use,
I
would
guess
that
we
would
move
from
eiffel
to
cd
events,
but
it
more
or
less
all
depends
on
you
guys
and
everyone
in
the
in
the
seed
events
community
to
help
out
making
this
a
success.
B
Just
after
my
talk
now,
you
will
hear
more
about
the
proof
of
concept
from
web
and
there's
a
need
to
have
getting
started
information
or
it
needs
a
way
to
get
started,
and
that,
of
course,
is
very
much
enabled
by
the
cloud
native
and
the
kubernetes
deployments
that
we
can
have
today.
So
it
should
be
very
easy
to
to
get
something
started
quickly.
Using
these
events,
we
should
consider
generalness
versus
specificness.
B
That
might
be
a
bit
strange,
but
what
I
mean
is
that,
for
example,
for
a
sword
change
event
in
the
eiffel
world,
we
have
one
kind
of
source
change
events
dealing
with
any
kind
of
scm
system,
so
both
clearcase,
as
you
saw
before
and
git
they
are
both
notified
using
the
same
event.
Maybe
that's
not
always
the
best
fit
because
clearcase
and
git
they
have
two
quite
different
paradigms
when
it
comes
to
source
control.
B
B
We
should
also
combine
ci
cd
paradigms.
I
mean
cs
what
the
tools
in
the
city
domain
look
like
with
experience
from
research
in
academia
and
architecture
in
eifel.
We
have
mostly
actually
used
research
based
evolution
of
the
protocol
and
the
architecture
of
I
mean
see.
I
see
the
system
architecture
in
a
high
level
and
not
that
much
looking
into
what
can
the
crcd
tools
help
us
with?
B
B
Here
it
has
a
slide
with
links,
you
can
have
it
afterwards
and
my
last
slide
bottom
line.
What
to
communicate
is
volitional,
but
how
to
communicate.
It
is
not
meaning
you
can
say
whatever
you
want
from
your
system,
you
can
tell
if
you
are,
if
you
want,
you
can
tell
about
activities
being
started
or
finished
or
whatever
you
can
tell
about,
builds
being
done.
C
B
For
sure,
so
I
didn't
mention
much
about
what
the
actual
parts
of
this
ecosystem
is,
but
I
think
that
the
parts
in
this
ecosystem
are
needed
to
be
able
to
provide
a
well
functioning
event,
aware
city
system.
So
for
sure
we
need
somewhere
to
store
events,
and
we
should
cooperate
around
some
kind
of
store.
There
could
be
multiple
stores.
B
I
don't
doesn't
really
matter
if
there's
just
one
way
to
store
events,
but
we
need
to
have
ways
to
store
events,
of
course,
in
the
ecosystem,
and
also
we
need
to
have
plugins,
hopefully
native
plugins,
to
the
different
cicada
tools
in
this
ecosystem
as
well
and
means
to
to
stand
and
receive
events
and
understand
them.
These
sdks
that
people
have
been
talking
about
earlier
today
as
well.