►
From YouTube: Remove the Hurdles of Non-interoperability in Your CI/CD Workfl... Shruti Chaturvedi + Oleg Nenashev
Description
Remove the Hurdles of Non-interoperability in Your CI/CD Workflows by Choosing Event-Driven Standardization - Shruti Chaturvedi + Oleg Nenashev, Dynatrace
Interoperability is essential to building cloud-native, event-driven workloads across CI/CD tools, but the lack of normalization and standardization while designing an effective event-driven architecture is a big challenge. Event-driven is essentially a design pattern where systems emit events and other participating systems react to those events. There are different ways to build this reactionary EDA. The main goal is that the events occurring within the CI/CD workflow should be dealt with effectively. Interoperability defines if and how are our systems interactingwith each other.
In this session, we’ll see the nuances of interoperable systems and discuss the need to standardize interoperability in event-driven systems. Within event-driven systems, we have the tools which emit or receive events, and then we have the actual events. We’ll take a closer look at how defining a standard for which event should be emitted when and what that event should look like makes working in multi-tool CI/CD workflows easy, efficient and cheap. CloudEvents, a common format for describing all event data, helps cross one phase of the interoperability roadblock elegantly. CDEvents helps cross the second phase by defining a standard vocabulary so the need to handle separate events emanating from separate tools is eliminated. We’ll start by looking at the CloudEvents plugin for Jenkins to see the advantage of standardization in event-driven architecture. We’ll also discuss how the CDEvents spec can add another dimension to what event-driven architecture can look like. With so many tools in the CI/CD workflow emitting similar yet different events, we fail to capture the power of event-driven. This, however, can be solved by leveraging standardization.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
All
right,
well,
hello,
everyone
hola,
it
seems,
should
be
saying
hola
here,
so
my
name
is
shadi
chatter
vedi,
I'm
a
back-end
engineer
at
gander,
so
at
gander
we
are
humanizing
e-commerce.
Well,
we'll
talk,
maybe
a
bit
more
about
that
later.
But
this
session
is
about
removing
the
hurdles
of
non-interoperability
in
your
ci
cd
workflows
through
event-driven
standardization,
so
moving
right
on
ahead,
so
the
three
ingredients
for
a
successful
system
and
when
we
say
successful,
we're
looking
at
three
key
vectors,
agility,
resilience
and
scalability
and
all
these
three
components
are
super
essential.
A
So,
however,
interoperability
without
standardization
leads
to
non-agility,
non-resilience
and
non-scalability.
So
we're
going
to
talk
and
hear
from
great
people
about
vendor
and
architecture
and
also
about
interoperability.
But
what
I
want
to
do
is
just
focus
a
bit
more
on
interoperability
in
the
next
slide,
so
different
types
of
interoperability.
So
we
have
direct
interoperability
and,
as
kara
mentioned
this
in
the
first
presentation,
this
is
what
we
can
correspond
to
integrations
and
then
we
have
indirect
interoperability,
which
is
really
the
true
interoperability
that
we're
looking
at
so
think
of
this.
A
In
terms
of
in
terms
of
example,
here
is
I
personally,
don't
speak
spanish,
and
here
I
might
need
a
spanish
translator,
someone
who
can
speak
spanish
for
me
and
if
I
go
to
germany,
I
might
need
another
person
who
speaks
german
and
can
help
me
translate
with
them.
So
you
know
it
leads
to
a
very
large
number
of
translators.
A
I
might
need,
as
I
keep
moving
countries,
but
an
indirect
interoperability
would
be
just
choosing
something
standard,
a
standard
language
where
everyone
can
understand
that,
so
that
would
be
cheaper
so
with
direct
interoperability
or
integrations
services
get
coupled
tightly
and,
as
we
say,
there's
a
direct
dependence
on
that
translator.
Who's
going
to
translate
the
formula
translate
the
language
for
me
versus
indirect
propability,
whereas
there's
no
such
direct
connection.
A
Direct
interoperability
again
complex
to
skill,
because
you
need
so
many
integrations
versus
indirect
operability
scales
independently
of,
however
many
services
or
tools,
you
need
to
communicate
with
expensive
to
develop.
There's
some
math
for
everyone
right
here.
So
if
we
have
you
know
three
systems,
we
will
somehow
need
like
three
integrations
for
each
of
those
systems
versus
indirect
interoperability.
It's
cheap
just
because
it
does
not
need
individual
connections.
A
So
what
we
really
need
to
depend
upon
is
indirect
interoperability
or
standardization
and,
as
it
says
in
the
slide,
there
is
no
alternative
to
set
standards
as
workflows
is
scale
and
the
alternative
is
just
non-interoperable
interoperability
or
well
chaos
in
our
system,
so
standardization
and
event-driven
approach.
So
when
we're
talking
of
event-driven
architecture,
we
have,
we
can
look
of
it
in
three
different
components
or
we
have
the
the
event
producers
or
the
event
consumers.
A
Then
we
have
the
event
itself,
so
where
can
we
implement
standardization?
So
the
tool
level
is
the
first
level
where
we
can
put
in
standardization,
and
this
is
because
all
of
the
tools
they
each
have
different
terms
and
technologies
even
for
very
similar
context,
so
they
might
be
emitting
very
similar
events.
However,
in
different
ways.
So
this
is
the
two
level
standardization
just
standardizing
the
type
of
events
coming
in
from
different
tools.
Then
we
have
the
event
level
standardization,
where
we
are
standardizing
the
format
of
the
u.n.
A
So
first
we
standardize
the
type
of
events
coming
from
different
tools
and
then
we
standardize
the
format
that
the
event
will
will
be
in
and
the
routing
level.
Of
course,
this
is
how
the
events
are
routed.
We
have
different
http
kafka,
several
different
ties,
we're
going
to
focus
on
tool,
level
and
event
level
interoperability
in
this
presentation,
so
the
first
level
standardizing
the
format
of
events.
A
So
this
is
one
of
the
component
of
standardization,
where
we
are
gonna,
standardize,
how
the
events
are
formatted
and
what
that
and
the
tool
that
we
are
looking
at
is
cloud
events,
and
this
is
a
specification
for
describing
event
data
in
a
common
way.
So
this
is
again
not
describing
the
type
of
the
un,
but
this
is
this
once
the
event
type
is
already
described.
This
is
this:
this
is
just
the
format
or
how
the
event
is
going
to
look
like.
A
So
what
I'm
going
to
do
here
is
talk
about
cloud
events
plugin
for
jenkins,
which
was
developed
as
a
google
summer
of
code
project
last
year,
and
a
big
shout
out
to
all
the
mentors
with
cara,
oleg,
andrea,
the
eventsik
community
and
the
entire
city
foundation.
Community
they've
been
very,
very
helpful
and
helped
develop
this
super
cool
plugin.
A
So
what
the
cloud
events
plugin
for
jenkins
does
is
allows
jenkins
to
use
cloud
events
as
its
event
format,
so
this
is
still
not
sort
of
default.
However,
you
can
you
can
have
this
plug-in
into
your
system
and
then
all
of
the
events
or
well,
some
events
that
we
chose
are
going
to
be
in
the
cloud
events
format
so
jenkins.
Again,
this
diagram
right
here
and
it's
a
cloud
event
and
then
it
can
be
consumed
by
tecton,
k
native
captain
or
any
any
sync
that
consumes
cloud
events.
A
So
what
does
the
cloud
owens
plug-in
for
jenkins
do
well
a
couple
of
things:
the
cloudwins
plug-in
for
jenkins.
It
first
of
all,
the
format
of
the
events
going
in
and
out
of
jenkins
to
or
from
other
ci
cd
systems
is
standardized.
It's
standardized
because
we
are
using
the
cloud
owens
format.
So
it's
just
going
to
be
a
very
similar
here,
the
event
headers,
here's
where
the
event
payload
goes
and
we
are
using
the
binary
con,
the
content
mode
I'll
just
talk
about
that
in
a
sec
as
well.
A
So
the
need
to
maintain
tool-specific
adapters
to
understand
the
varying
event
formats
from
different
tools
is
eliminated,
because
so
now
we
know
what
event
or
what
format
is
that
event?
That's
going
to
come
in
so,
for
example,
k
native.
It
does
not
need
to
know
what
what
is
the
format
of
that
event,
because
well
it's
a
standardized
event.
So
we
do
not
any
of
the
tool
which
is
going
to
be
consuming.
A
This
event
from
jenkins
does
not
need
to
know
the
specific
format,
so
what
we
can
do
is
build
complex
end-to-end
pipelines,
extending
multiple
ci
cd
tools,
which
use
cloud
events
so
again,
leading
on
to
a
cheap
and
scalable
process.
You
can
scale
this
to
as
many
tools
and
as
many
systems
as
you
like,
as
long
as
you're
sync
or
as
long
as
the
consumer
of
the
event
can
understand
and
can
process
cloud
events.
A
But
again,
the
one
big
problem
is
the
various
events
from
jenkins
they're,
still
very
jenkins,
specific
they're,
not
ci,
cd
or
ci,
cd,
tooling
specific.
Yet
so
jen
can
specific,
still
means
that
this
is
not
adhering
or
conforming
to
any
standards.
You
would
have
a
build
event
very
specific
to
how
bills
are
presented
within
jenkins,
so
any
consumers
who
are
interested
in
those
events
build
events.
A
So
what
has
our
journey
been
with
the
cloud
events
plug-in
so
g-stock
projects
are
usually
divided
in
two
different
phases:
phase:
one
and
phase
two
well
phase,
two
really
kind
of
took
a
turn,
but
with
phase
one.
The
first
thing
we
started
off
with
was
configuring
jenkins
as
a
source,
and
this
is
where
jenkins
will
be
emitting
cloud
events,
so
we
we
had
to
look
into
event
listeners.
Where
can
we
get?
Those
events
from
the
second
part
was
figuring
out.
A
This,
I
believe
too,
was
a
bit
of
a
problem
because
we
just
put
in
everything
we
can,
because
there
was
no
standard
for
the
type
of
event
that
we
had
to
emit.
So
without
knowing
what
type
of
certain
event
belonged
to.
It
became
hard
for
us
to
understand
what
the
event
consumer
might
need
so
the
event
consumer,
for
example.
If
looking
for
a
build
event,
we
did
not
know
what
standards
do
we
need
to
conform
to?
A
What
can
the
build
event
that
the
consumer
needs
would
want
to
see
in
that
particular
event,
a
certain
id
and
name
or
whatever?
So
we
just
put
in
all
the
information
we
can
in
the
event
and
the
phase
two
was
just
us
understanding.
If
we
were
able
to
achieve
the
final
goal,
which
was
do
we
have
loosely
coupled
interactions
between
jenkins
and
other
ci
cd
tools
between
jenkins
and
techton
jenkins
and
captain
jenkins,
canada,
anything
that
consumes
cloud
events.
A
So
looking
into
the
events
supported
by
the
plugin,
as
we
said,
what
events
are
important
and
how
to
represent
them,
we
at
that
time
did
not
know
because
it
was
hard
to
tell
what
events
should
we
send
out
what
events
should
a
ci
tool
be
sending
out
the
other
pipeline
and
other
tools
in
the
pipeline
can
use.
So
whatever
we
thought
was
important,
we
put
in
there.
You
know
what
what
can
other
tools
need?
A
Maybe
q
events
maybe
build
events
and
node
events,
so
these
were
some
of
the
events
that
we
started
off
with
we
had
q
events,
job
events,
build
events
and
note
events,
and
this
was
somehow
taken
from
other
tools
and
events
that
they
supported.
So
this
is
before
cd
events
and
we
did
not
have
any
standard
vocabulary
or
standard
type
where
we
can
pull
all
of
these
events
together
and
represent
them
so
strategy
for
event.
Payload.
A
As
I
said,
we
just
put
in
a
lot
of
data
more
data
than
less
because
we
did
not
know
what
standard
or
what
is
the
type
of
this
event.
So
what
can
the
other
tool
that
is
consuming
this
event
can
look
for
so
here
is,
for
example,
a
q
event,
and
we
just
put
in
what
that
display.
What
is
the
name
of
the
job?
That's
in
display
what
how
long
it's
gonna
it
has
been
in
the
queue
and
all
of
that.
So
maybe
it's
not
the
most.
A
What
would
have
been
the
most
relevant
information,
but
we
had
to
put
in
there
just
in
case
the
the
person
who's
or
the
tool
that
is
consuming?
It
might
need
it
entering
phase
two,
and
this
was
when
we
were
asking
ourselves:
can
the
plugin
now
interoperate
with
now
jenkins?
Can
it
interoperate
with
other
ci
cd
tools
and
some
of
the
questions
that
were
in
our
mind?
How
will
the
other
ci
cd
tool
use
these
events
that
are
sent
by
the
cloud
events
plugin?
So
we
have
jenkins
sending
out
cloud
events
plugin?
A
Where
is
it
going
to
go
and
how
is
it
going
to
be
utilized
so
and
the
other
question
that
we
have
were
the?
What
will
the
event
consumer
need
in
order
to
process
the
cloud
events
plug-in
come
or
the
cloud
events
coming
from
jenkins?
You
know
we
do
send
out
the
cladowns.
Is
there
additional
information
that
we
need
to
put
in
there?
A
So
for
that,
we
designed
a
proof
of
concept
which
was
inspired
by
the
eventsig
team
and
inside
the
proof
of
concept.
We
had
jenkins
sending
out
cloud
events
to
the
k-native
cloud
events
broker,
and
this
is
essentially
our
event.
We
can
say
it's
like
a
handler,
which
is
where
all
of
the
cloud
events
are
coming
in
and
on
the
cloud
events
or
the
k-native
cloud
events
broker,
we
have
defined
a
k-native
trigger
and
a
trigger
is
essentially
can
think
of
it
as
a
filter.
A
Events
to
tecton
and
trigger
is
again
where
you
can
extract
specifics
from
that
event,
and
then
you
can
use
those
specifics
inside
your
task,
runner
pipeline
and
things
like
the
name
of
the
job
that
you
that
had
just
started
or
the
name
of
the
build
or
the
artifact
that
is
just
finished
and
then
finally
sending
it
on
to
the
task
run.
So
you
would
have
that
you
would
receive
that
information
and
then
act
upon
it.
A
typical
event,
driven
architecture.
A
A
A
A
A
The
terminology
used
is
very,
very
different
and
the
consumer
of
those
events.
They
must
be
familiar
with
that
tool,
specific
vocabulary
and,
if
they're
not
familiar
again,
the
consumer
does
not
know
what
it
need
to
do
or
what
it
should
be
doing
with
the
event
that
it
has
received.
So
our
plugin
was
not
entirely
tool
agnostic.
Well,
there
must
be
an
end
here,
but
yeah
the
the
plugin
was
not
entirely
tool.
Agnostic
still
needed
to
know
the
specifics
of
other
tools
in
the
tool,
specific
entities
and
all
of
that.
A
Yes,
we
did
not
need
any
additional
adapter
to
consume
the
events,
and
that
is
where
cloud
events
was
very
very
helpful,
because
there
was
a
set
format
for
how
each
event
is
going
to
look
like.
So
this
is
very
similar
to
if
someone
had
sent
out-
let's
say
a
medical
document,
and
everyone
knows
well,
the
temperature
is
in
fahrenheit
or
is
in
celsius.
So
you
can.
You
can
easily
translate
that
so
because
the
event
was
in
the
same
format.
A
It
was
very
easy
to
translate,
so
no
additional,
wrappers
or
adapters
were
needed
to
consume
it,
and
it
also
made
us
think
of
jenkins
as
a
sink
for
jenkins
is
a
sink
jenkins.
Consuming
events.
We
too
would
need
a
lot
of
work
in
order
to
know
the
nuances
of
the
of
different
tools
we
are
working
with,
for
example,
if
you're
working
with
spinnaker,
if
you're
working
with
tecton
we'll
still
have
to
understand
what
the
different
events
or
what
those
different
entities
they
mean.
A
So
this
is
level
o
this
comes
before.
We
standardize
the
format
of
the
events.
We
should
be
standardizing
the
type
of
events,
because
when
then
we
come
to
level
one
which
is
the
standardizing
the
format.
We
know
that
the
event
must
not
only
adhere
to
the
format,
but
it
must
also
adhere
to
the
type
it
belongs
to.
So
this
is
the
tool
level
standardization,
where
see,
because
we
have
multiple
tools,
each
tool,
different
terminologies,
similar
events
for
those
different
terminologies
or
different
concepts.
A
Some
events
made
sense
only
for
certain
tools,
so,
for
example,
if
he
had
an
artifact
built
or
an
artifact
published
event,
that
would
not
make
a
lot
of
sense
for
other
or
down
the
pipeline.
So
how
are
we
going
to
standardize
or
how
are
we
going
to
preserve
so
there's
a
lot
of
ambiguity
and
again
lack
of
compatible
terms
made
design
considerations
very,
very
expensive.
A
So
if
a
particular
sink
is
only
interested
in
artifact
build
event
from
other
tools,
how
it
will
it
will
have
to
set
filters
for
each
of
those
different
tools
because,
there's
you
know
the
event
or
the
type,
it's
not
standardized.
Everyone
may
be
representing
it
in
a
different
way
and
on
the
diagram
right
here
on
the
right
we
can
see,
even
though
you
know,
if
you
have
very
similar
tools,
job
started
or
task
runs
started,
they're
still
represented
in
different
ways,
so
bringing
in
seed
events
again.
A
This
is
where
seed
events
would
be
very,
very
helpful,
so
considering
jenkins
as
a
source.
Now
we
know
the
event
or
now
we
know
what
jenkins
should
be
or
jenkins
should
be
adhering
to
in
terms
of
the
events
that
it
is
publishing.
We
would
also
know
what
information
should
we
be
putting
there,
because
we
have
an
idea
of
okay.
Here's
how
this
this
is,
what
that
event
means,
and
this
is
how
it
should
be
consumed
and
jenkins
as
a
sink,
would
have
been
for
someone
or
a
consumer.
Anyone
who
is
consuming
those
events.
A
They
would
know
exactly
how
to
consume
it,
exactly
what
to
do
upon
it
without
needing
additional
information
about
those
tool,
specifics
or
the
tool
yeah
vocabulary.
So,
as
you
can
see
right
here,
we
have
different
terms
and
terminology,
so
we're
not
changing
that
at
the
tool
we're
just
sort
of
grouping
them
together,
so
jenkins,
job
started
or
techdown
event
task
run,
just
grouped
under
dev.ct
events.build.started,
just
adding
a
common
terminology
over
tools,
not
changing
the
terminology
of
the
tool
itself,
so
well.
B
Okay,
so
most
of
you
probably
know
me,
I'm
a
toc
member
in
the
continuous
delivery
foundation,
I'm
also
board
member
in
the
jenkins
project.
Recently
I
joined
dyna
trace
to
help
with
captain
growth,
and
currently
I
also
contribute
to
captain
project.
Quite
a
lot.
I'm
involved
to
a
few
other
initiatives
like
open
feature
for
open
source
feature
flag
management.
If
you
want,
we
can
take
calculator
about
it.
So
and
all
my
presentation
is
basically
my
own
opinion.
B
Okay,
first
of
all,
as
we
discussed
at
this
conference
and
my
other
conferences,
open
source
is
for
the
win,
as
well
as
open
source.
Centers
are
must,
if
you
want
to
achieve
interability
and
scale.
If
you
want
to
integrate
multiple
vendors
and
basically,
if
we
talk
about
open
source,
observability
ecosystems,
we
already
have
a
lot
of
standards
available.
So
there
is
a
lot
of
technologies
out
there.
Obviously
cloud
events.
B
We
already
talked
about
cd
events,
the
emerging
standards
also
open
telemetry
of
all
kinds
of
observability,
and
there
is
also
a
lot
of
open
source
tools
using
that.
So
this
is
basically
an
open
observability
standard
and
for
me,
cd
events
contributes
to
this
open
observability
system.
It's
not
just
transferring
commands
between
one
service
to
another,
but
also
transferring
insights.
What
cannot
be
passed
through
open,
telemetry,
open
telemetry
has
no
events,
but
with
cd
events.
You
can
actually
do
that
and
for
me,
for
cd
runs.
B
Of
course
we
need
to
push
forward,
we
need
to
grow
adoptions
and
I
hope
to
see
alpha
release
of
and
public
announcements
of
city
events.
Soon
from
the
technical
side,
we
are
more
or
less
ready.
So
there
is
a
lot
of
logistics
to
be
done,
also
continuity
in
the
foundation,
but
we
are
going
getting
closer
to
that
and
hopefully,
maybe
later
this
year
or
early
next
year,
we
will
be
able
to
reach
general
availability
when
all
cdf
member
projects
and
also
many
projects
outside
the
cdf
start
adopting
these
standards.
B
For
me,
city
events
is
one
of
the
key
projects
happening
in
the
continuous
delivery
foundation
now,
and
we
need
to
push
adoption
across
the
ecosystem.
So
you
have
a
few
logos
there.
These
are
just
companies
and
projects
that
already
declared
intent
to
adopt
cd
events
and
we
need
to
keep
working
to
grow
this
list,
and
once
we
have
alpha
release,
then
we
will
be
able
to
actually
make
a
lot
of
implementations
and
make
it
available
to
the
industry,
and
then
hopefully,
this
standard
will
grow
really
quickly,
so
to
keep
it
going.
B
So
this
cd
events
in
general
now
I'll
speak
a
bit
on
behalf
of
jenkins
project
and
then
on
behalf
of
the
captain
project.
So
I'm
wearing
multiple
hats
today,
but
no
real
hats.
Okay,
so
about
jenkins
yeah
many
people
say
that
jenkins
is
old.
Every
time
I
do
a
presentation
on
jenkins.
I
say
that
jenkins
is
not
old,
it
keeps
growing
and
actually
it
keeps
evolving
to
be
more
and
more
cognitive.
So
if
you
use
jenkins
in
modern
way,
probably
use
pipeliners
code,
you
use
configuration
as
code.
B
Probably
you
already
use
junk
separator
for
kubernetes
or
home
charts,
officially
supported
by
the
community,
and
also
we
have
modern
packaging
for
the
platforms
we
have.
Various
attempts
like
serverless
jenkins,
powered
by
jenkins
file
runner,
so
jenkins
keeps
evolving
to
address
modern
use
cases
and
to
be
applicable
in
the
cloud
native
world.
B
For
me,
jenkins
still
remains
an
automation
server
of
framework,
so
there
is
no
intent
to
make
jenkins
a
fully
autonomous,
ci
cd
system
for
cloud
native
space,
just
because
I
don't
believe
it
makes
any
sense
jenkins,
well
cloud
native
spaces
modeler,
and
if
you
want
to
apply
jenkins
today,
it
has
to
be
modular
too.
At
the
same
time,
if
you
want
to
have
a
modular
system,
that
is
a
unique
ecosystem,
you
need
integrations
interoperability,
and
this
is
why
investment
in
such
interability
project
was
a
key
investment
by
the
junkies
community
in
the
recent
years.
B
So
if
you
open
the
roadmap,
half
of
the
projects
somehow
target
interoperability
connecting
jenkins
to
other
systems-
and
this
is
what
was
the
main
power
of
jenkins
for
many
years
for
city
events
as
shitty
said.
Basically,
I
can
just
repeat
what
we
want
to
achieve,
so,
firstly,
we
need
to
adopt
a
cloud
events
plugin
so
that
it
becomes
cd
events,
so
it
becomes
fully
compatible
with
the
standard
once
alpha
version
is
released.
There
is
still
some
changes
here
and
there
some
terminology
terminology
alignment,
but
basically
it
requires
technical
implementation.
B
There
is
no
blockage
to
implement
it
right
now.
Also,
we
need
see
the
events
trigger
so
that
we
can
control
jenkins
from
cd
events,
and
I
think
that
we
also
need
a
generic
layer
so
that
jenkins
can
produce
arbitrary
cd
events
right
from
your
pipelines,
so
that
you
can
invoke
our
arbitrary
flows
and
use
jenkins
as
automation,
server,
which
is
flexible
and
can
be
integrated
with
any
tool.
So
this
what
for
jenkins-
and
hopefully
it
will
happen
in
the
next
year-
we
already
discussed
some
bits
in
the
community.
B
We
consider
the
gsoc
project
for
this
year,
but
maybe
we
will
start
working
in
autumn
then
captain
who's
familiar
with
captain
okay,
so
captain
is
a
data-driven
administration
tool
for
your
cloud-native
apps.
So
basically,
it's
not
automation.
Server
like
jenkins.
It
does
orchestration
and
it
sits
on
cloud
events
receives
these
events
and
acts
on
them,
including
processing
data
processing,
metrics
and
direct
and
convergence
systems,
instabilities
and
applying
autoremediation.
B
Secondly,
we
need
to
produce
cd
events
on
our
own,
because
captain
is
educated,
orchestrated
with
a
lot
of
added
value
features,
so
we
could
automatically
produce
cd
events
for
many
common
use
cases
and
this
what
needs
to
be
happening?
Last
but
not
least,
captain
itself
is
a
quite
big
modularity
system
with
a
lot
of
orchestration.
We
support
github's
management
for
captain
and,
of
course,
we
need
to
try
to
use
the
events
when
we
deploy
captain
its
models,
so
that
you
can
observe
how
captain
itself
operates
at
the
large
scale
deployments.
B
So
these
are
areas
we
need
to
apply
on
the
captain
side,
but
also
there
is
site
for
the
standard,
because,
when
city
events
started
when
event
six
started,
the
captain
community
also
started
contributing,
because
historically,
when
we
implemented
captain
when
we
sourced
it
in
2019,
there
was
already
open
specification
for
cloud
events.
We
used
called
captain
events.
B
This
specification
is
very
simple
it
you
can
see
key
events
on
the
right
and
actually,
during
the
discussions,
some
of
the
beats
formats
have
been
already
contributed
to
cd
events.
Now
we
actually
need
to
do
opposite
to
adopt
what
is
now
in
city
events
to
align,
but
one
topic
we
observe
in
captain
is
that
there
are
many
event
types
for
application,
management
and
orchestration
which
began
cicd
events.
B
So
what
I
would
like
to
see
as
capital
maintainers
is
that
these
events
also
become
standardized
so
that
it's
not
something
we
maintain
and
implement
for
any
system,
but
something
that
everyone
can
adopt
easily
and
for
that,
for
example,
sending
sli
slows.
So
if
you
work
with
set
reliability,
if
you
have
violations
for
your
target
metrics,
it
would
be
nice
to
have
these
events.
B
Also,
common
monitoring
alerts:
it's
not
in
city
events,
standards
at
the
moment,
evaluations
if
you
want
to
do
quality,
gigs
or
the
specific
bits
in
your
pipelines
and,
of
course,
any
kinds
of
release
and
rollback
variations,
which
is
again
not
a
part
of
continuous
delivery.
But
it's
a
part
of
deployment
and
it's
only
partially
represented
in
cd
events
at
the
moment.
B
So
it's
also
something
that
we
could
adopt
and
we
were
talking
about
having
it
open
source
and
basically
generalizing
it
as
a
standard,
maybe
as
a
part
of
cd
events
standard
as
a
next
iteration
of
that
or
maybe
creating
a
new
standard
within
the
cdf.
So
it's
subject
for
the
discussion,
but
this
is
something
I
would
like
to
see
in
the
project
happening.
B
So
this
is
what
we
have
for
captain
and
jenkins
and
just
again
thanks
everyone.
So
thanks
siggins
all
contributors,
thanks
shorty
for
this
plugin
and
for
a
lot
of
feedback
we
get.
We
got
an
early
stages
of
the
project
and,
of
course,
thanks
to
all
the
jenkins
and
captain
contributors,
wholes
made
the
implementations.
B
So
a
key
takeaway
is
from
me
for
you,
so,
firstly,
city
events
is
a
great
opportunity
for
the
cd
ecosystem
for
the
continuous
delivery
foundation
and
we
need
to
keep
pushing
forward.
So
if
you
contribute
to
the
cdf
or
if
you
want
to
make
your
projects
more
open,
you
can
see
the
cd
events
and
try
adopting
them.
Then,
for
us,
it's
a
joint
interest.
There
is
a
type
between
member
projects
and
companies,
so
we
believe
that
everyone
should
be
contributing
and
if
there
is
benefit
for
you,
you're
welcome
to
join
the
community.
B
It's
fully
open
source
on
slack
so
andrea,
already
shared
the
links
and
you're
welcome
to
join
us.
Yeah
jenkins.
The
captain
plan
adopted
cd
events
earlier,
so
we
are
not
going
to
wait
until
the
ga
availability.
So
hopefully
we
will
get
another
feedback
from
the
field
while
implementing
the
standard
and
again,
if
you
want
to
basically
have
a
seat
at
the
table
to
contribute
to
the
standard.
B
Okay
for
today,
if
you
do
some
discussions,
just
a
few
items,
so
whomever
discusses
announcements
and
adoption
strategy,
it's
something
you
could
do
as
a
thc
as
a
cdf
team,
we
are
still
accepting
various
marketing
quotes.
So
if
you
want
to
share
something
for
cd
events,
announcements,
please
contact
the
email
or
andrea.
We
can
add
you
to
the
list.
Also,
the
cdftc
dedicated
ten
thousand
dollars
budget
for
evolution
of
cd
events.
So
basically
it
means
that
we
can
run
two
or
three
programs.
B
Let's
say
this:
lfx
mentorship
targeting
city
events,
ecosystem
like
documentation,
reference,
implementations,
sdks
whatever
whatever
and
to
make
it
happen.
We
need
mentors
and
we
need
contributors.
So
if
anyone
in
this
audience
wants
to
participate,
please
reach
out
to
me
and
they
would
be
happy
to
work
with
you
so
that
we
get
these
programs
running,
because
these
internship
programs
actually
help
a
lot
for
the
ecosystem
again.
The
example
of
shorty
and
her
project
and
thanks
a
lot
also
application
life
cycle
events.
B
C
D
Yeah
hi
very
nice
presentation.
Thank
you.
One
question
about
the
storage
station
things.
What
you
you
mentioned
in
your
presentation
that,
like
the
the
things,
do
not
need
to
understand
the
specifics
of
the
of
the
events,
but
still
we
need
to
standardize
the
event
type.
So
I
see
that
there
is
at
least
for
me
there
is
a
contradiction
in
in
in
death.
So
how?
A
A
Okay,
let
me
maybe
switch
back
and
look
here
so,
for
example,
if
the
sink
is
looking
for
a
specific
like
a
bill
start
that's
what
the
sync
is
going
to
res
like
that's
what
the
sync
is
interested
in
receiving
only
events
of
the
type
build
started
right,
so
obviously
the
sync
if
it
has
to
pull
some
information
from
the
event,
it
still
would
have
to
understand
that
you
know
like
if
we
are,
we
are
talking
right
now
right,
so
we're
using
a
standard
language.
We,
like
both
understand
like
english.
You
both
understand.
A
Okay,
here's
what
this
person
means,
but
in
order
to,
if
you
ask
me
a
question
I'll
still
have
to
sort
of
like
think
about
it
and
answer
it
I'll
still,
so
the
the
sink
still
will
have
to
process
that
information,
but
it
does
not
need
anything
externally
to
understand.
Okay,
well,
this
tool
is
sending
me
a
bill
started.
What
does
this
mean
and
the
for
the
source?
That
is
sending
that
event.
It
does
not
have
to
conform
to
like
it's
not
specific
to
that
particular
tool.
It's
just
a
bill
started
event.
A
B
It
also
was
mentioning
that
if
we
talk
about
modern
cicd
systems,
it
the
the
pipeline
itself
doesn't
have
to
exist
within
a
single
system.
So
once
cd
events
and
other
standards
actually
evolve,
it
means
that
the
same
pipeline
can
be
distributed
between
multiple
systems.
So
you
could
be
replacing
pipeline
context.
B
Similarly,
how
you
do
with
open
telemetry
between
projects
and
then
so,
then
it
becomes
essential
to
have
this
standard,
but
on
the
other
hand,
it
doesn't
really
matter
for
you
as
cic
engineer,
which
pipeline
engine
is
used
within
your
pipeline,
because
once
you
have
a
centralized
system,
you
just
have
this
system
and
yeah.
This
is
a
key
challenge
for
unification,
because
right
now,
even
in
jenkins,
we
cannot
really
agree
on
some
bits
of
the
terminology
and
hopefully
we
will
get
there.