►
From YouTube: Toolchains Are Only As Strong As Their Weakest Link: A Discussion On Interoperability Across CI/C...
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Toolchains Are Only As Strong As Their Weakest Link: A Discussion On Interoperability Across CI/CD Solutions - Melissa McKay, JFrog; Andrea Frittoli, IBM; Fatih Degirmenci, Continuous Delivery Foundation; Mauricio Salatino, VMware; Justin Abrahms, eBay
JW Grand Ballroom 3
Speakers: Mauricio Salatino, Andrea Frittoli, Fatih Degirmenci, Justin Abrahms, Melissa McKay
The development of a CI/CD pipeline often involves cobbling together a number of different tools and technologies. The software development and delivery pipeline from beginning to end is a vast space and one of the benefits of open source technologies is the variety of tools to choose from, each born from a need expressed by the community, and each with their own strengths and capabilities. Although excellent tools have been developed by the community and adopted at large by various organizations, connecting these tools together in a robust and reliable way is a challenge. Join this discussion of the various issues that can arise when composing a full CI/CD pipeline and how these might be addressed. Learn about the CDF Interoperability Special Interest Working Group and its vision to offer clarity and pursue solutions to the CI/CD implementation challenges organizations must overcome.
A
A
We,
this
conversation
is
actually
more
about
one
of
the
special
interest
groups
that
we
put
together.
It's
called
the
interoperability
special
interest
group,
it's
part
of
the
cd
foundation,
and
I
had
the
pleasure
of
meeting
actually
mauricio
today,
amazing
and
the
rest
of
these
gentlemen,
all
at
this
group
and
I'm
going
to
let
them
introduce
themselves
and
I'll,
let
you
know
where
they
come
from
just
so.
You
have
an
idea
of
the
background
and
then
we're
just
going
to
start
having
a
discussion
here.
So,
first
of
all,
I
guess
myself,
melissa,
mckay.
A
B
Mr
fatih
manji,
I
joined
the
conference
foundation
recently
last
week
to
lead
the
efforts
of
our
community
from
eriksen,
and
I
was
involved
in
conscious
dare
foundation
since
it's
very
early
days,
and
I
was
part
of
special
interest
or
group
interpreter.
I
am
still
part
of
special
class
group
interoperability
and
now,
thanks
to
medicine
and
justin,
we
will
continue
pushing
our
force
forward
and
then
we
also
start
an
especially
interest
group
around
software
supply
chain.
I
am
currently
co-chairing
that
group
and
I
am
from
sweden.
C
Hello:
everyone,
I'm
andrea
fritoli,
I'm
a
developer
advocate
and
software
engineer
at
ibm.
I'm
also
involved
with
a
few
interest
groups,
a
special
interest
group,
the
cdf,
the
interoperability
and
the
co-chair.
The
events
special
interest
group
and
I
am
a
maintainer
of
the
cd
events
project,
which
was
created
by
the
event
special
interest
group
and
yeah
with
tacton
as
well.
D
Awesome,
hello,
I'm
justin
abrams,
I'm
a
principal
architect
and
the
head
of
the
open
source
program
at
ebay,
I'm
involved
in
the
cdf
as
a
general
board.
Member,
I
think,
is
the
name
and
also
the
chair
of
the
interoperability
sig
with
melissa
and
I'm
also
a
maintainer
of
open
feature
which
is
adjacent.
E
Well,
yeah,
my
name
is
maurice
salatino
and
I
joined
the
cdf
pretty
early
on
as
well,
and
I
I
think
that
I've
been
jumping
between
different
groups
like
interoperability,
is
one
but
most
closely
involved
with
c
events
and
yeah
the
cd
events
initiative,
I'm
working
from
vmware,
but
full
time
working
on
a
project.
That's
called
k
native.
E
I
don't
know
if
you
have
heard
that
before
and
I'm
really
passionate
about
like
integration,
so
I've
been
doing
software
integrations
for
a
long
time,
and
I
think
that
the
cd
events
project
is
a
very
you
know.
It's
a
very
worth
a
project
to
spend
time
and
just
collaborate
with
different
companies
and
different
people
that
it's
interested
into
promoting
more
interoperability
in
the
tools
that
we
are
creating
in
the
cloud
native
space.
A
Awesome,
so
I
don't
know
if
you
can
tell
why
I
assembled
this
group
just
from
their
introductions.
They
come
from
amazing
backgrounds,
they're
all
very
passionate
about
what
they
do,
they're
very
much
involved
in
the
organizations,
and
these
are
going
to
be.
You
know
the
decision
makers
and
the
king
makers
moving
forward.
B
Thanks
man,
the
origin
of
special
interest
group
interpret,
goes
back
to
other
communities
before
joining
countries.
There
foundation
as
a
contributor
around
2019
I've
been
contributing
to
linux
foundation,
networking
projects,
openstack,
zool
and
so
on,
and
during
those
days
around
2016-17,
we
started
having
troubles
to
bring
different
open
source
technologies
together,
like
platforms
or
network
software
network
controllers
or
applications,
because
all
these
communities
were
using
different
ci
cd
tools
and
technologies,
and
there
wasn't
an
easy
way
for
us
as
community
to
bring
these
technologies
together,
deploy
them
and
test
them.
B
And
around
those
days
we
start
conversations
around
how
we
can
tackle
this
challenge,
because
we
we
can't
possibly
integrate
all
these
different
tools
with
each
other.
Even
if
we
tried
the
integration
is
costly
and
can
be
broken
on
a
daily
basis,
because
committees
like
to
change
things
because
they
move
forward
and
then
when
cd
foundation
was
established
around
2019,
that
gave
us
a
chance
to
reach
out
to
the
projects
and
communities
who
we
are
actually
have
been
working
with
and
using
such
as
jenkins,
spinnaker
and
so
on.
B
And
we
then
said
this
is
a
perfect
place
for
us
to
actually
bring
this
topic
up
and
start
talking
around
the
topic
with
the
maintainers
of
these
projects
and
with
our
colleagues.
Friends
from
all
these
other
communities
from
networking
openstack
kubernetes,
we
proposed
formation
of
special
interest
group
introverted,
2000
november
2019
november.
I
think
during
kubecon
san
diego
and
then
it
got
approved.
A
We
hear
interoperability,
which
is
the
name
of
the
group,
and
we
also
hear
integration
and
I'd
like
for
each
of
you
to
describe
how
you
got
involved
with
the
interoperability
group
or
something
coming
out
of
the
interoperability
group
and
what
those
two
terms
mean
to
you.
Why
they're
important
to
you
I'll
start
with
mauricio.
E
And
if
you
think
about
like
integrating
all
these
tools
to
achieve
something
well,
you
will
spend
a
lot
of
time
trying
to
integrate
them
all
in
order
to
just
achieve
whatever
you're
trying
to
achieve
in.
In
the
other
hand,
when
you
are
building
interoperability,
what
you
expect
is
to
have
a
common
vocabulary
that
all
these
tools
can
talk,
and
then
you
can
just
build
integrations
based
on
that
common
vocabulary,
which
reduces
the
amount
of
glucose
that
you
need
to
write.
C
B
And
I
agree
three
or
few
it's
difficult
to
disagree.
I
think
the
thing
is
like
the
key
thing
I
had
to
deal
with
during
my
previous
job,
like
while
I
was
operating,
cicd
systems
or
production
systems
like
as
justin
explained,
like
which
tools
we
should
be
integrating
with
each
other.
What
about
the
next
tool?
We
want
to
bring
into
our
pipelines
and
you
always
have
to
keep
up
with
what's
happening
with
the
projects.
But
if
we
have
the
true
interoperability
in
place,
we
don't
have
to
touch
the
existing
system.
B
We
just
hook
the
new
tool
or
technology
into
our
existing
production
systems,
and
it
just
starts
working
because
they
all
use
the
same
language.
So
it's
kind
of
like
you,
don't
have
to
destroy
anything,
because
if
you
are
trying
to
integrate
something
to
an
existing
system,
you
may
have
side
effects
which
may
break
things
which
may
stop
your
pipeline,
which
may
block
you
to
roll
out
an
urgent
bug
fix.
B
But
if
you
are
like
adding
a
tool
that
speaks
in
the
same
language,
you
have
very
low
risk
compared
to
how
it
would
be
with
integration
again
like
it's.
We
have.
We
can't
fix
all
the
tools
and
get
them
integrated
with
each
other,
but
again,
looking
at
the
future
and
thinking
that
and
starting
to
in
interval
terms
terms
is
critical,
and
I
think
that
is
the
important
thing
to
perhaps
think
going
forward.
D
I
think
one
thing
that
I
would
add
to
that
is
like
when
you
do
an
integration.
That's
like
a
developer,
write
some
code
and
then
it's
done
right
like
you,
don't
have
to
do
a
lot
of
work,
and
so
it's
really
nice
from
a
getting
things
done
perspective
but
lacks
scalability,
and
I
think
one
of
the
other
important
differentiations
is
integration.
Is
a
technical
concern
like
what
is
the
api
contract
for
that?
A
A
First
of
all,
we
have
a
lot
of
members
of
the
cd
foundation
a
lot
of
corporate
sponsors,
but
we
talk
a
lot
about
open
source
projects
as
well.
I
think
most
of
us
use
them
in
our
day-to-day
work.
I
do
at
jfrog,
of
course,
and
I
want
you
just
in
from
your
background
and
your
opinion-
why?
Why
does
this
matter?
I
mean
it
seems
like
it
makes
sense
for
open
source
projects,
but
why
does
a
an
organization
like
this
matter
to
a
corporation
and
I'm
going
to
start
with
you
mauricio.
E
Yeah,
that's
yeah.
That's
definitely
important.
I
think
that
it's
like
there's
the
open
source
aspect
of
it,
but
also
the
you
know,
yeah
like
building
an
ecosystem
that
it's
it's
healthy
and
it
promotes
best
practices,
and
it
promotes
also
in
like
inclusion
in
the
fact,
in
the
sense
that
you
can
bring
more
tools
and
more
tools
should
be
able
to
be
working
together.
E
I
think
that
for
corporations,
I
think
that
there
is
a
big
benefit
on
being
able
to
play
nice
with
other
corporations
and
also
to
support
customers
that
are
actually
customers
from
multiple
vendors
and
they
want
to
get
stuff
done
and
they
are
blocked
by
these
vendors
not
working
together.
So
it's
like
bringing
more
synergy
and
joining
kinda
like
as
an
individual
to
the
city
foundation
or
one
of
these
groups
is
very
rewarding,
because
you
will
learn
a
lot
in
a
multi-vendor
environment
where
there
will
be
a
lot
of
collaboration.
D
Yeah,
that's
awesome
for
me,
a
lot
of
my
day.
Job
is
spent
doing
a
lot
of
discussions
with
people
around
the
learnings
of
the
dora
program.
So
state
of
devops,
stuff
and
and
research
shows
that
when
you
unlock
capabilities
like
continuous
delivery,
you
have
better
outcomes
for
your
business
and
selfishly.
It
is
dramatically
more
fun
to
be
in
a
to
be
a
developer
in
a
place
where
you
don't
have
to
do
manual,
verification
processes
and
everything's,
automated
and
so
to
me,
like.
D
The
cdf
is
important
because
it
provides
common
language
in
which
to
talk
about
these
tools
and
capabilities
and
provides
best
practices,
which
is
a
different
sig
around
like
how
do
we
do
continuous
delivery?
What
does
a?
What
does
a
pipeline
really
look
like
and
what
should
the
components
of
it
be?
C
Going
in
a
way
that
it
makes
sense
for
the
things
that
you're
doing
and
also
then,
if
you're,
building
a
product
or
a
service,
and
that
you
offer
this
to
customers
and
if
your
service
is
interoperable
with
other
tools
that
your
customer
already
use,
it
just
makes
it
easier
to
integrate.
You
know
it's
like
it's
a
very
good
selling
point.
I
think.
B
Yeah,
I
think
I
will
refer
back
to
justin
a
conversation
we
had
on
slack
like
a
month
ago
around
that
topic.
I
think,
like
I
see
this
community
as
the
place
to
innovate
in
cicd
ecosystem,
like
some
of
the
conversations
that
are
taking
place
like
the
one.
I
refer,
the
intent
based
pipelines,
they
could
become
real,
critical,
impactful
things.
So
if
you
are
a
vendor,
if
you
don't
want
to
miss
what
is
being
currently
discussed
within
the
community,
you
must
be
there.
If
you
arrive
late,
you
may
be
late.
B
If
you
are
there
right
now,
you
can
take
part
in
those
discussions
and
impact
how
the
community
is
thinking
and
contribute
to
those
efforts
and,
like
the
innovation
aspect,
is
so
critical
because,
like
it
literally
prepares
you
for
the
future,
because
you
will
not
be
hit
by
a
sudden,
you
know
new
thing
that
is
coming
out
from
the
community
like
how
cd
events
happen.
His
significance
came
out
like
that
way,
conversations
around
few
contributors
and
then
it
became
a
sig
then
became
a
project
and
similar
conversations
are
happening
on
a
daily
basis.
B
So
I
think,
regardless
of
the
you
know,
company
type,
end
user
or
vendor.
I
think
it
is
important
to
be
there.
It
is
important
to
be
talking
with
the
community
and
contributing
those
discussions
again.
The
development
like
how
we
are
talking
about
shift
left
development
is
also
should
left
shift
left
because
most
of
the
products
today
use
open
source,
say
80
percent
90
percent-
I
don't
know
so.
If
you
are
not
in
the
community,
then
you
may
be.
A
A
We
all
see
the
value
in
becoming
a
part
of
a
group
like
this
and
solving
the
bigger
overarching
problems
that
we
all
struggle
with
every
day.
I
know
as
a
as
a
developer,
it's
a
kind
of
a
little
hard
to
see
that
high
you're
you're
down
here,
you're
working
on
that,
like
actual
integrations,
for
example,
but
being
able
to
see
something
a
little
bit
at
a
higher
level,
joining
one
of
these
groups
being
able
to
solve
the
bigger
issues
so
that
you
don't
have
to
struggle
so
much
as
a
developer.
A
A
You
predicted
that
I
I
want
each
of
you
to
tell
me
what
you're
passionate
right
now
that
we
discuss
in
the
interoperability
group
or
in
other
other
cigs,
that
you're
involved
in
or
other
projects
you're
involved
in
like
cd
events
and
I'm
starting
with
andrea,
because
you
started
with
cd
events
and
have
a
lot
to
do
with
the
success
of
that
project.
So
go
ahead
and
tell
us
a
little
bit
about
what
it
is
for
those
of
us
who
don't
know
and
where
they
can
find
out
more
information.
C
Yeah,
absolutely
thanks
melissa,
so
cd
events,
it
started
from
the
sig
events.
It's
a
relatively
new
project
is
incubated
in
the
cdf
and
we
are
building
a
specification
for
events
in
the
cicd
space.
So
we
want
to
define
a
common
language
so
that
projects
in
the
tools
in
the
cicd
space,
ranging
from
configuration
management
system
to
ci,
cd
tools,
build
tools,
tests,
artifact
repository
deployment
tools,
etc.
So
they
can
emit
events
that
are
in
the
same
language,
which
enables
tools
to
talk
to
each
other.
C
C
We
are
building
sdks
for
a
few
languages,
go
java
and
python,
and
another
thing
that
we
are
doing
a
lot
is
less
technical,
but
more
like
really
talking
to
a
lot
of
people
about
cd
events.
We
had
a
day
zero
event
at
cubecon
all
about
city
events
with
a
great
talks
there
and
yeah.
So
also
here,
it's
it's
a
great
opportunity.
C
We
are
talking
to
a
lot
of
people
because
the
way
we
want
to
develop
the
project
is
use
case
driven,
so
what
we
want
to
be
listening
to
what
what
our
people
needs,
what
they
need
in
terms
of
interoperability
and
we
then
implement
pocs.
That's
why
we
already
have
some
sdks,
because
we
need
to
implement
those
pocs
and
yeah
to
make
sure
that
we
are
driving
this
in
a
direction
that
is
actually
solving
problems
and
creating
yeah
potential
solutions.
D
Cool,
I
can
go
next.
I
think
the
thing
that
I'm
most
excited
about
is
honestly,
like
some
of
the
definition
work
that
we're
doing
of
like
figuring
out
what
the
steps
of
a
pipeline
are.
What
are
the
stages
and
like
what
sort
of
things
can
you
do
there
like?
Okay,
so
we
built
a
thing,
that's
good!
What
what
other
things
can
we
do
to
make
sure
that
builds
good,
and
so
one
of
them
is
like
test
it
like
you
run
tests.
D
That
makes
sense,
but
we
might
also
do
like
static
code
analysis
or
like
with
a
security
mindset
or
from
a
code
correctness
standpoint
and
like
coming
up
with
a
qua
a
common
vocabulary
for
what
those
different
types
of
thing
are,
as
well
as
here's
some
cool
things
that
you
didn't
know
that
maybe
you're
not
ready
for,
but
in
six
months
or
five
years.
You
know
that
like
doing
dynamic,
application,
security
scanning
or
fuzzing
is
something
that
you
could
be
doing
or
like
the
chaos
engineering
stuff
that
people
do
it's
like.
B
B
I
think
this
like
having
us
as
humans
talking
and
understanding
each
other
is
a
critical
step
take,
and
I
think
we
achieved
that
up.
Certainly,
we
can
still
do
more
than
that,
but
I
think
we
have
a
good
baseline
now,
where
we
can
lean
on
and
build
more
common
definitions
and
go
into
details
like
static
analysis,
testing
and
so
on.
E
Yeah
good
stuff-
and
I
really
like
that
problem
trying
to
solve
like
the
vocabulary
aspect
of
it
and
conceptually.
What
do
you
need
in
order
to
basically
define
the
terms
without,
like
being
so
intrusive,
that
a
tool
that
already
has
their
own
terms?
You
can
actually
use
that
vocabulary
and
still
be
functional
and
complete.
Basically,
I'm
I'm
kind
of
like
very
practical,
like
I'm,
really
passionate
about
building
stuff,
I'm
building
integrations
and
that
stuff.
E
E
So
it's
it's
worth
the
time
just
to
have
like
a
single
point
like
a
specification
where
we
can
just
all
share
and
then
build
tools
on
top
of
those
abstractions
and
then
just
you
know,
we
can
go
even
higher
on
on
more
abstraction
layers,
but
at
least
we
have
a
common
based
understanding
between
the
different
tools
and,
what's
going
on,
I'm
really
passionate
nowadays
about
trying
to
solve
that
question.
One
question
that
was
asked
yesterday
in
andrea's
session
about
how
do
we
ask
different
vendors
to
adopt
this
kind
of
specifications?
E
It's
a
very
difficult
question
to
answer,
because
you
cannot
force
companies
to
just
adopt
stuff.
That's
not
going
to
happen.
So
I've
been
doing
a
little
bit
of
research
about
how
can
we
just
be
more
proactive
into
providing,
let's
say,
mappings
or
transformations
for
things
that
already
exist
to
a
common
vocabulary
like
that,
the
one
that
we
have
and
I'm
100
sure
that
this
problem
has
been
solved
before
several
times
for
different
specifications.
D
I
think
the
thing
that
corey
doctoral,
mentioned
earlier
today
around
like
network
effects,
makes
a
lot
of
sense,
because
once
you
have
six
out
of
seven
who
support
a
data
data,
interchange
format,
then
it
becomes
less
of
a.
We
need
to
convince
that
company
and
becomes
more
of
like
hey
users.
Did
you
know
that
this
company
doesn't
do
the
thing
that
is
awesome
and
everyone
else
does
yeah.
E
A
So
what
you've
just
witnessed
right
here
is
a
discussion
we
would
have
in
one
of
our
sig
interoperability
groups
or
one
of
the
other
groups
as
well.
This
is
how
we
talk
about
things.
This
is
how
we
discuss
things
come
up
with
new
ideas.
All
of
us
come
from
different
companies,
like
I
said
before,
different
backgrounds,
so
we
all
come
from
our
individual
use
case
scenarios
in
our
own
silos,
and
it's
been
incredible
to
be
a
part
of
this
group.
A
I've
learned
a
lot
about
what
other
people
are
doing
in
the
industry,
how
they're
solving
these
problems-
and
I
encourage
you
all
to
also
become
a
part
these-
these
meetings,
that
we
have
they're
all
public
they're,
all
open,
go
to
the
cdf
website.
You
can
find
information
about
when
we
meet
and
go
ahead
and
get
involved.
Oh,
I
also
want
to
take
a
moment
just
to
plug
cd
events,
one
more
time
we
are
having
the
community
day
on
friday
for
a
cd
event.
A
D
A
F
What's
the
percentage
of
work
that
you
do
in
the
open
source
community
during
your
day,
job
versus
personal
time,
because
I've
been
trying
to
do
more
and
more
open
source,
but
my
day
job
gets
in
the
way
and
then
my
kids
get
in
the
way
of
my
personal
time.
So
you
know
it's
a
challenge.
So
curious
is
what
that
split
is
for
you
all.
D
I
would
say
I
do
90
plus
percent
of
my
work
in
open
source
during
my
work
day.
Part
of
that
is
because
I'm
the
head
of
the
open
source
program,
but
more
re,
but
that's
not
actually
the
bulk
of
my
work.
I
I
have
pushed
internally
so
we're
building
a
feature
flagging
thing
inside
ebay
for
internal
use
and
we
could
go
build
our
own
client
library
or
there's.
D
And
so
it's
about
turning
my
work
problems
into
ebay
doesn't
care
about
future
flags
like
that's,
not
a
competitive
advantage
that
we
have
it's
pretty
standard
in
the
industry,
and
so
why
shouldn't
the
work
that
we
do
be
open
source
because
we'll
get
help
maintaining
it,
and
it
looks
good
for
ebay
and
like
there's
a
bunch
of
good
reasons
for
that,
and
so
having
that
conversation
is
a
really
important
one.
That
has
enabled
me
to
be
able
to
do
my
work,
mostly
at
work.
C
D
F
A
Great
answers,
I
encourage
you,
bring
that
question
to
one
of
our
meetings.
Maybe
we
can
discuss.
That
would
be
great
all
right.
Thank
you.
Everyone
for
coming,
I'm
going
to
wrap
this
up
now.
You
can
find
us
we'll
be
here
most
of
us
through
the
rest
of
this
week.
I
think
so
track
us
down.
If
you
have
any
more
questions,
follow
us
on
twitter
come
to
one
of
the
groups
that
we
have
we'd
love
to
see
your
faces
thanks.