►
Description
With nearly every modern application built on open source libraries, developers contributing to these projects rely on CI/CD in order to keep up with the rapid speed of development. CircleCI recently surveyed over 800 open source developers to understand what benefits they have gained by using CI for their open source projects and what challenges they have run into while doing so. Join us as we explore how open source communities are adopting CI/CD to modernize their delivery pipeline and learn some best practices for implementing CI/CD for your own open source projects.
A
All
right
we're
gonna
go
ahead
and
get
started
now.
I'd
like
to
thank
everyone
who
is
joining
us
today.
Welcome
to
today's
CN
CF
webinar.
What
does
the
open
source
community
need
from
CI
CD,
I'm,
Katelyn,
Barnard
marketing
manager
at
CN,
CF
and
I'll
be
helping
to
moderate
today's
webinar
I'd
also
like
to
welcome
our
presenters
today,
vivec
Ravi
Shankar
and
Tom
Trahan
at
circle,
CI
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
speak
as
an
attendee,
so
there's
a
Q&A
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
any
questions
in
there
as
they
come
up
throughout
the
webinar
and
then
we'll
get
to
all
of
those.
At
the
end,
the
session
is
being
recorded
and
will
be
sent
out
afterwards,
along
with
the
link
to
the
presentation,
typically
within
24
hours.
So
with
that
I'll
hand
over
to
the
back
and
Rob
to
take
off
today's
presentation.
A
B
You
very
much
Kaitlyn
really
appreciate
the
invitation
and
happy
to
be
here
today,
so
myself,
I
handle
business
development,
so
everything
to
do
with
partnerships
and
circle,
CI
technology
partnerships
with
with
with
companies
that
we
integrate
with,
as
well
as
channel
partnerships
and
vivec
from
our
product
marketing
team.
It's
always
thinking
about
the
product
in
terms
of
the
best
use
cases
for
our
customer
base.
So
that's
probably
the
last
time
you'll
hear
us
talk
about
circle
CI
today,
the
rest
of
it's
all
gonna
be
about
CI
CD,
particularly
for
for
open
source
projects.
B
So,
let's
get
started
so
today
we're
gonna
run
through
a
few
topics
and
then
finish
up
with
with
QA
and
so
look
forward
to
your
questions
here.
At
the
end,
first
thing
we're
going
to
talk
about,
is
you
know,
ultimately,
why
is
you
know
continuous
integration,
CI
CD?
Why
is
it
important
for
open
source
projects
and-
and-
and
ultimately
you
know,
why
should
you
be
embracing
adding
this
to
your
open
source
project?
B
The
projects
that
open-source
projects
when
they
do
get
rolling
on
setting
up
and
effectively
using
CI
and
CB
on
their
on
their
projects.
What
are
those
practices
that
we've
seen
employed
the
most
frequently
by
by
essentially
the
projects
that
are,
you
know
doing
it
right
quote-unquote?
So
so
that's
where
we're
gonna
go
today,
definitely
accumulate
those
questions
and
submit
those
to
Kaitlin
as
we
go
and
we'll
come
back
to
those
at
the
end.
So
starting
off
with
you
know,
why
is
CI
important
for
OSS
I
think.
B
Ultimately,
there
is
not
a
lot
of
education
required
anymore
on
the
concept
of
continuous
integration.
I
think
most
folks
on
the
call
here
today
and
then
in
the
community
are
now
well
aware
of
why
it's
important
and
how
critical
it
is
to
to
effectively
being
able
to
run
a
kind
of
software
project
right,
but
particularly
those
that
start
to
grow
in
size
and
grow
in
the
number
of
contributors.
And
as
you
look
now
at
where
open-source
projects
are
in
their
in
their
growth
and
usage
across
the
the
community
and
across
the
world.
B
We've
moved
from
a
period
where,
ten
years
ago,
open
source
software
here
at
the
top
of
the
slide
represented
somewhere
between
five
and
ten
percent
of
the
software
that
that
you
know
any
software
project
across
the
world,
whether
a
commercial
project
or
an
internal
project
at
a
company
or
a
personal
project.
You
know
only
five
to
ten
percent
of
that
prod
of
that
software
was
open,
source
software
and
and
so
in
fact,
its
impact
on
a
lot
of
the
work
that
that
downstream
users
were
having
was
fairly
limited.
B
So
let's
go
to
the
next
slide
here
and
obviously
then
that
has
its
direct
corollary.
Where
is
if
the
open
source
project
doesn't
have
the
ability
to
put
out
trusted
code
or
can't
do
so
on
a
regular
frequent
basis,
then
it
tends
to
become
just
less
useful
to
downstream
consumers,
and
so
you
know
all
of
us
who
do
open
source
projects.
We
all
do
so
with
the
intent
to
provide
useful
software
software.
That's
going
to
become
and
make
a
difference.
B
You
know,
there's
really
these
three
major
pillars
that
that
folks
go
through
when
they,
when
they
think
about
software,
there's
ultimately
the
starting
point,
which
is
the
creation
and
collaboration
around
the
code
itself.
And
this
this
takes
place.
You
know,
obviously
within
source
control
systems
under
not
github
and
bitbucket
and
get
lab
are
those
places
where
you
know
as
a
community.
B
Open
source
contributors
are
coming
together,
collaborating
on
changes
in
that
distributed
environment
in
those
source
source
code
and
in
those
source
code
systems,
and
it
really
does
provide
for
this
ability
to
to
create
the
necessary
synergies
across
folks
that
are
contributing.
So
you
know,
as
a
project
starts,
when
it's
just
a
single
user,
managing
that
collaboration
obviously
only
have
to
collaborate
with
yourself,
but,
as
you
start
to
add
additional
contributors,
the
coordination
across
those
efforts
starts
to
become
more
complex.
B
So
you
need
to
put
in
place,
of
course,
these
types
of
automated
systems
that
help
to
manage
that
contribution
and
to
avoid
the
conflicts
and
to
resolve
the
conflicts
that
inevitably
come
up.
As
you
start
to
grow.
The
number
of
folks
that
are
that
are
working
together
on
these
projects
on
the
next
phase.
When
you
get
beyond
the
creation
of
code
and
the
collaboration
on
code,
you
have
that
same
set
of
issues
that
pop
up
in
terms
of
the
testing
and
deployment
of
code
right
so
think
about
the
middle
pillar
of
software.
B
What
are
those
elements
that
they
find
the
most
challenging
and
the
most
useful
for
them
when
trying
to
add
CICP
into
their
open
source
project?
So
so
with
that
I'm
gonna
turn
this
over
to
the
back
and
have
him
take
you
through
some
of
the
research
we've
recently
done,
and
some
of
the
results
that
we
heard
back
from
from
our
user
base
cool.
C
Thanks
so
like
Tom
was
saying
we
really
wanted
to
understand.
You
know
how
our
circle
CI
users,
thinking
about
CI
CD,
like
what
is
the
value
that
CI
CD
is
a
whole.
You
know
whether,
even
if
it's
not
us
specifically,
what
is
the
value
that
CI
CD
is
bringing
to
them
and
how
should
it
actually
be
working
for
them
to
make
open-source
development
easier,
not
more
complicated.
C
So,
just
a
little
bit
on
the
survey
method,
oh
gee,
we
we
sent
out
a
survey
to
about
14,500
of
our
users
of
those
we
got
827
responses,
so
we
actually
got
like
a
pretty
good
response
rate
just
for
for
a
survey
that
you
know
you
weren't
really
required
to
do
so.
One
of
the
the
huge
things
we
just
wanted
to
ask
is,
like
you
know,
is
CI
CD
actually
helpful
for
these
users
in
the
first
place,
and
we
we
definitely
got
a
positive
answer
on
that
one.
C
So
most
of
our
users
said
that
it
would
either
be
a
most
impossible
to
maintain
their
open-source
project
without
CI,
or
it
would
be
very
difficult
to
maintain
it
without
it.
You
only
have
a
small
number
of
people
who
are
saying
that
it
would
be
a
minor
in
canyons
and
almost
no
one's
saying
that
it
it
isn't
necessary
at
all.
C
That
is
well
maintaining
code
quality.
Getting
a
road
map
set
up.
You
know
you
make
sure
that
everyone
has
the
line
on
those
things
and
then
test.
Writing
is
up
there
also,
you
know
so.
Actually
writing
those
tests
that
your
your
CI
tool
is
going
to
maintain
are
is
you're
going
to
run.
Excuse
me
is
also
a
pretty
difficult
part
of
maintaining
an
open
source
project
so
because
of
this,
what
should
you
really
be?
Looking
for
in
a
CI
solution
for
your
open
source
project?
C
The
first
thing
is
you:
you
generally
want
to
go
with
a
SAS
solution,
and
that's
just
because
managing
servers
takes
time.
It's
just
going
to
be
easier
if
you
can
spend
your
time
actually
contributing
to
your
open
source
project
rather
than
you
know,
running
a
server
on
the
side
to
just
be
be
testing
that
project,
and
that's
one
of
the
reasons
that
you
know.
Solutions
like
like
Travis
gained
so
much
popularity
early
on
the
open-source
communities,
because
you
know
they
were
one
of
those
first
providers
to
offer
a
really
good
cloud-based
solution
for
ci.
C
Secondly,
fast
build
times
this
one's,
you
know
pretty
self-explanatory.
You
you
want
to
be
looking
for
a
solution.
That's
going
to
be
building
your
your
code
as
quickly
as
possible,
because
you
know
less
time
waiting
for
those
tests
to
run
and
your
your
application
to
build
is
going
to
mean
you
know
more
time
that
you
can
put
into
actually
delivering.
You
know
more
value
to
the
project.
C
Third
is
easy
integrations
with
the
tools
that
you
use
already,
so
that
you
know
there's
a
lot
of
other
DevOps
tools
out
there
code
coverage
tools,
things
like
that
they're
also
going
to
make
developing
open
source
projects
more
efficient
and
any
CI
tool
that
it
has
easy
integrations
with
those
other
tools
that
you're
already
using
is
just
going
to
to
save
you
in
more
time,
so
that
you're
not
trying
to
figure
out
how
to
share
data
in
between
those
tools
and
then
the
last
one
is
great
documentation
again.
This
one
is
also
pretty
self-explanatory.
C
You
don't
want
to
spend
a
lot
of
time.
You
know
diving,
through
Stack
Overflow
for
a
month
figuring
out
how
to
set
up
your
CI
tool
when
you
should
be.
You
know,
writing
code
for
your
project,
so
the
other
thing
we
learned
is
that
CI
is
managed
by
maintainer
x',
so
86%
of
our
users,
based
on
our
sample
size,
were
maintainer
x'
of
an
open
source
project
and
then
89%
of
those
actually
managed
the
CI
config
for
the
project.
C
C
C
Then
you
also
want
tight
integration
with
your
VCS,
because
you
don't
want
to
spend
time
mirroring
permissions
from
your
VCS
over
into
a
CI
tool.
It's
easier
if
you
can
just
get
set
up
with
something.
That's
just
going
to
automatically
take
all
of
your
user
permissions
from
your
VCS
that
you've
already
spent
time
setting
up
and
move
that
over
into
your
CI
tool.
Without
you
having
to
do
any
more
work
and
then
finally,
secrets
management
is
also
a
huge
one,
if
you're
a
project
that
is
using
any
kind
of
secrets,
maybe
for
deployment.
C
C
Excuse
me
are
contributing
to
projects
that
only
have
one
to
ten
users,
and
then
you
know
a
little
bit
a
little
bit
in
the
11
to
50
user
range.
And
then
you
know
we
have
some
of
these
projects
that
are
really
big
over
over
50
users.
Up
to
you
know
over
500,
but
most
of
them
are
in
that
1
to
10
range
and
they're.
C
You
know
gaining
value
about
abusing
CI,
even
at
that
that
small
level-
and
that's
it's
really
interesting-
to
see
me
able
to
see
that
that
you
know
these
projects
are
adopting
circle
CI
at
the
beginning
of
the
process
and
then
scaling
it
all
the
way.
Up
to
these
really,
you
know
huge
projects
with
over
500
contributors,
and
so
CI
really
should
be
scalable,
and
you
should
be
thinking
about
that
at
the
at
the
lowest
level.
You
know
when
you're,
starting
with
you
know
one
to
ten.
C
You
know,
maybe
you
only
have
four
people
contributing
to
your
project,
but
you
still
want
to
be
thinking
about.
How
is
your
CI
going
to
scale
as
your
project
becomes
more
popular,
and
you
know
it's
always
easier
to
implement
good
CI
practices
when
you're
that
small,
rather
than
you
know,
trying
to
rip
out
your
old
system
and
put
in
something
new
once
you
realize
that
it's
no
longer
gonna
be
scalable
for
a
large
project.
So
what
you
should
look
for
here
is
powerful
orchestration
capabilities.
C
So
you
know
those
those
tools
that
are
going
to
make
it
really
easy
to
still
make
a
powerful
testing
framework
when
you
grow
from.
You
know
that
to
users
up
until
you
know
100
contributors
and
then
another
thing
is
that
declarative,
syntax
and
that's
just
because
it's
going
to
be
a
lot
easier
for
new
contributors,
the
project
to
see
what's
going
on,
and
you
see
I
tool.
If
you
have
it
declarative
syntax,
it's
a
lot
easier
to
get
lost
in
in
you
know
complicated
scripting
than
it
is
to
get
lost
in
something
like
Yamma.
C
C
C
B
You
vivec,
and
so
you
know
best
practice
number
one
that
we've
seen
is
is
you've
got
decisions
you
can
make
around
what,
whether
to
build
every
single
commit
for
your
project
or
whether
to
build
only
pill,
pull
requests
and
a
lot
of
times
this.
This
really
does
come
down
to
decisions
that
you
make
in
terms
of
how
frequently
you
want
the
the
testing
tour
to
occur
and
and
how
I
guess
how
aggressive
you'd
like
to
be
on
validating
every
change
that
comes
into
the
system,
one
of
it.
B
So
what
we
see
across
a
lot
of
open
source
projects
is
that
folks
do
configure
these
to
only
run
on
pull
requests
and
so
that
there
may
there
might
be
testing
and
running
on
Forks
or
other
areas
and
every
single
commit.
But
the
project's
configuration
for
testing
and
for
continuous
integration
might
be
generally
often
set
up
to
only
went
on
on
pull
requests,
and
so
that
only
when
I,
when
contributions
have
reached
the
stage
where
they're
ready
to
be
considered
by
the
broader
community
are
the
are
the
test
Suites
being
being
executed
in
full?
B
This
is
you
know.
Obviously,
this
is
that
you
know
this
is
a
trade-off
decision,
because
you
get
a
lot
of
value
on
testing
on
every
commit
as
well.
But
this
is
one
of
those
areas
that
there
becomes
a
tipping
point
in
the
growth
from
the
size
of
a
project
where,
where
that
decision
may
become,
you
know
a
necessary
change
for
the
project
to
make
where,
as
a
lot
of
folks,
what
we
see
is
they
start
out
with
running
their
their
configuration
and
their
testing
on
all
commits.
B
But,
as
the
community
starts
to
grow,
the
number
of
contribution
contributors
and
contributions
commits
grows,
they
hit
a
point
where
they
realize
that
it's
it's
more
effective
for
the
organizer
for
the
entire
community
to
run
these
only
poll
requests.
So
so
that's
one
of
the
things
that
we've
seen.
The
second
thing
that
we've
seen
come
up.
You
know
pretty
much
on.
Every
single
project
is
how
you
manage
secrets
and
clearly
having
an
intentional
approach
to
managing
secrets.
B
If
they,
if
they're
performing
testing
but
not
deployments.
Often,
this
is
not
such
a
high
priority,
but
if
they're
performing
deployments
out
into
integrated
test
environments,
for
instance,
it's
then
then
this
becomes
a
growing.
It
grows
and
importance.
It
becomes
an
important
element
for
the
projects
and,
at
that
point
typically,
what
project
maintainer
is
go
on
to
do
is
is
restrict
access
to
certain
secrets
and
environment
variables.
B
Probably
the
most
common
one
would
be
based
on
branch,
and
so
whether
or
not
it's
a
feature
based
branch
or
whether
it's
commit
to
master
often
involves
a
different
set
of
testing
and
activities
to
be
performed,
and
that's
probably
the
most
common
condition
based
testing
that
we
see,
we
also
see
differences
being
being
used
on
whether
it's
a
commit
or
whether
it's
a
full
request.
Also
one.
B
That's
a
real
common
one
that
folks
that
folks,
use
and
open
source
projects
is,
is
evaluating
what
changed
from
a
previous
commit
to
this
commit
and
deciding
what
what
to
execute.
And
then.
Lastly,
there
we've
even
seen
ones
where
folks
are
using.
You
know
the
person
who
can
who
triggered
a
pipeline
to
determine
what
sort
of
things
to
perform
there
as
well.
B
There
were
some
basic
housekeeping
that
was
desired
to
be
in
place
before
going
through
all
that
that
more
expensive
processing
and
so
providing
a
first
step
in
a
pipeline
to
preform
linting
checks
or
to
evaluate
commit
messages
and
make
sure
that
they
meet
up
with
standards
that
you
set
up
for
your
project,
really
to
create
the
hygiene
elements
upfront
in
the
process
and
only
proceed
to
the
more
advanced
testing.
After
passing,
those
initial
tests
becomes
the
really
nice
best
practice
that
we've
seen
people
execute,
and
so
in
that
particular
project.
B
They're
thinking
about
the
hygiene
of
that,
particularly
as
more
and
more
members
of
the
community,
start
contributing
to
it.
The
next
one
that
we've
seen
here
is
you
know
enabling
the
ability
to
run
tests,
Forked
repositories
or
to
build
pull
repack
pull
requests
that
have
come
from
fork
repositories,
one
of
the
nice
things
about
about.
That
is
that
you
could
actually,
as
you
start
to
scale,
you
can
actually
employ
a
fork
fork
strategy
where
contributors
are
essentially
requested
to
fork
the
project
and
be
developed
lean
on
their
on
their
local
accounts
or
their
own
accounts.
B
You
know
itself
at
that
master
branch
layer,
and
so
the
ability
to
do
that
and
essentially
have
users
have
the
freedom
to
be
testing
and
can
and
and
committing
frequently
before
they
come
back
to
the
community
and
issue
those
those
those
changes
back
to
the
community.
You
know
now
has
been
a
has
been
a
practice
that
we've
seen
folks
use
pretty
frequently
as
well.
B
So
you
know
one
of
the
one
of
the
elements
about
testing,
particularly
as
you
start
to
really
build
up
the
maturity
of
the
testing,
that's
being
performed,
as
I
mentioned,
that
project
that
had
gotten
up
to
thirteen
thousand
unit
tests.
All
of
a
sudden,
the
length
of
time
that
it
takes
to
execute
tests
becomes
quite
important,
and
so
there
are
a
variety
of
strategies
that
can
be
employed
on
a
CI
CD
system
that
will
help
you
really
focus
on
bringing
down
those
those
those
times
and
those
durations
and
with
them.
B
You
know,
for
instance,
I
mentioned
that
project
with
13,000
unit
tests
that
one
I
think
in
the
end
ended
up
paralyzing
tests
across
20
different
parallel
processes
to
to
really
shrink
the
testing
time
by
one.
You
know
fight
to
make
it
one
twentieth
of
what
it
was
before
when
running
on
a
single
node,
for
instance.
B
So
so
those
are
six
practices
that
we've
seen
open-source
projects
you
know
effectively
put
to
use
and
and
once
some
of
them,
which
have
a
little
bit
of
a
view
to
the
future
when
they
start
to
see
that
they're
scaling
at
a
pace
that
we're
they're
going
to
get
many
contributors
participating
in
their
in
their
project
and
in
their
community
simultaneously.
So
with
that,
that's
where
we're
going
to
end
today's
presentation,
but
throw
it
open
for
questions.
A
C
Guess,
while
we're
waiting,
one
of
the
the
common
questions
I've
received,
is
how
do
I
actually
know
what
I'm
going
to
need
when
I
start
scaling
to
a
larger
project,
because
if
you've
never
worked
on,
you
know
a
huge
open-source
project
and
you've
you've
never
run
CI
for
a
big
open-source
project.
You
you've
never
really
experienced
what
you
you
are
going
to
need
to
be
able
to
do
with
CI.
C
At
that
point,
so
one
of
the
suggestions
I
would
have
if
you're
in
that
situation
is
try
to
find
some
open
source
projects
that
are
already
pretty
big
that
are
out
there.
That
are,
you,
know
somewhat
similar
in
in
type
to
the
one
that
you
are
building
and
see
what
their
CI
configuration
looks
like.
You
know,
see
what
tool
they're
using
see
what
they
have
set
up,
because
that
could
be
a
good
indicator
of
what
you
may
need
down
the
road
once
you
start
growing.
B
Okay
thanks,
it
looks
like
we
did,
get.
Also
a
couple
questions
come
in
here
from
Nick
when
it
comes
to
infrastructure
as
code
versus
just
your
application
code.
Do
you
see
differences
in
how
you
look
at
CI
or
CD,
notably,
you
know
with
terraform
kubernetes
is:
do
you
are
able
to
create
load,
balancers
clusters,
services
and
even
routing
rules
as
yamo?
Do
things
change
between
these
lines
of
code
versus
application
logic,
great
question:
what
we
see
has
become
an
increasingly
common
use
case
on
CI
CD
is
the
validation
of
changes
to
infrastructure
as
code
right?
B
So
before
executing
a
a
far-reaching
change,
for
instance,
into
in
a
production
environment
that
might
might
get
5,000
servers,
those
changes
can
first
be
validated
against
policies
that
have
been
configured
and
essentially
defined
by
the
organization.
So
we're
seeing
that
to
be
become
a
really
nice
way
to
add
this
level
of
maturity
into
managing
the
infrastructure
as
code.
B
All
of
it
is
code,
all
of
it
can
be
tested
for
what
you
expect
to
be
changed
and
implemented,
and
how
you
expect
it
to
work
and-
and
there
seems
to
be
a
lot
of
great
new
third-party
tools
coming
out
that
allow
you
to
validate
those
changes
as
part
of
your
CI
CD
next
question
from
Harish:
what's
the
best
stage
to
do
performance
testing,
and
so
this
is
one
that
you
know,
there's
differing
opinions
on
here.
The
one
that
we've
seen
probably
the
most
frequently
is.
B
It
does
come
later
in
the
pipeline
flow
after
because,
ultimately,
here
you're
trying
to
get
to
a
point
where
you
know
you
validated
and
you've
got
code
that
you're
now
pretty
sure
you
want
to
put
into
production.
And
now
you
want
to
make
sure
that
that
last
set
of
problems
that
might
occur,
which
are
ones
you
don't
see
until
you
test
it
at
scale,
aren't
gonna
show
up
in
production
right
because
you
can
get
you
can
test
it.
B
Now
that
make
that
type
of
replication
doable
within
your
CI
CD
systems.
But
it
usually
comes
at
the
end,
and
it
comes
at
the
point
because
it
generally
doesn't
involve
a
significant
testing
load
as
well.
It's
one
that
you
want
to
make
sure
you're
ready
and
it's
the
last
stage
before
production,
and
so
that's
typically,
where
we
see
it
come
up
in
and
folks
will
will
make
sure
they've
done
all
the
other
validations.
They
know.
This
is
a
piece
of
functionality
that
they're
ready
to
put
in
front
of
customers.
B
B
Okay,
here
comes
another
one:
thoughts
on
the
cloud
delivery
framework,
a
notably
sea-ice
position
or
just
over
all
thoughts
foundation.
That's
what
I
thought
you
meant
there,
so
so
with
a
continuous
delivery
foundation,
which
is
a
new
foundation,
much
like
the
CN
CF
that
has
recently
launched
it,
launched
in
March
at
the
open
source,
Leadership
Summit,
and
and
has
an
initial
set
of
four
projects
that
are
now
part
of
the
foundation
and
are
are
coming
together
with
the
first
set
of
meetings
and
the
community
is
starting
to
build.
On
top
of
that.
B
So
the
CF
looks
to
looks
like
it
should
be:
a
very
useful
mechanism
law,
a
lot
like
CN
CF,
to
coordinate
around
standards
and
particularly
standards
for
interfaces
between
the
different
tools
and
and
tooling
that
that
exists
for
for
continuous
delivery,
CIN
CD,
you
think
back
to
that
that
earlier
slide,
where
we
were
talking
about,
there's
really
these
three
major
pillars
that
exist
in
when
you
do
software
right.
There's
the
creation
and
collaboration
around
code.
There's
everything
that
you
do
around
validation
valid.
B
You
know
building
and
testing
and
delivering
that
software
to
users
and
then
there's
the
runtime
environments,
where
software
is
run
in
a
production
environment
and
has
to
be
monitored
and
and
and
and
probably
you
know,
attended
to
it.
You
know
in
that
runtime,
environment
and
so
that
in
and
then
when
you,
and
so
when
you
look
between
those
three
pillars,
there's
interfaces
between
those
three
pillars
that
the
greater
we've
got
standardization
around.
B
How
you
can
communicate
across
those
those
pillars,
the
better
off
everybody
is
going
to
be
because
then
you
can
plug
and
play
different
tools
and
and
different
strategies
easier.
The
second
thing
is
that
when
you
look
within
that
middle
pillar
of
are
what
happens
within
CICP,
there's
many
different
tools
that
we
mentioned
that
get
brought
to
play
inside
your
CI
TD
processes.
B
And
so
we
really
do
see
the
CDF
providing
a
great
function
there
in
defining
those
standards.
And
the
second
thing
is
just
the
separating
it
out
as
its
own
as
its
own
foundation
as
opposed
to
making
it
part
of
the
CN.
Cf
really
does
call
out
the
importance
of
that
middle
pillar
of
how
important
it
is
that,
as
a
community
in
the
software
world,
we
all
get
to
a
higher
and
higher
level
of
maturity
in
our
ability
to
build
out
and
test
and
validate
the
the
value
that
we're
putting
in
front
of
customers
all
right.
B
So
now
we
have
a
question
from
Anthony.
In
here,
what
are
the
triggers?
You
see
that
caused
teams
to
move
from
an
imperative
model
of
pipeline
configuration
like
full
programming
languages,
to
more
declarative
models
like
yellow
any
pitfalls
or
things
to
be
aware
of
when
making
this
transition.
Yeah
great
question,
actually
the
one
of
the
reasons
you
move
to
something
like
yamo.
Ultimately,
a
declarative
model
is
to
simplify
right
to
make
it
so
that
it's
easier,
it's
it's
more
easily
understood,
so
it
can
be
transitioned
across
team
members.
B
B
So
if
you've
declared
something
that's
covered
by
a
a
that's
configured
to
perform
a
certain
way
behind
the
scenes
based
on
that
declaration,
then
everything
is
great,
but
as
soon
as
you
want
to
perform
something
that
gets
very
imperative
where
you
wanna
you
wanna,
you
want
tremendous
control
over
what
it
actually
occurs
and
it
goes
beyond
what
the
declarative
use
cases
are
supporting.
Then,
of
course,
then
you
want
to
go.
B
You
want
the
capabilities
to
go
to
an
imperative
model,
and
so
what
we
always
see
here
at
circle
and
what
we
see
across
you
know
to
be
to
be
the
model
that
no
matter
what
anybody
says
says
you
know
in
you
know,
in
a
public
statement
in
the
end,
what
we
always
see
is
people
want
it
to
be
simple
until
they
don't
they
want
it
to
be
simple
and
and
easy
to
do
for
the
most
common
use
cases,
but
as
soon
as
there's
a
specific
need
where
they
need
total
control.
People
want
that
total
control.
B
So
ultimately,
we
always
believe
that
the
best
model
is
one
that
brings
those
two
worlds
together.
That
allows
you
to
be
declarative
for
the
most
common
actions
and
use
cases,
so
things
that
you're
gonna
perform
exactly
the
same
way
that
someone
else
is
going
to
perform.
Those
things
don't
need
to
be
defined
imperative
ly
every
single
time.
Those
can
be
done,
declaratively,
preferably
through
reuse
of
that
declarative
configuration.
B
But
as
soon
as
you
have
specific
items
that
are
applicable
to
your
project,
you
want
that
ability
to
go
and
do
imperative
activities,
and
so,
ultimately,
in
your
CI
CD
system,
you're
gonna
want
to
look
for
one
that
let
you
do
both
and
I
think
that's.
You
know
a
really
important
detail
that
sometimes
isn't
isn't
thought
of
you
know
up
front
when
deciding
on
where
to
go,
but
in
the
end
that's
the
one
we
see
over
and
over
again
come
come
to
light.