►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
A
B
I
had
one
week
and
then
I
have
two
weeks
coming
up
now
and
in
one
in
september.
I
want
to
go
october.
B
B
B
They
live
in
the
south,
sweden,
not
north,
but
yeah,
north
and
sweden,
but
it's
not
near
north
of
sweden.
C
C
So
eric
said
he
might
be
a
bit
late
johnny
today.
No
one
else
has
heard
slack
so.
C
B
Yeah
last
time
we
basically
just
jumped
into
a
bunch
of
different
items
and
just
discussed
them.
B
So
I
forget
people
we
get
to
maybe
walk
down
the
list
of
discussions
and
see
if
we
can
get
some
started.
A
B
I
didn't
check
my
slack
properly,
so
I
saw
in
the
email
had
said
he
wouldn't
be
able
to
join,
also
and
alois,
wouldn't
also
be
able
to
join.
C
Yeah
eric's,
I
was
going
to
join,
maybe
a
few
minutes
late.
I
don't
know,
but
it's
already
six
past.
We
can
wait
a
bit
more
for
eric.
If
you
want,
we
can
discuss
about
the
items
we
can
just
close
it
for
today.
B
Yeah,
I
don't
know,
do
we
have
any
ideas
on
how
to
get
things
going
a
little
bit
more
or
how
to
get
more
engagements.
C
I
get
a
bit
of
time,
one
thing
that
I've
been
planning
to
do,
but
I
didn't
manage
to
yet
and
is
to
kind
of
try
and
capture
the
issues
or
things
that
came
up
or
came
out
of
the
doing
building
the
plc.
C
So
what
kind
of
problems
with
things
that
we
noticed-
and
I
think
some
of
it
is
already
captured
in
the
discussion
from
last
meeting
like
the
fact
that
we
have
a
lot
of
data
in
the
attribute
that
should
be
only
used
for
filtering
and
routing
and
other
things
like
we
had
to
do
a
lot
of
adult
things
in
the
poc
to
carry
the
context
from
captain.
C
C
And
capture
them
yeah,
then
there
is
the
work
to
be
done
to
kind
of
evolve
a
little
bit
the
sdk.
That
was
just
it's
an
initial
implementation,
but
there
is
some
work
to
be
done,
so
there
are
ideas
of
things
that
we
can
do
forward
moving
forward
and
but
yeah,
as
I
said,
we
need
engagement.
We
need
people
to
be
able
to
spend
time
in
implementing
things,
and
so
one
thing
that
we
plan
for
the
next
meeting
is
the
naming
discussion
again
for
the
next
sig
meeting.
C
We
had
a
discussion
with
emil.
So
if
we
managed
to
close
that
discussion
in
let's
say
a
couple
of
weeks
around
the
time
two
three
weeks
and
we
can
start
creating,
you
know
things
like
github
organization
and
new
project
associated
with
the
sdk
and
the
spec,
and
then
we
could
try,
and
so
we
could
submit
that
project
the
project
to
the
cdf
and
try
to
get
more
involvement
in
that
way.
B
Maybe
it's
easier
to
to
have
something
like
a
code
product
or
something
that
people
can
commit
to
rather
than
having
people
discussing,
because.
A
B
We
have
these
meetings
and
there's
not
too
many
people
are
calling
to
them.
So,
but
maybe
it's
easier
with
with
us
accounts
things
then.
A
B
Yeah
one
thing
with
the
routing
there:
what,
when
we
had
a
chat
there
with
always
and
so
on,
he
his
idea
of
routing
contained
a
lot
more
things
than
I
thought
about
routing.
C
It
looks
like
it's
just
the
three
of
us
today
that
matthias
was
just
asking
me
about
writing.
Maybe
could
you
repeat
the
question.
B
B
C
Right,
at
least
in
the
scope
of
the
the
poc
so
far
and
routing
decisions
were
only
taken
based
on
the
message
type
and
the
message
source
possibly
so
these
are
the
two
bits
of
information
that
were
used
for
routing
and
those
are
already
existing
cloud
events,
films,
materials
so
really
didn't-
have
to
use
anything
specific.
C
Today,
cd
events
for
google.
It
will
be
nice
to
try
and
implement
some
more
use
cases
and
see
if
there
is
any
other
type
of
information
and
that
could
be
used.
That
could
be
useful
for
routing
yeah.
Possibly
I
don't
know.
C
B
Yeah
well,
it
gets
your
prob.
It
sounds
like
you're
you're
more
in
line
with
what
I
have,
because
when
I
was
thinking
I
was
trying
to
have
some
kind
of
a
way
how
to
frame
this.
But
if
you
check,
for
example,
if
you
want
our
our
specification
to
become
a
cloud
advanced
extension,
you
know
they
have
some
extensions
to
them
and
we're
taking
a
look
at
those
extensions.
They
were
quite
small.
It
was
basically
just
one
or
two
fields.
B
Yes,
so
if
you
want
to
have,
if
you
want
to
make
this
an
extension,
then
I
probably
would
like
to
have
maybe
one
or
two
extra
fields
in,
but
not
more
than
that,
which
would
mean
be
that
most
of
the
stuff
that
we
have
would
go
into
the
data
part.
C
I
think
so
my
impression
so
far
is
that
yeah
I've
not
yet
found
something
specifically
that
could
go
into
the
as
an
extension
I
mean
it
could
even
be
the
case
if
we
say
we're
just
providing
a
kind
of
schema
or
data
structure
for
the
body.
We
don't,
we
don't
have
to
have
new
new
fields
in
the
headers.
If
you
will
so
I
guess
we
could
some
something
that
might
be
interesting.
There
might
be
something
related
to
the
context.
C
Well,
no,
no!
No,
maybe
not,
because
I
I'm
not
sure
you
want
to
to
write
messages
based
on
context,
because,
again
the
context
is
unique:
kind
of
ephemeral,
type
of
information,
so
yeah,
I'm
not
sure
I've
not
seen
yet
a
field,
that's
being
implemented
as
an
extension.
D
So
I'm
trying
to
remember
the
exact
use
case
that
alois
brought
up,
but
I
think
it
was
something
like
so
say
say
that
we
we
are
deploying
a
service
or
we
we
send
out
a
yeah,
we're
deploying
a
service,
and
we
have
as
part
of
that
message
like
what
environment.
What
is
the
was
it
deployed
on
what
is
the
name
of
the
service
and
what
is
the
version
of
the
service
then
like,
for
instance,
the
environment
that
could
be
used
for
routing?
D
If
we,
if
someone
has
a
service
and
they
want
to
say,
I
am
the
service
that
wants
to
react
to
services
to
other
services
deployed
in
this
environment,
then
then
that
would
imply
maybe
not
routing
but
definitely
filtering
and
the
same.
You
go
one
step
further
and
say
I
am
the
thing
in
this
environment
that
wants
to
know
when
this
service
has
been
upgraded,
then
both
those
two
will
be
used
for
filtering.
D
B
B
C
But
then
I
mean
sorry,
I
I
I
guess
filtering
and
robbing
can
be
related,
at
least
when
using
the
when
using
the
the
canadian
events
bus.
C
It's
routing
is
based
on
subscriptions,
so
you
you
define
a
subscription
that
includes
a
destination
and
filters,
so
you
can
say,
send
these
messages
to
this
destination
if
they
match
this
filter
and
yeah.
C
So
if
you
have
an
application
that
deals
specifically
with
messages
specific
to
certain
environment,
then
I
guess
it
could
make
sense
to
to
filter
based
on
that
and
so
you
it
could
be
considered
routing,
because
you
say
you
don't
want
to
get
all
the
messages
for
all
the
applications
to
that
environment,
and
in
my
in
some
cases
you
could
say:
okay,
just
filter
on
the
destination.
In
other
cases
you
could
say:
well
those
are
different
environment,
maybe
staging
reproduction.
C
B
But
we're
actually
talking
about
some
kind
of
of
like
I
don't
know
if
I
use
the
word
right,
I
mean
in
a
field.
We
have
a
domain
concept.
So
for
company
ericsson
we
send
these
basically
millions
of
events
per
day
and
in
order
to
like
separate
those,
we
have
an
idea
of
a
domain.
So
basically
everything
within
the
domain
you
have,
you
can
filter
on,
but
I'll
be
using
rabbitmq
filter.
B
But
then,
if
you,
if
you
want
to
have
some
separations,
you
create
different
domains
and
then
we
let
certain
events
be
propagated
to
other
domains
if
they're
interesting,
for
example,
like
artifact,
new
and
so
on,
but
the
old
activity
events,
for
example,
the
jobstart
pipeline,
in
our
case
those
we
don't
propagate
to
other
domains,
because
that
would
be
too
much
data.
B
C
Yeah
yeah,
possibly
yeah.
I
guess
it's
just
limiting
the
events
to
those
that
are
relevant.
B
The
now
for
forgot,
the
field
that
we're
talking
about,
but
this
cd
dot
type
in
info,
we're
using
the
routing
key
in
rapdemke.
You
have
a
routing
key
to
know
where
it
comes
from
and
there
we
we
include
this
routing
key
domain
in
the
routing
key.
So
basically
we
have.
B
It
was
better
described
here
on
the
notes
for
for
last
time.
Let
me
just
drop
that
in
the
chat,
if
you
don't
have
it
yeah,
that's
the
notes-
and
I
can
probably
copy
that
part
also.
C
B
So
it's
this
part
with
you
have
a
family
and
you
have
type,
we
have
a
tag
and
we
have
a
domain
id.
C
B
Yeah,
I
mean
it's.
Basically,
it's
more
it's
more
like
top-down,
it's
a
more
top-down
approach,
because
it's
just
inside
a
company.
So
I
don't
know
if
you
have.
If
you
have
a
bunch
of
different
open
source
projects,
then
the
domain
id
of
having
like
pre-configured
domains
might
be
hard
to
come
up
with.
B
I
guess
you
need
to
some
kind
of
hierarchy
to
know
where,
where
you
want
to
listen
from,
if
you're,
if
you're
just
interested
in
a
certain
environment,
then
you
want
to
listen
on
that
environment,
but
that
you
need
some
kind
of
way
to
listen
to
it.
C
C
I'm
sorry
just
thinking
out
loud,
like
with
the
k
native
events,
router
router,
you
can
only
filter
on
exact
matches,
so
you
can
say
yeah.
C
Equals
exactly
this
string
or
you
can
say,
source
matches
exactly
the
string.
C
No
and
I
think
it's
for
a
performance
reason
that
they
just
allow
you
to
do
like
exact
match,
because
it's
yes
again,
it's
meant
for
routing,
and
I
guess
the
except
mention,
of
course
it's
much
quicker
to
to
compute
but
yeah.
I
could
try
to
find
out
if
there
is
more
reasoning
behind
this,
if
it's
a
something
that
don't
want
to
have
like
regular
expressions
or
partial
matching
or
if
that's
something
that
is
not
only
not
yet
there.
C
B
It
will
be
interesting,
so
reptimq
is
the
one
I
know
and
there
you
have
both,
and
so
when
you,
when
you
put
a
raffle
key,
you
have
dots
in
between
and
then
you
can
say:
okay
within
these
dots
take
whatever,
and
then
you
can
also
say
star.
That
is,
I
only
care
about
the
first
part
of
this
and
then
the
rest
of
it
can
be
wild
card.
D
Yeah,
I'm
looking
at
the
cloud
event
spec
now
as
well.
There
is
a
an
unrequired
with
optional
optional
field
called
subject
and
the
documentation
for
subject,
at
least
according
to
my
interpretation,
basically
says
this
is
where
you
put
whatever
you
need
to
put
when
source
is
not
enough
for
people
or
for
subscribers
to
filter
messages.
D
So
if
you
have
a
subscriber
that
is
only
interested
in
a
certain
subset
of
messages
of
the
same
type
or
from
the
same
source,
you
can
put
stuff
in
subject
to
deal
with
that.
So
if,
if
our
spec
could
also
include
a
design
for
what
should
be
put
in
the
subject
field,
that
could
also
possibly
be
helpful.
D
So,
for
instance,
we
could
say
that
if
you
do
a
service
deploy,
then
the
subject
is
the
service
that
you're
deploying
or
maybe
it
is
the
environment
and
the
service
that
you're
deploying
with
some
some
separator
in
it.
I
think
that
could
possibly
be
used
to
to
solve
some
subset
of
the
problems
without
introducing
new
attributes.
B
Yeah,
that
sounds
like
a
very
reasonable
thing,
because
I
I
like
the
idea
of
having
something
that
that
is
there
and
if,
if
we
need
to,
then
we
can
add
on
new
attributes,
but
we
can
try
to
to
come
up
with
something
a
subject.
B
C
B
So
this
source
could
probably
solve
a
routing
question,
but
did
you
have
some?
You
mentioned
something
else
that
andrea
or
maybe
I'm
jumping
ahead
now
on
the
subject,
please
stop
me
if
you
get
any
more,
but
you
talked
about
some
additional
things
that
that
you
have
to
do
ad
hoc
solutions
for.
B
C
Standard
or
anything
specified
in
the
protocol
that
would
specifically
help
carrying
it
around.
So
I
mean
because
the
there's
no
specification
from
what
we
have
in
the
body
we
just
placed
it
in
the
body
and
then
but
the
problem
is
that
then
the
receivers
that
translate
the
messages
or
that
process
the
messages
anyways
did
have
to
know
the
knowledge
about
where
to
look
for
that
field.
C
Even
for
the
sdk
to
be
able
to
return
generic
context
field
right,
so
we
could
have
something
like
say:
okay
in
the
body,
we
have
a
section
that
is
delegated
to
specific
application,
and
there
they
can.
They
must
have
a
fill,
which
is
called
context
and
the
name
of
the
section
must
be
called
the
same
name
of
the
application
or
the
source.
I
mean.
A
C
C
The
problem
is,
it
might
be
that
maybe
different
application
may
need
more
than
one
field
or
more
information
to
be
carried
around
as
part
of
the
context.
So
I
don't
know
if
that's
something
that.
C
B
Yeah
or
maybe
we
have
a,
we
always
say
that
for
an
application
you
can
you
receive,
you
can
have
this
dict
and
so
the
sdk
returns
kind
of
like
the
default.
The
protocol
has
some
fields
that
it's
defined
and
then
the
application
has
its
own
part.
That's
also
returned.
B
I
wonder
if
you
can,
if
we,
if
you
want
to
create
something
like
that
for
us,
we
have
cloud
events
in
the
bottom
and
those
cloud.
Events
are
then
transferred
on
on
something
else,
and
then
we
have
our
protocol
and
then
we
have
like
the
next
layer
would
be
the
application,
but
that
makes
sense.
C
Yeah,
I
think,
from
logical
point
of
view.
That's
the
structure
that
we
that
we
are
creating
yet
yeah.
B
A
C
B
Yeah,
that
is,
do
we
need
to
draw
some
kind
of
picture
in
order
to
forget
people
to
be
in
part
with
what
we're
talking.
Maybe.
B
Should
that
go
into
kind
of
like
the
vocabulary
draft,
then,
if
you,
if
you
want
to
go
that
direction,.
C
C
B
Yeah,
if
I'm
able
to
squeeze
out
some
time,
I
could
take
a
look
at
such
a
picture,
but
I
have
an
upcoming.
I
have
an
upcoming
e-fil
summit,
so
I
prepare
for
it.
So
I
don't
know
how
much
time
I
have
with
that
now,
but
I'll
put
that
in
my
to-do
list
at
least.
C
Okay,
all
right.
C
Anything
else
you
guys
like
to
discuss
and
these
topics
or
any
other
topic
any
follow
from
last
time.
D
We
should
try
to
attract
people
from
other
projects
or
companies
that
are
working
in
this
area.
He
mentioned
like
github
and
atlassian
and
aws
and
some
other
stuff.
Maybe
you
brought
it
up
and
on
the
sega
didn't
attend
the
last
time,
unfortunately,
not
that
we
can
do
much
about
it
now,
but
I
just
wanted
to
remind
ourselves.
C
Yeah,
definitely
I
mean
we're
doing
a
bit
of
advocacy,
work
and
like
presenting
this
plc
that
we
built.
A
C
I
think
mauricio
presented
a
captain
music
group,
I'm
planning
to.
They
asked
me
in
the
cdf
dlc
to
do
kind
of
a
presentation
or
update
where
we
act
with
this
with
the
work
on
this.
So
we'll
present
it
there,
and
I
also
we
proposed
a
talk
to
actually
have
a
talk
accepted
at
devops
word
with
mauricio
on
this
and
kubecon
as
well.
D
C
Yeah
yeah
we
we
can
try
and
reach
out
to
people
from
specific
companies
directly
as
well.
For
sure,
I
think
it's
it's
good
if
we,
if
we
know
about
use
cases
that
we
can
solve
for
events-
and
we
can
include
those
in
upcoming
pocs-
that's
also
very
good
to
make
a
stronger
case
for
what
we're
doing.
C
Nothing
that
comes
to
mind
right
now,
but
I
need
to
be
honest
to
spend
some
time
and
yeah
look
through
the
different
bits
of
code
that
we
wrote
and
see.
If
there
is
anything
else
that
comes
up,
I
think
yeah.
C
A
B
That's
good
also,
when
you're
looking
at
it,
I
I
created
a
a
set
of
unit
tests
for
the
sdk
and
it's
it
feels.
I
tried
to
reduce
the
amount
of
duplication
there,
but
it
feels
awful
a
lot
a
lot
of
code
for
for
something
that
is,
is
kind
of
like
a
repetitive
work.
B
So
it
feels
like,
if
you
generated
one
event
and
then
you've
generated
all
of
them.
I
mean
we
could
probably
just
specify
how
the
event
looks
like
and
then
generate
the
code
for
that
event,
based
on
some
kind
of
template
or
something,
and
then
we
just
need
to
test
the
template,
rather
than
actually
testing
that
each
single
event
can
be
produced.
C
C
C
So
is
there
an
open
pr
with
the
unit
test
that
needs
to
be
looked
at.
B
Yeah,
I
have
it
up
for
review.
I
think
I
have.
B
Okay,
yeah
add
unit
test
and
92.
B
B
B
C
Yeah,
probably
I
wonder
if
that's
part
of
what
could
be
generated
as
well.
You
get
some
kind
of
spec
for
the
structure
of
the
events.
B
Yeah,
I
think
it
would
be
better
if
you
can
just
you
know.
This
is
how
an
event
would
look
like,
and
then
we
generate
those
parts,
because
I
think
there's
going
to
be
an
awful
lot
of
code
for
it.
C
C
B
C
B
Yeah,
I
could
do
that.
I
can
create
two
issues
actually
one
to
cover
more
documentation.
One
can
do
one
about
reducing
code
application
in
sdk,
so
we
have
on
track
at
least.
C
C
Okay,
anything
else,
folks.