►
From YouTube: SIG Events: Using CloudEvents to Create an Interoperable CI/CD Ecosystem - Andrea Frittoli, IBM
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG Events: Using CloudEvents to Create an Interoperable CI/CD Ecosystem - Andrea Frittoli, IBM
With more organizations adopting a Cloud-Native architecture and microservices, continuous delivery has evolved from mere best practices to an indispensable tool to swiftly and reliably bring new features in front of customers. The CI/CD landscape is rich and diverse, with tools like Keptn, Flux and Argo that offer opinionated solutions to specific problems. Organizations rely on various ones to address their automation requirements, but they lack a way to consistently orchestrate, monitor and measure their overall workflow. There is a real need for interoperability and standardization in the CI/CD space: solving this problem is the mission of the Events Special Interest Group at the CD foundation. The speakers will present their work at the SIG in establishing a shared dictionary and set of CloudEvents, a “lingua franca” for tools to understand each other and collaborate to solve a wide range of scenarios. They will demonstrate using shared events to let existing tools work together.
A
A
A
A
A
A
A
So
maybe
we
can
use
events,
but
we
need
some
kind
of
standardization
inside
the
city
foundation.
There
are
several
special
interest
group
and
one
of
them
is
focused
on
events.
The
events
sag
this
group
was
born
to
define
a
shared
vocabulary
about
ci,
ncv
and
software
supply
chain
and
soft
life
cycle
in
general.
A
A
We
are
also
developing
a
go
sdk
for
clients
to
consume
and
produce
cloud.
Events
related
to
continuous
delivery
and
more
languages
are
coming.
Our
goal
is
to
avoid
the
need
for
one-to-one
integration
between
each
tool
so,
rather
than
using
synchronous,
prescriptive
apis,
we
just
rely
on
descriptive
events.
We
share
semantics
across
projects
to
create
a
shared
vocabulary,
is
quite
hard,
as
every
project
and
initiative
will
define
their
own
terms,
concepts
and
semantics.
A
We
focused
on
four
logical
buckets
for
our
events.
Each
of
this
packet
encapsulate
a
set
of
entities.
The
core
packets
contains
pipelines
and
tasks
which
are
quite
common,
well
understood,
and
there
are
many
implementation
of
pipeline
engines
out
there.
The
source
code
version
control
bucket
is
all
about.
Where
do
we
store
source
code
and
how
do
we
manage
changes?
A
A
A
A
Events
can
help
us
to
understand
and
externalize
what
tools
are
doing
and
provide
a
very
decoupled
way
of
creating
integration.
By
listening
to
these
events
and
reacting
to
them,
we
are
defining
the
vocabulary
in
an
event
format,
meaning
that,
instead
of
creating
entities,
we
want
to
represent
things
that
happen
to
those
entities.
A
A
A
A
A
We
wanted
to
avoid
creating
this
very
specific
integration
point
and
that's
exactly
where
the
cd
events
play
a
very
important
role
in
this
demo.
You'll
see
free
open
source
project
in
action.
Tagnon
is
a
cicd
pipeline
engine
that
extends
kubernetes
with
a
concept
of
pipelines
and
tasks.
Technon
is
very
known:
opinionated.
That
means
that
you
can
create
any
kind
of
pipeline
to
do
really.
Whatever
you
want
to,
it
doesn't
need
to
be
related
to
releasing
or
delivering
your
version
of
services
with
tactile.
A
Tecton
can
listen
and
emit
cloud
events,
but
its
own
format.
Captain,
on
the
other
hand,
is
a
much
more
opinionated
tool
to
do
life
cycle
management
of
our
cloud
native
application.
It
basically
allows
us
to
orchestrate
different
tools
to
cover
common
use
cases
when
we
are
building
and
delivering
cloud-native
application.
A
A
Captain
has
very
interesting
features
that
are
possible
because
captain
keeps
tracks
of
the
context
this
orchestration
between
different
tools.
So
it
has
all
the
context
that
it
needs
to
do,
for
example,
quality
gates
before
deploying
new
version
and
auto
remediation
policies.
That
will
kick
in
when
things
go
wrong,
while
canadian
eventing
is
not
a
core
part
of
the
demo,
we
are
using
it
because
it
provides
the
right
abstraction
to
route
cloud
events
between
services.
A
A
So
if
you
put
everything
together,
this
is
how
the
overall
demo
scenario
looks
like
so
on
the
left
top
left
side
with
tacton,
with
support
for
in
and
out
events,
we
developed
the
tecton
cloud
events
controller
specifically
for
sending
cd
events
on
the
right
hand,
side.
We
have
captain
the
blue
box,
which
also
supports
input
and
output
cloud
events,
and
we
developed
two
translation
layers
within
captain
to
translate
between
cd
events
formats
into
the
captain
on
formats.
A
Finally,
on
the
bottom
layer,
you
you
see,
we
have
view,
monitor,
measure
layer
and
for
the
demo
we
have
we're
using
the
cloud
events
player
that
is
able
to
visualize
events
that
are
sent
and
triggers.
I
use
them
to
subscribe
to
events,
so
the
montagne
captain
or
a
plot
events
player
want
to
receive
events,
so
they
create
a
trigger
or
subscription
and
they
can
select
which
events
they
want
to
receive
cloud
events
player
will
receive
all
the
events,
so
the
flow
of
the
demo
goes
like
this.
A
A
There
is
a
new
package
that
has
been
produced
and
your
artifact
that
has
been
produced,
so
we
want
to
deploy
it.
So
it
starts
a
deployment
sequence
and
it
sends
events
about
this
because
captain
is
not
actually
doing
the
deployment
itself.
The
event
about
deployment
starting
is
picked
up
by
tekton.
That
runs
the
deployment
pipeline.
Once
it's
finished
again,
it
will
send
a
notification
and
events
about
deployment
done,
and
this
is
picked
up
by
captain
and
used
to
finish
the
sequence
right.
But
let's
see
this
in
action
now.
A
A
A
A
A
So
in
the
curtain
bridge
we
see
spsc
service
in
the
production
environment.
There's
a
question
mark.
So
if
we
click
on
it,
we
see
that
we
have
a
sequence
that
has
been
started:
delivery.
The
way
we
set
it
up
for
the
demo,
there
is
a
manual
approval
required
before
the
deployment
is
complete.
So
let's
go
back
for
a
moment
to
our
diagram
and
you
can
see
techno
executed
the
build
an
event
was
sent
here.
A
A
A
A
Right,
so
these
are
where
the
results
and
it's
the
b42a
ending
with
four
nine
to
d5.
So
yeah,
that's
what
we
want.
So
let's
approve
this.
We
want
to
deploy
it
so
now
captain
is
not
going
to
do
deployment
itself,
but
it's
starting
a
deployment
sequence
sending
an
event
which
is
then
picked
up
by
tecton,
and
you
see
the
deployment
here
is
marked
as
handled
by
tecton.
A
Here
are
the
events,
queued
started
and
finished,
and
once
tecton
is
finished,
doing
the
deployment
it
sends.
The
cd
service
deployed
event,
which
contains
all
the
details
about
the
pipeline
run
that
was
executed
as
well
as
service
environment,
id
service,
name
and
service
version
service
name.
Poc
here
matches
what
we
have
on
captain
site
and
the
service
version
is
the
version
of
the
deployment
we
can
actually
go
and
look
into.
A
So
right
now,
these
are
sent
as
part
of
the
body
of
the
events
in
the
cd
events
protocol.
But
this
is
something
that
we're
working
on
for
future
version
of
the
protocol.
We
want
to
have
a
general
facility
for
different
applications
to
transport
application,
specific
context
and
information
that
might
be
required,
so
that
can
be
done
in
both
generic
as
well
as
plugable
way
by
the
different
application
in
the
protocol.
A
And
that
was
our
demo
and,
as
I
mentioned
earlier,
there
are
a
lot
of
activities
that
we
are
performing
at
the
siege
events
from
producing
the
spec,
as
well
as
developing
the
sdks
and
tooling
around
and
building
pse
that
you've
just
seen
in
action.
So
if
you're
interested
in
contributing,
please
join
the
sig
events
channel
on
the
cdf
slack,
we
hold
bi-weekly
meetings
for
the
sig
events
and
as
well
by
with
meeting
specific
to
the
vocabulary,
work
and
yeah
their
contribution.