►
Description
Mauricio Salatino (CDF) will join us at this Keptn User Group meeting to present how interoperability between CI/CD systems can be achieved by defining a common language based on cloud events. He will demo a PoC that allows to bridge the gap between different CI/CD systems on the example of Tekton and Keptn and make them interact with each other on a common set of events that both systems are able to interpret and act upon.
📖 Slides: https://drive.google.com/file/d/1evjiK9I1ErWXB99k4LeDQy2qmnduqMzm/view?usp=sharing
💻 Proof of concept: https://github.com/cdfoundation/sig-events/tree/main/poc
⏱️ Timecodes
00:00 Intro
02:00 Presentation
16:00 Demo
39:08 Q&A
Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
A
B
A
Yeah
say
for
me
and
just
a
a
quick,
a
quick
heads
up
so
captain
as
a
cncf
project.
We
are
following
you
the
cnc
code
of
contact,
so
please,
please
be
nice
to
each
other.
In
this
meeting
the
q
a
is
open.
The
chat
is
open,
feel
free
to
ask
questions.
I
will
then
just
kind
of
yeah
ask
these
questions
to
maurizio
during
the
presentation
or
at
the
end
of
the
presentation.
However,
where
they
fit
best,
the
whole
presentation
is
also
going
to
be
recorded.
A
You
will
find
it
later
on
on
captain.sh
and
also
on
our
youtube
channel,
and
you
will
also
find
all
the
other
captain
user
group
meetings
on
captain.sh
or
on
the
youtube
channel
and
just
as
a
as
some
information
for
you,
there
will
be
the
next
user
group
meeting
then
again
also
in
september,
with
a
story
from
a
captain
adopter
and
for
today
I
think,
I'm
already
handing
over
to
maurizio.
We
will
have
a
look
at
what
he
came
up
with.
A
B
Sounds
great,
let
me
share
my
screen
then,
and
let's
get
started
so
yeah,
as
jurgen
mentioned,
I
will
be
talking
about
interoperability
in
ci,
cd
or
interoperable
ci,
cd
ecosystems,
basically,
and
the
title
of
the
presentation.
It's
definitely
aimed
towards
kind
of
like
sharing
some
of
the
work
that
we
have
been
doing
in
the
continuous
delivery
foundation.
B
But
first
let
me
introduce
myself.
My
name
is
maurice
salatino,
I'm
at
salahu
in
twitter
and
I'm
also
working
as
a
staff
engineer
for
vmware
and
inside
vmware.
I'm
working
for
a
project,
that's
called
k
native.
Some
of
you
might
know
that
project,
it's
pretty
popular
in
the
you
know
in
the
kubernetes
ecosystem
as
well,
and
I
will
be
talking
a
little
bit
about
that
during
the
presentation.
B
I
believe
that
the
main
reason
why
I'm
doing
this
presentation
here
is
because
I
joined
the
continuous
delivery
foundation
a
couple
of
years
ago
when
it
was
created
and
since
then
I've
been
working
with
different
teams,
different
companies
and
different
open
source
projects
towards
trying
to
understand
how
kind
of
like
we
can
create
a
space
where
projects
can
go
and
can
share
ideas.
And
can
you
know
start
integrating
to
create
like
a
better
like
ci
and
continuous
delivery
ecosystem
in
general?
B
If
you
don't
know
about
the
foundation,
I
totally
recommend
you
to
check
out
this
website,
because
you
know
again,
if
you
are
into
cicd
or
devops
or
githubs.
This
is
a
the
perfect
place
to
go
there
and
you
know
share
your
experiences,
contribute
to
different
open
source
projects
and
you
know
and
keep
learning.
Basically
inside
the
cd
foundation,
there
are
like
different
special
interest
groups,
that's
where
the
sigs
are,
and
they
are
focused
in
doing
different
kind
of
like
research
or
experimentation
or
building
you
know,
integrations
between
different
projects.
B
I
joined
one
of
these
sigs
one
of
these
special
interest
groups
that
it's
called
events
and
in
this
specific
group
we
are
focused
on
creating
a
common
vocabulary
for
continuous
delivery
and
all
the
terms
and
all
the
entities
that
are
related
to
continuous
delivery.
It
is
a
very
ambitious
task
to
achieve.
It
is
pretty
difficult
to
come
up
with
a
list
of
terms
that
will
apply
to
every
like
to
all
the
projects
that
are
out
there
being
built
right
now,
but
I
think
that
we
can
start
simple.
B
We
started
simple
with
a
bunch
of
core
terms,
and
then
we
started
building
on
top
of
that
and
the
the
main
thing
is
we,
you
know
just
expose
these
terms,
this
vocabulary
and
we
try
to
get
feedback
from
different
projects.
That's
why
I'm
presenting
here
in
the
captain
meetup
and
we
just
iterated
right
the
main
idea
of
reading
kind
of
like
this
vocabulary.
B
So
we
have
been
doing
some
research,
but
because
we
are
like
very
practical
people,
we
decided
to
start
building
pocs
like
proof
of
concepts
and
examples
and
some
tools
in
order
to
materialize
kind
of
like
this
dictionary
of
terms
and
the
vocabulary
itself,
and
we
also,
we
quickly
realized
that
the
best
way
for
us
to
start
is
to
focus
on
events.
So
we
have
entities.
B
I
will
be
talking
a
little
bit
about
the
entities
and
the
and
the
concepts
that
we
are
dealing
with
right
now,
but
we
also
need
to
see
tools
and
these
tools
are
usually
exchanging
events.
So,
instead
of
saying
okay,
we
will
just
create
you
know
apis
and
bridge
between
apis.
We
said:
okay,
we
can
observe
systems.
We
can
extract
the
events
that
are
happening
in
these
systems.
B
We
also
enable
all
these
other
use
cases
that
are
more
related
with
observability
and
monitoring
and
orchestration
right,
like
only
based
on
events,
so
we
set
up
kind
of
like
a
list
of
things
that
we
wanted
to
deliver
as
part
of
this
work
as
part,
but
as
part
of
this
group,
the
first
one
was
like
this
protocol.
Agnostic
vocabulary
right,
like
that's
the
specification
that
we're
working
on
that
you
can
find
in
github.
B
I
can
just
share
the
links
as
well,
and
on
top
of
that
specification,
we
are
building
tools
again,
like
sdks
and
frameworks
that
will
allow
you
to
create
these
events
and
emit
these
events
and
also
parse
these
events
and
read
them
in
different
languages.
But
it
cannot
be
complete.
I
mean
creating
these
tools,
it's
pretty
difficult.
B
So
a
shared
vocabulary
right,
like
the
vocabulary
that
we
are
working
on.
It's,
as
I
mentioned
before,
it's
just
a
set
of
entities
that
we
believe
that
are
pretty
common
in
you
know
in
most
of
the
cic
cd
tools
that
are
out
there
like
in
the
community
right,
like
all
the
other,
all
the
open
source
projects
and
also
the
private
projects.
They
are
pretty
much
doing
similar
things
and
they
are
kind
of
like
defining
similar
concepts,
sometimes
with
different
names,
but
at
like
the
conceptual
level
they
are
kind
of
like
pretty
similar.
B
So
we
started
by
defining
like
four
different
core
packets,
as
we
call
them
right
like
they
are
like
just
bag
of
concepts.
We
have
one
bucket
that
is
called
core.
We
believe
that
pipelines
and
tasks
are
quite
common
and
well
understood
entities
for
concepts
that
you
know
in
a
ci
in
a
continuous
integration
environment,
almost
everybody
that
is
aware
of
continuous
integration
will
understand
what
a
pipeline
and
what
the
task
is
on
the
source
code
version
control
bucket.
We
have
repositories,
branches
and
changes
for
something
like
you
know.
B
B
We
are
going
to
be
testing
that
something
and
we
are
going
to
probably
creating
artifacts
from
you
know
from
from
our
software
that
we
are
building
basically
and
finally,
the
last
one,
which
is
a
little
bit
more
related
to
cloud
native,
because
the
vocabulary
at
the
beginning,
it
was
pretty
abstract
and
not
related
to
any
specific.
You
know
environment,
but
the
continuous
deployment
it's
a
little
bit
more
related
to
cloud
native
deployments
right
where
you
have
environments,
maybe
applying
githubs.
On
top
of
that,
and
you
are
basically
deploying
services
right.
B
This
is
a
little
bit.
You
know
this
is
the
entities
that
we
are
trying
to
tackle
in
the
first
iteration
of
this
vocabulary.
It's
not
the
full
list,
but
this
is
mainly
where
we
are
focusing
right
now,
because
we
wanted
to
show
that
this
can
be
applied.
You
know
in
real
life
systems,
of
course,
if
you're
building
embedded
systems,
then
you
can
just
go
and
say:
okay,
I
just
want
to
choose
the
continuous
integration
bucket
and
I
will
only
use
these
entities
it
doesn't
need.
B
It
doesn't
mean
that
you
need
to
adopt
everything
or
nothing
right
like
you
can
just
go
pick
and
choose
which
concepts
are.
You
know
interesting
for
your
use
case
and
then
just
use
whatever
you
want
and,
as
I
mentioned
before,
we
have
the
entities
but
we're
not
focusing
in
the
entities
themselves.
We
are
focusing
on
systems
that
are
emitting
events
about
these
entities
right
and
an
event.
It's
basically
a
data
record
expressing
that
something
happened
with
a
like.
A
very
well
specified
context
right.
B
So
if
you
look
at
any
of
the
systems
that
are
building,
you
know
our
software
nowadays,
you
will
see
that
you
know
the
pipe
like
pipeline
has
started
event.
You
know
an
artifact
has
been
published
in
the
event
or
when
you're
going
github
on
creative
ranch.
Github
is
actually
emitting
an
event
that
it's
you
know
the
branch
was
created,
so
you
can
tap
into
these
events
and
then
do
stuff
and
automate
things
together
by
looking
at
these
events.
B
So
for
each
of
the
entities
that
I
mentioned
before,
we
have
defined
a
set
of
events
that
we
are
expecting.
You
know
tools
to
create
and
to
emit
and
at
the
same
time
we
are
planning
to
use
these
events
to
make
other
tools
to
understand
what
you
know.
The
first
tool
was
doing
and
to
be
able
to
react
on
it
and
also
to
be
able
to
send
events
back
to
that
tool
and
say:
okay,
you
started
the
pipeline
and
I
deployed
the
service.
B
Again
as
I,
as
I
mentioned
before,
we
have
decided
to
build
something.
We
wanted
to
show
that
you
know
tools
can
interoperate
by
using
this
common
vocabulary
that
we
are
creating
and
this
common
vocabulary
that
it's
basically
defining
events.
So
we
looked
into
some
of
the
you
know,
projects
that
are
pretty
popular
like
tecton,
which
is
a
pipeline
engine,
that's
cloud
native.
It
runs
on
top
of
kubernetes,
it
does
a
bunch
of
nice
things.
B
They
were
already
using
cloud
events
for
defining
their
own
tecton
events
for
when
pipelines
were
created
and
all
these
things
we
looked
into
captain,
which
is
very
event-driven.
I
will
be
talking
a
little
bit
about
that
later
on
and
also
because
I
work
at
canadia,
but
also
because
knativ
is
pretty
good
at
like
dealing
with
cloud
events
and
routing
cloud
events.
We
included
cloud
like
eventing
into
the
demo
as
well.
B
We
are
expecting
to
be
able
to
replicate
this
demo
that
I
will
be
showing
with
all
the
tools
as
well,
and
I
know
that
you
know
other
people-
it's
working,
for
example,
on
the
jenkins
project,
to
be
able
to
emit
cloud
events.
So
as
soon
as
we
have
something
that
can
emit
cloud
events,
we
can
start
integrating
these
tools
by
using
this
shared
vocabulary.
B
So,
as
I
mentioned
before,
tecton
is
like
a
cloud
native
pipeline
engine
that
allows
you
to
define
pipelines
with
tasks
inside
it
allows
you
to
do
that
by
defining.
You
know,
kubernetes
resources
that
basically
contains
the
pipeline
definition.
It
provides
that
declarative
approach.
So,
if
you're
in
the
kubernetes
ecosystem,
it's
pretty
easy
to
get
used
to
tecton
and
to
you
know,
basically
define
the
pipelines
that
can
do
whatever
you
want.
B
It's
pretty
lightweight
the
way
that
it's
being
built,
it's
been
built
to
scale
by
using
the
kubernetes
constructs
and
and
that's
pretty
nice
when
you're.
When
you
are
in
that
ecosystem,
it
is
really
not
opinionated
in
the
sense
that
it
gives
you
some.
You
know
some
concepts
like
pipelines
and
tasks,
but
you
can
create
any
kind
of
pipeline
that
you
want
right
like.
If
you
want
to
you
know,
build
embedded
systems
again,
you
can
just
build
them
there
and
then
release
them
to
multiple
architectures.
B
B
Basically
captain.
In
the
other
hand,
it's
a
life
cycle.
You
know
management
tool
for
cloud
native
applications.
It
allows
you
to
do
like
orchestration
of
tools
related
with
ci,
as
with
ci
and
cd
as
well.
It's
even
driven
by
by
nature
right.
It's
it's,
basically
an
event-driven
like
state
machine
that
allows
you
to
orchestrate
different
tools
together,
which
is
pretty
nice
and
again
because
it's
heaven-driven
it
kind
of
like
fit
pretty
nice
to
the
story
of
the.
B
You
know
the
sig
events
kind
of
like
group
and
that's
why
we
just
started
looking
into
it
and
we
decided
to
go
ahead
and
create
like
a
poc
with
this
and
it.
Of
course,
it
adds
a
lot
of
value.
On
top
of
you
know,
on
top
of
normal
tools
that
you
will
use
inside,
like
you
know
your
ci
pipelines
and
your
delivery
pipelines
by
just
adding
quality
gates
and
remediation
that
I'm
not
showing
here
in
this
demo
today,
but
I'm
really
looking
forward
to
start
adding
these
kind
of
things
to
show.
B
B
So
let's
take
a
look
at
the
demo,
so
in
the
demo
I
will
be
showing
a
local
setup.
It's
running
on
my
laptop
on
on
kubernetes
kind,
so
I
have
a
kubernetes
kind
instance.
I
have
kept
on
installing
that
cluster.
I
have
tecton
installing
that
cluster.
I
have
k
native
installed
in
that
cluster,
so
my
computer
is
it's
pretty
loaded
and
a
big
shout
out
here
to
andrea
fritoli
from
from
ibm
black
chipping
twitter,
who
worked
a
lot
in
this.
B
B
So
imagine
that
you're
working
in
a
company
and
you
have
a
pipeline
to
build
a
service
like
an
application.
Let's
say
that
it's
a
web
application,
so
you
know
that
that
pipeline,
if
will
basically
basically
go
and
fetch
the
source
code,
build
the
the
source
code
depending
on
the
language
that
it's
been
built.
You
need
to
have
the
tools
to
build
that
source
code.
Then
you
need
to
create
a
docker
container.
B
If
you
want
to
run
inside
kubernetes
and
then
you
basically
need
to
package
that
and
publish
that
somewhere,
so
you
can
actually
run
that
in
a
remote
kubernetes
cluster.
As
soon
as
you
have
that
that
you
know
artifact,
then
the
next
step
is
usually
to
trigger
a
deployment
and
in
order
to
deploy
that
you
basically
need
to
choose
in
which
environment.
Do
you
want
to
deploy
that
artifact?
How
to
deploy
that
artifact?
And
for
that
we
have
another
tecton
pipeline
defined.
That
basically
can
do
that,
but
we
wanted
to
so.
B
The
developers
that
created
those
pipelines
doesn't
want
to
actually
run,
for
example,
these
pipelines
in
their
own
environments.
They
need
another
team
that
basically
define
what
needs
to
happen
for
those
things
to
be
deployed,
for
example
in
a
production
environment
right
and
for
that
they
have
defined
a
captain
sequence
that
basically
are
going
to
orchestrate
these
pipelines
right
in
order
to
basically
orchestrate
that
delivery
process,
so
that
sequence
basically
will
include
some
kind
of
some.
B
So,
in
this
space
very
simple
use
case,
where
we
build
software,
then
we
have
another
team
that
is
in
charge
of
deploying
the
software
or
at
least
authorizing
the
deployment
of
the
software.
We
have
two
different
tools
again
like
captain
and
tecton.
That
needs
to
be
used,
and
we
want
our
teams
to
be
able
to
interact
right
like
and
to
interoperate
and
to
be
able
to
use
these
tools
together
in
a
very
natural
way.
B
So
we
started
with
these
two
two
tools
right
like
and
these
two
tools.
They
come
with
different
components
inside
right
and,
as
I
mentioned
before,
they
both
understand
about
what
cloud
events
are,
but
they
are,
they
both
are
defining
their
own
cloud
events
right
like
so.
We
have
captain
cloud
events
in
captain
side
and
we
have
tekton
cloud
events
in
the
tecmon
side
right.
B
They
do
not
understand.
They
do
not
understand
each
other
right
like.
If
we
want
to
build
an
integration
between
these
two
tools,
we
will
need
to
create
some
kind
of
translator
right
like,
and
it
needs
to
be
bi-directional
right
like
let's
say
that
tecton
is
sending
tecton
events,
we
will
need
to
pick
the
tecton
events
and
then
translate
to
captain
events,
so
captain
can
understand
what
tekton
is
doing
and
then
just
do
something
about
it
right
and
if
you
want
to
do
it,
the
other
way
around
like
captain,
is
doing
something.
B
For
example,
it's
requesting
a
deployment
and
that
deployment
is
is
implemented
by
a
tecton
pipeline.
We
will
need
to
be
able
to
take
that
captain
event
and
translate
it
to
tecton,
so
they
don't
know
what's
to
do
with
it
right
and
the
problem,
then
that's
that,
of
course,
that
can
be
done.
Like
that's
integration,
basically
like
system
integration,
there
are
tools
to
do
that,
but
it
becomes
really
project
specific
right.
B
If
imagine
that
now
you
have
jenkins-
or
you
have
another
tool
that
you
want
to
use,
then
you
will
need
to
build
another
directional
translator
for
that
extra
tool
right
and
the
more
tools
you
have
in
the
ecosystem.
We
all
know
that
in
ci
cd,
if
you
go
and
take
a
look
at
the
cncf
and
the
cd
foundation,
you
will
see
that
there
are
tons
of
different
tools
right.
If
you
want
to
build
one
integration
for
each
pair
of
tools,
then
you
will
end
up.
You
know
spending
three
four
years,
writing
integrations
only
right.
B
So
what
the
next
thing
that
you
can
do
is
basically
it's
just
have
a
common
vocabulary
like
that,
the
one
that
we
are
defining
right
like
this
continues
delivering
events
that
we
are
creating
inside
this
group
and
then
we
can
create
a
single
translator
for
each
of
these
tools
right
and
then
we
can
just
let
them
interact
right
and
that's
pretty
much
what
we
did
so
we
created.
You
know
like
something
for
tecton
like
a
component
for
tecton
that
it's
going
to
emit
this.
B
You
know
common
vocabulary,
events
and
we
created
something
for
captain
that
it's
going
to
understand.
You
know
this
common
vocabulary
and
also
emit
events
from
that
vocabulary.
Right
and
those
are
the
components
that
we
have
here
right.
So
we
have
tekton
cloud
events
that
it's
an
extension
to
tecton
that
basically
knows
when
to
emit.
You
know
these
common
vocabulary,
events
and
you
can
imagine
because
it's
a
pipeline
engine,
we
are
going
to
be
emitting.
You
know
pipeline
started
events,
we
will
be
emitting,
you
know,
artifacts,
published
events
and
maybe
service
deployment.
B
We
hope
in
the
group
that
at
some
point,
when
the
vocabulary
is
mature
enough,
you
know
tools
are
going
to
start
using
that
inside
kind
of
tools
themselves.
Instead
of
just
using
extensions
to
these
tools,
we
are
very
positive
that
that's
going
to
happen,
but
we
need
to
keep
re
reiterating
the
event
formats
and
the
content
of
the
events,
so
they
become
more
useful.
B
For
you
know
a
wide
range
of
tools
when
you
are
in
this
situation,
right
like
when
you
already
have
you
know
a
common
vocabulary
and
the
components
that
are
emitting
and
consuming
this.
You
know
new
cloud
events
format.
Then
you
start
wondering
about
okay.
What
transport
do
you
use
right?
Another
thing
that
we
wanted
to
avoid
doing
in
the
demo
is
to
send
events
from
tekton
straight
to
captain
right
because
again,
that
makes
it
pretty
poor
for
like
from
this
scalability
point
of
view.
B
If
we
just
send
an
http
http
request
from
one
tool
to
another,
then
we
need
to
care
about.
You
know
we're
trying
when
something
goes
wrong.
We
need
to
make
sure
that
you
know
the
services
are
available
and
they
are
like
ritual
and
all
these
kind
of
things,
and
for
that
reason
we
decided
to
use
their
like
native
eventing.
As
I
mentioned
before,
and
again,
canadian
eventing
provides
this
provide.
This
idea
of
you
know
a
cloud
events
broker.
You
know
like
a
knee
broker
by
default.
B
It
deals
with
cloud
events
and
it
routes
cloud
events
and
then,
as
I
mentioned
before,
we
created
like
these
triggers
of
subscriptions
for
for
these
tools
right,
so
the
tools.
Now
they
don't
need
to
know
about
each
other.
They
just
need
to
know
that,
where
the
broker
is
and
then
send
events
to
the
broker
and
then
based
on
the
subscriptions,
you
know
the
events
are
going
to
be
consumed
by
different
components.
B
We
know
that
whenever
there
is
a
captain
event,
we
need
to
put
it
in
the
broker
and
if
there
is
a
pipeline
listening
so
or
a
pipeline
waiting
for
an
event
to
start,
it's
going
to
be
picking
that
event
from
the
broker
and
then
just
starting
a
pipeline,
and
that's
pretty
much
what
I
will
be
showing
now
live.
But
one
more
thing
before
moving
forward
is
the
fact
that
it
is
important
when
we
are
building
this
integration.
B
You
know
ecosystems
and
when
we
are
like
making
different
tools
to
interact
and
to
interrupt
interoperate,
you
kind
of
like
start
losing
the
big
picture
of
what's
happening
right
and
again,
once
again
like
by
using
this
cloud
native
necessary
the
1080
broker.
In
this
case,
we
can
tap
into
all
events.
B
A
Yeah
thanks
for
for
explaining
everything
in
detail,
I
just
want
to
mention,
because
a
couple
of
you
already
know
about
captain
events,
and
then
we
saw
the
slide
from
from
you
maurizio,
with
kind
of
the
the
cdf
events,
so
they
are
very,
very
similar.
It's.
We
are
not
trying
to
invent
something
completely
new
here.
We
are
actually
working
together
where
we
are
kind
of.
A
We
want
to
implement
the
eventing
standard
that
that
will
be
established
by
the
cdf,
but
we
also
want
to
bring
in
our
expertise
in
other
parts
and
kind
of
to
enrich
those
events
that
there
can
be
one
eventing
standard,
inventing
definition
that
serves
all
the
different
use
cases,
and
then
we,
basically
all
the
different
tools
and
they
implement
this.
So
this
is
the
currently
they
are
not
exactly
the
same.
A
So
for
this
we
need
this
inbound
outbound
translator,
as
you
also
yeah
explained,
but
this
is
the
this
is
the
kind
of
the
reason
and
the
history
of
the
events
that
we
will
see
from
the
from
on
the
tacton
side
and
the
events
that
we
will
see
on
the
on
the
captain
side.
And
then
there
was
one
question
coming
in:
can
we
have
a
look
at
the
last
slide
that
you
just
showed?
The
question
was
directly
related
to
this.
A
This
one
yeah
related
to
the
cloud
events
player
and
the
question
was:
can
the
captain's
bridge
serve
as
the
cloud
events
player,
and
maybe
I
can
answer
this
real,
quick,
captain's
bridge,
it's
more
the
ui
for
captain
and
you
will
see
each
and
every
cloud
event
inside
of
captain
but
of
course,
all
the
other
cloud
events
that
are
not
going
to
captain
are.
You
cannot
see
them
in
captain,
so
this
is
the
reason
why
there
is
a
specific
component.
B
Yeah
yeah,
that's
that's
the
main
idea
there.
It's
like
in
each
of
the
tools.
You
probably
can
see
all
the
events
that
are
related
to
that
specific
tool.
But
when
you
start
using
multiple
tools
together,
then
you
start,
you
know
losing
kind
of
like
what's
kind
of
like
the
entire
sequence
and
captain
does
a
great
job
at
like
showing
the
sequences
and
showing
kind
of
which
events
are
being
sent
from
the
captain
perspective,
which
is
pretty
good
because
captain
was
designed
for
integration
purposes
and
for
orchestrating
multiple
tools.
B
But
you
can
see
that
you
know
tecton
wasn't
designing
that
way.
So
in
order
to
see
the
full
picture
that
you
definitely
need
to
take
a
look
at
some
kind
of
like
you
know,
at
the
broker
level
in
this
case,
but
yeah,
I'm
I'm
guessing
that
the
more
that
we
make
progress
on
the
vocabulary
like
tools
will
pop
up
to
show
all
the
you
know,
all
the
common
vocabulary,
events
and
to
aggregate
them
and
to
you
know,
have
a
really
nice
ui
showing
that
so
yeah.
B
B
You
know
interoperability
between
different
tools,
and
we
know
that
the
you
know
the
recovery
is
not
perfect,
but
that's
why
we
are
kind
of
like
iterating
it
and
just
presenting
about
it.
So
people
is
aware
and
they
can
just
go
and
bring
their
expertise
as
the
captain
thoughts
are
doing
because
they
already
built
most
of
these
events
already
they
already
have
like
you
know
one
of
these,
these
events
implemented
in
their
tools.
So
we
wanted
to
just
leverage
that
expertise
and
then
just
put
them
in
a
common
language,
as
jurgen
was
mentioned
before.
B
So,
as
I
mentioned
before,
I
have
tech
tennis
techno
installed.
I
have
captain
installed
and
I
have
the
cloud
events
player
also
like
looking
for
events,
and
as
I
also
mentioned
before,
the
scenario
was
that
I
have
two
pipelines
were
for
building
artifacts
and
the
other
one
for
deploying
that
artifact
into
an
environment,
and
I
have
captain
with
the
defined
sequence
for
basically
doing
that
deployment
right.
B
So
let
me
first
show
you
a
bit
of
the
pipeline
here
that
I
have
so
the
first
pipeline
that
basically
it's
called
bill,
artifact
it's
defined
in
tecton,
and
you
can
use
the
tecton
command
line
tool
to
just
kind
of
explore
how
the
pipeline
is
being
configured.
So
these
are
just
properties
for
the
pipeline.
Where
is
the
source
code
for
the
for
the
application
that
we
are
going
to
build?
Where
is
the
docker
file
that
is
going
to
be
used
to
create
a
container?
B
Where
should
we
push
that
container
and
what's
kind
of
like
the
version
that
we
are
going
to
create
for
for
that
application?
And
here
in
the
task
section?
Basically,
you
are,
you
can
see
exactly
kind
of
what
the
pipeline
is
doing
so
the
first
one
is
cloning,
the
repository
from
github.
It
goes
to
that
repository.
It
clones
that
specific
branch
and
then
it's
going
to
use
kaneko,
which
is
a
tool
to
build
containers
inside
kubernetes.
So
it's
going
to
basically
build
that
application
container
and
then
just
push
it
into.
B
You
know
a
container
registry
in
this
case
happening
here
inside
can
so
this
pipeline
is
pretty
straightforward.
It's
just
going
to
do
that
and
we
can
run
this
pipeline
by
just
running
this
command
that
I
can
share
as
well.
But
if
you're
running
the
poc,
you
will
see
that
as
soon
as
you
kind
of
run
the
the
script.
You
are
going
to
see
this
this
fast
last,
you
know
line
to
start
the
pipeline.
B
When
you
start
pipelines
in
tecton,
using
kind
of
like
the
command
line
tool,
you
can
parameterize
the
pipeline
using
different
values
right,
like
which
source
code.
Do
you
want
to
go
clone
and
build,
and
I
will
just
accept
all
the
defaults
here,
like
main
branch,
where
is
the
docker
file
and
and
where
to
push
the
docker
file?
Right
and
again,
that's
the
target
name
of
the
application.
B
Now
you
can
see
that
you
know
the
container
is
being
built
at
some
point.
We
should
be
able
to
see
some
some
locks
in
here
as
well
and
that's
completed,
and
now
it's
running
the
last
task,
which
is
basically
exporting
the
results,
and
I
think
that
the
pipeline
is
done
already
right,
like
so
the
pipeline
succeeded,
everything
went
right
and
one
thing
that
we
can
see
in
here.
B
Let
me
refresh
this
is
that
a
new
docker
image
called
plc
was
created
and
it
has
a
very
specific
shaft
for
this
build
and
that
sha
is
the
one
that
we
can
just
go
now
and
look
into
captain.
So,
as
I
mentioned
before,
we
just
run
a
pipeline,
that's
basically
building
an
artifact
and
we
can
see
the
events
that
were
created
by
that
pipeline
in
this
case.
B
So
again,
let
me
make
this
bigger
and
let's
see
if
the
ui
supports
that,
so
you
can
see
that
there
was
one
of
these
events
that
again
was
defined
by
the
city
foundation,
but
its
pipeline
run
cued
the
pipeline
was
cured,
the
pipeline
was
started,
the
pipeline
was
finished.
And
finally,
the
last
event
that
was
submitted
here
is
that
the
artifact
was
packaged
right,
like
it
was
packaged
as
a
docker
container.
So
we
are
emitting
that
event
and
we
have
the
captain
listener.
B
That
is
basically
looking
for
these
events
and
triggering
a
sequence
based
on
that
right.
So
now,
I'm
jumping
to
the
captain
bridge
here
and
I
have
a
production
sequence
here,
like
a
delivery
sequence
as
well,
that
basically
it's
telling
me
that
you
know
there
is
a
new
artifact
that
was
created
and
that's
the
sha
of
the
artifact
that
was
created.
I'm
sharing
now
data
with
captain
and
the
delivery
sequence
here
is
saying
that
it's
waiting
for
approval
right.
So
I
can
click
in
here.
B
There
you
go
yeah,
what's
the
typical
refreshing
yeah,
so
basically
the
pipeline,
the
sequence
in
captain
was
triggered,
and
the
first
thing
on
that
sequence
is
the
manual
approval.
Right
and
again,
we
are
here
simulating
a
team
that
it's
waiting
for
artifacts
to
be
published
and
as
soon
as
a
new
publishes,
a
new
artifact
is
published.
They
need
to
basically
validate
it
and
then
just
accept
that
they
are
going
to
promote
that
to
their
production
environment.
B
So
here
we
have
like
a
manual
approval
defined
inside
the
the
captain
sequence
and
as
soon
as
we
you
know,
hit
okay
for
this
artifact,
then
the
sequence
will
move
to
the
next
step
and
the
next
step
is
basically
doing
a
deployment.
But
captain
is
not
going
to
do
the
deployment
it's
just
going
to
send
a
cloud
event
to
tecton.
So
tecton
can
run
another
pipeline
to
do
that,
deployment
to
the
production
environment
again
showing
how
captain
can
orchestrate
you
know,
different
tools.
B
You
can
be
doing,
for
example,
the
build
with
tecton
and
then
the
deployment
with
jenkins
or
with
any
other
tools
like
you
know,
spinnaker
or
any
ci2.
As
you
can
see
here,
yep
captain
is
telling
us
that
you
know
that
it's
been
handled
by
tecton.
That
basically
means
that
another
pipeline
was
triggered
in
the
tecton
side.
B
I
can
show
you
that
here
the
deploy
artifact
pipeline
was
triggered,
and
you
can
see
here
that
there
was
a
deployment
step
and
then
just
configuring
an
ingress,
so
we
can
access
to
the
application
and
in
captain
it
also
provides
this
really
nice
link
here
that
we
can
click
and
access
the
application
right
and
again,
a
big
shout
out
to
andrea
for
building
this
kind
like
a
simple
application,
and
you
can
see
that
he
was
presenting
here
in
an
ibm
conference
as
well.
So
that's
really
cool.
B
So
this
is
the
application
that
it's
up
and
running
in
our
production
environment
and
that
was
deployed
by
captain,
but
it
was
orchestrated
so
it
was
deployed
by
tecton,
but
it
was
orchid
orchestrated
by
the
delivery
sequence
in
captain
which
require
the
manual
approval.
Basically,
at
the
beginning
again,
if
I
go
to
the
cloud
events
player
here
and
I
refresh
and
zoom
out
a
little
bit
less
here,
you
can
see
that,
after
the
artifact
package,
the
event
that
was
sent
by
the
first
pipeline,
then
we
have
captain.
B
You
know
saying
that
there
is
a
new
artifact
being
published
and
that
created
like
a
new
like
it
triggered
a
new
pipeline
in
tecton
that
was
started.
It
deployed
a
new
service,
so
we
have
service
deployed
event
because
we
have
our
application
up
and
running
in
the
production
environment,
and
then
the
pipeline
finished
right
and
that's
pretty
much
what
I
wanted
to
show
today.
I
know
again
it's
a
complex
interaction
between
different
tools,
but
think
about
this.
B
B
This
is
quite
common,
but,
like
you
will
not
just
choose
a
single
tool
and
just
do
everything
with
it,
so
we
just
choose
the
best
tool
for
each
of
the
things
that
you
need
to
do,
and
then
you
will
hope
to
be
able
to
make
them
all
work
together
and
place
play
nice
for
now.
We
believe
that
this
is
really
promising
and
we
will
keep
working
on
this
vocabulary
and
we
really
appreciate
you
know
the
captain
community
input
in
this.
B
A
Thanks
so
much
for
for
the
whole
demo,
I
think
it's,
it's
really
powerful
everything
that
that
we
saw
here
the
whole
translation
part.
Maybe
we
can
go
back
to
the
the
image
once
again
to
this
one,
because
we
we
could
really
see
that
it's
the
same
kind
of
events
that
are
sent
so
we
really
saw
in
the
cloud
events
player.
A
We
saw
this,
let's
say
the
standard
that
we
want
to
establish
and
the
like,
the
the
the
form
of
communication
that
we
want
to
have,
and
you
could
really
see
the
whole
journey
from
deployment
all
the
way
to
production,
although
it
was
not
the
multi-stage,
including
quality
gates,
but
you
can
easily
build
this.
We
already
saw
the
improvement
step,
which
is
pretty
cool
that
you
all
already
included
this,
and
we
can
imagine
that
before
or
after
the
approval
there
might
be
another
stage
there
might
be
tests
to
be
executed.
A
But
again
the
tests
would
also
be
some
kind
of
a
cloud
event
and
we
would
trigger
the
test.
So
the
whole
idea
of
having
this
vocabulary
a
common
vocabulary
and
having
all
these
different
tools,
not
only
deployment
tools
but
also
testing
tools
playing
together.
I
think
it's
it's
a
really
strong
idea,
and
thanks
for
for
showing
this,
I
see
there
are
some
questions
coming
in
sure.
B
If
you
want
to
get
involved.
That's
why
I'm
just
leaving
this
slide
here.
You
can
definitely
join
like
the
sig
events.
You
know
slack
a
channel
there
inside
the
cdf
foundation,
slack
organization,
and
we
do
like
meetings
every
two
weeks
and
you
know
we
are
pretty
open.
It's
like
you
know.
Everybody
there
like
comes
from
different
companies
with
different
backgrounds,
but
they
are
really
interested
in
just
pushing
this
forward.
So
yeah,
if
you
have
any
ideas,
please
feel
free
to
just
drop
me
a
message
or
a
comment
or
or
join
the
slack.
B
So
it's
good,
I
will
be
sharing
these.
I
can
share
these
links
with
you
jurgen
and
that
we
just
can
put
them
with
the
recording
as
well.
I
think
that
people
usually
tend
to
want
to
go
and
look
by
themselves.
You
know
like
the
vocabulary,
the
plc
and
the
different
groups
and
documents
that
we
are
creating.
A
B
Yeah
this
one
here
and
here
you
can
find
basically
a
script
that
basically
will
install
all
these
things
even
creating
like
a
kubernetes
cluster
locally.
It
requires
you
to
have
some
some
tools
installed
right,
like
this
plc.sh,
and
it
explains
here,
what's
required,
what's
necessary
and
the
components
that
are
going
to
be
installed
for
running
the
demo,
that
I
just
run
right
and
yeah
again
here
like
more
diagrams
and
the
tools
that
are
installed
by
the
script
and
and
the
events
that
are
being
sent
as
well.
B
A
Cool,
thank
you.
Are
there
any
more
questions
on
on
the
on
on
the
demo
or
on
the
topic
or
anything
else
you
want
to
share
or
ask
maurizio.
Then
please
send
us
the
questions
in
the
slack.
Sorry
in
the
in
the
chat
here
or
by
q,
a
I
will
just
give
it
another.
Second,
if
some
some
questions
are
coming
in
in
the
meanwhile,
I
want
to
already
thank
you
for
your
for
your
presentation
and
the
whole
poc.
A
I
think
it's
really
great
to
see
how
all
these
tools
can
come
together
and
that's
actually.
I
really
believe
this
is
the
future
of
all
the
different
integrations
that
we
want
to
build.
If
we
can
kind
of
agree
on
one
definition,
then
it
will
be
so
much
easier
instead
of
learning
all
these
different
apis.
B
A
I
think
we're
good
here.
If
you
have
more
questions
for
maurizio,
you
will
find
him
on
in
the
cdf
slack
also
on
twitter.
If
possible,
we
can
maybe
also
share
your
slides
with
the
with
the
recording
perfect.
Then
you
will
also
find
the
twitter
handle
and
he
also
just
shared
it
here.
So
thanks
again
for
for
joining
us.