►
From YouTube: CDF SIG Best Practices - June 27, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
So
I
don't
know
if
we're
gonna
be
joined
by
anybody
else.
A
Today
I
haven't
heard
anything
from
from
tara,
but
she
might
be
joining
us
in
a
in
a
little
while
we
can
probably
spend
a
little
bit
of
time
today
talking
about
the
jenkins
x
side
of
things,
because
it
would
certainly
be
good
to
start
to
set
out
some
reference
implementations
of
some
of
these
best
practices,
and
you.
A
Yeah,
so
let
me
just.
A
So
what
we've
got
in
here
is
a.
A
A
series
of
different
sections,
where
you
know
we're
we're
trying
to
encourage
the
development
of
this
best
practices
site
with
additional
content.
So
obviously
the
the
primary
content
is
is
in
the
learn
section.
A
But
also
to
in
the
community
section
to
actually
have
some,
if
you
like,
worked
examples
or
references
from
community
projects
showing
how
how
we
can
leverage
those
tools
to
to
actually
build
on
best
practice.
Yep.
C
B
A
Yeah,
so
it
I
think
it's
it's
relatively
straightforward
in
in
in
terms
of
all
of
the
the
beats
that
it
touches
on,
but
it's
not
necessarily
obvious
to
everybody
how
you
get
from
a
theoretical
understanding
of
what
needs
to
be
done
to
actually
having
an
implementation
of
that
that
will
serve
a
team
or
an
organization.
A
Now,
obviously,
jenkins
x
already
does
a
large
chunk
of
what
we've
got
in
best
practices,
but.
D
A
From
the
opposite
problem,
which
is
that
you
know
it's
a
magic
thing
that
you
install
and
then
you
need
to
spend
the
next
two
years
working
out
what
it
can
do
for
you,
because
it
does
so
much
that
it's
you're
almost
discovering
its
capabilities
by
accident
by
stumbling
across
them.
Rather
than
having
a
a
clear
vision
for
how
the
tool
is
going
to
support
you
in
your
business
needs.
B
Yeah
absolutely
and
that's
about
documentation
for
one
thing-
and
you
know,
there's
also
some
unknown
code
here
and
there's
somebody
need
to
kind
of
get
get
into
it
and
try
to
align
with
with
how
you
define
continuous
delivery
and
how
to
solve
that
and
then
see
see
how
jenkins
x
lines
up.
So,
I
think
for
continuous
integration.
B
I'll
have
to
look
closer
at
that,
but-
and
I
know
there's
one
thing
that
we
don't
do
and
that
is
with
with
youtube's
drift
detection.
Is
that
part
of
this
guide
as
well
or
is
that
we
do
consider
that
outside.
A
So,
that's
not
something
that
we've
gone
into
great
detail
on
at
the
moment,
but
it's
it's
likely
to
be
something
that
we,
you
know
develop
over
time
as
as
as
we
refine
what's
there
at
the
moment.
A
So
I
I
think
you
know
a
a
good
first
step
really
would
be
to
to
have
some
sort
of
you
know,
white
paper
that
would
map
the
basic
concepts
that
are
in
the
best
practices
guide
onto
capabilities
within
the
jenkins
x
platform
and
and
that
that
can
be
done
in
in
a
sort
of
narrative
style.
So
it
can
be
relatively
conversational
and
it
probably
needs
to
be
done
at
a
different
level.
C
C
A
Contribution
on
on
this,
one
is
pretty
straightforward:
the
the
whole
site
is
within
the
cdf
github
repos,
there's
a
best
practices
site
repo,
and
you
can
just
submit
prs.
C
B
Yeah,
you
know,
I
think
that
I
can
manage
to
to
do
this.
This
will
also
be.
B
I
think
this
will
also
align
with
my
company.
How
are
they
want
to
want
to
work
with?
You
know
best
practices
and
and
kind
of
be
aligned
on
things
like
agile,
agile,
work
management,
work
modes.
A
I
think
from
a
cdf
perspective
it
it
would
be
a
really
worthwhile
thing
to
be
doing,
because
it
looks
like
the
focus
this
here
is
going
to
be
on
you're,
trying
to
get
more
reference
examples
of
all
these
patterns
and
start
to
tie
together.
The
work
that's
been
done
previously
so
that
it's
easier
for
people
to
get
from
a
theoretical
understanding
to
you.
C
D
Hello,
yeah
hi
everybody-
I
missed
the
best
practices
session
at
cdcon
just
ended
up
having
loads
of
flight
problems,
so
I
just
saw
the
videos
were
posted
today,
so
I'll
go
check
it
out,
but
I
was
wondering
what
the
quick
summary
of
how
it
went
was.
A
D
Yeah
cool
yeah,
looking
forward
to
catching
up
with
that
yeah
just
been
out
for
a
while,
so
just
in
general,
catching
up
with
the
state
of
things
and
seeing
where
I
can
help.
A
Yeah,
well
certainly,
things
are
seem
to
be
moving
fast
on
the
supply
chain,
security
side
of
things,
so
it
would
be
good
to
to
keep
the
documentation
at
pace
with
the
the
evolution
of
you
know,
best
practice
and
solutions
out
there
in
the
marketplace.
A
So
I
I
don't
know
if
there's
anything
that
you
you
might
be
able
to
put
together
from
a
you
know,
white
paper
perspective
that
we
can
include
in
the
community
section.
D
Yeah,
that's
a
good
question,
like
maybe
one
thing
that
springs
to
mind
is
I
have
a
colleague
who
is
in
the
kubernetes
community
and
I've
seen
him
give
a
talk
around
like
how
they
to
use
the
salsa
levels,
to
incrementally
kind
of
evaluate
where
they
want
supply,
chain
security
and
then
work
through
what
they
could
fix
and
improve
like
adding
s-bombs
and
then
code
signing
and
and
all
the
different
things
they
tackled
and
the
problems
they're
they're
hitting.
A
Yeah,
I
think
I
mean
recently
I've
I've
seen
you
know
a
number
of
demos
from
people
who
are
building
practical
solutions
in
the
space
and
and
the
challenge
always
seems
to
be
with
those
demos
that
there's
a
an
abstract
talk
at
the
beginning,
about
all
the
scary
things
that
can
happen
to
your
supply.
D
A
And
then
there's
a
demo
of
magic
happening,
but
there's
a
huge
gap
in
the
middle
of
of
the
whole.
What's
what
are
the
concepts?
What's
the
mindset?
A
How
do
you
actually
need
to
approach
this
from
a
practical
perspective,
and
you
know
where
do
certain
tools?
Add
value
in
in
this
whole
puzzle
yeah,
so
it
would
definitely
be
good
to
get
some
some
content
in
there
that
that
goes
from
the
you
know.
The
abstract
theory
that
we
we've
got
on
the
on
the
best
practices
learn
side,
yeah.
D
Yeah
and
I
wonder
if
we
can
get
some
of
the
tact
on
folks,
they
were
talking
about
the
practical
ways,
they're
trying
to
improve
techton
from
a
supply
chain
security,
and
I
think
there
was
a
talk
or
I've
seen
a
document
where
they
sort
of
go
through
all
the
different
criteria
and
things.
I
wonder
if
that
that
would
be
a
nice
practical
example
to
include
somehow
yeah.
C
A
D
A
A
C
C
B
He
is
starting
this
week,
I
think
for
next,
so
we
will
see
what
what
what
he
can
can
do
for
us
if
it's
tactile
chains
or
something
else.
A
And
feel
free
to
loop
him
into
the
best
practices,
discussion
or
pointing
at
the
documentation
so
that
you
know
we
we've
got
some
continuity
of
concepts
and
spanning
across
could
be
nice
to
work
from
from
that
best
practice,
almost
like
a
set
of
high
level
requirements
and
and
then
drill
down
into
actual
capabilities.
B
A
A
Okay,
well,
it
doesn't
look
like
anyone
else
is
going
to
be
joining
us.
A
So
I
I
think
we're
we'll
continue
with
the
current
schedule
of
meetings,
because
it
would
be
nice
to
keep
the
momentum
going
and
you
know
try
to
fill
out
the
gaps
that
we've
currently
got
in
in
the
documentation
set.
D
A
A
You
know,
because
we
are
we're
mostly
there
with
the
the
the
general
best
practice
and
we
can
go
into
more
sort
of
maintenance
mode
on
that
now.
A
But
really
the
the
important
piece
for
this
year
will
be
about
aligning
all
of
the
all
the
projects
within
the
cdf,
so
that
they've
all
got
a
connection
from
best
practice
through
to
implementation
on
those
projects
and
then
there's
also
a
lot
of
opportunity
for
members
to
get
involved
in.
You
know:
writing
white
papers
about
how
they're
solving
particular
problems
in
their
organizations
or
with
with
clients,
and
so
we
get
a
much
broader,
much
more
inclusive
view
of
how
to
approach
the
challenges.
C
A
Evangelizing
back
amongst
the
the
cdf
membership
to
you
know
encourage
people
to
think
about
contributing
at
a
different
level.
Now.
A
Yes,
they're
they're
still
on
the
same
schedule
as
they
were
previously
they'll,
probably
move
time
slot.
Once
the
two
new
members
are
elected,
there's
going
to
be
another
vote
on
when
it
will
occur,
but
other
than.
D
D
The
current
slot,
but
that'd
be
interesting
if
they
change.
A
Yeah,
so
I'm
not
sure
when
when
that
election
completes-
but
I
imagine
it's
it's
sometime
in
the
next
week
or
so,
there
will
be
a
a
new
vote
on
times
as
soon
as
that.
C
A
Okay,
well,
I
think
in
that
case,
I'll
give
everybody
the
rest
of
their
time
back
and
we'll
speak
again
in
a
couple
of
weeks.
Time.
B
I'm
just
kind
of
thinking
about
this
whole
idea
of
continuous
delivery
and
kind
of.
B
I
think
you
touched
about
it
in
there
or
one
of
the
documents
are
about
the
difference
between
when
you,
if
you,
if
you,
if
you
know
something
or
you
believe
you
have
found
something
to
be
true-
and
you
want
to
implement
that
that's
one
mode
and
another
mode
is
when
you're
kind
of
you
know
that
this
kind
of
more
vague
area,
you
don't,
you
are
more
unsure
of
the
territory
what
to
do
so.
I
think
that's
gonna,
if
you
ideally
idealize
these
two
modes,
one
of
them
is
the
classic
waterfall
model.
B
Where
you
actually
know
everything
or
you
believe
you
know
everything
in
front.
Sometimes
you
can
actually
know
quite
a
lot,
but
not
everything
but
other
times.
You
know
a
lot
less.
So
you
know
in
the
one
one
mode
of
devices
for
experimentation,
and
I
order
for
more
stability,
yeah
understand
where
I'm
going.
A
It
doesn't
give
you
many
of
the
benefits
in
in
return,
because
you
just
don't
get
that
massive
acceleration,
because
the
the
rest
of
the
organization
is
effectively
fighting
against
the
optimizations
within
the
the
technology.
A
A
So
so
that's
why
that
stuff
is
really
important,
because
for
many
organizations,
if
they,
if
they
genuinely
need
to
go
faster
in
order
to
survive
as
an
organization.
C
A
B
I
totally
get
those
differences
you're
talking
about
there,
but
but
even
within
one
project
you
could
have
like
you
create.
You
know
you
need
to
sell
tickets
and
I
have
a
feature
that
sets
the
price
on
the
ticket
and
I
allow
it
to
sell.
B
But
you
can
have,
you
know,
do
experiments
on
top
of
this
again,
where
you
don't
necessarily
have
the
same
demands
to
to
you
know
stability
or
test
coverage
or
even
security.
Perhaps.
B
C
C
A
A
And
so
what
happens
is
that
they
they
invest
a
lot
of
time
and
money
in
buying
new,
tooling
and
setting
up
the
teams
and
training
the
teams
and
then
what
they
find
is
they're.
Not
getting
the
user
stories
into
the
system
fast
enough
cadence
to
to
keep
the
pipeline
full
and
then
they're
getting
to
the
point
where
the
coding
and
testing
on
something
is
done
and
they
want
to
put
it
into
production.
A
B
Yeah
yeah,
I
understand
where
you're
going
now,
it's
about
simply
yeah
structuring
the
organization
to
allow
rapid
change
and-
and
that
also
means
kind
of
something
about
the
you
know.
You
can't
have
all
this
sign
of
five
six
different
departments
and
all
that
you
have
to
be
give
more
responsibility
to
to
the
ones
who
are
closest
to
the
to
the
the
the
product
and
the
market
and
the
the
code.
All
of
that
and
yeah,
I'm
actually
thinking
that
yeah.
B
I'm
thinking
about
my
colleague
as
an
agile
coach
is
talking
about
the
methodology
which
is
called
titles
type,
which
is
about
which
often
teaches
to
government
organizations
in
norway
and
abroad,
not
very
much
that
about
how
we
should
make
sure
to
define
a
vision.
First,
where
you
give
give
the
employees
an
idea
what
they
want
to
achieve,
and
then
we
let
them
loose
to
solve
the
problem
and
after
they
have
returned
with
the
solution.
B
A
All
of
your
employees
are
motivated
by
the
value
of
the
company,
because
the
salary
is
not
very
good,
but
you
stand
to
to
make
all
of
your
rewards
on
the
exit
price,
so
so
the
more
effective
the
company,
the
higher
its
valuation
and
and
the
the
higher
the
value
it
will
exit
at
so
so
ever
everything
is
focused
on
the
price
of
the
shares,
which
means
that
everyone
is
highly
motivated
to
do
whatever's
necessary
to
maximize
the
customer
experience
so
that
you
get
more
customers.
You
retain
your
customers
longer
and
you
get.
You
know.
C
A
Now,
if
you
look
at
a
a
conventional
mature
enterprise
with
a
long-term
product
or
a
government
department,
that's
trying
to
solve
a
particular
social
problem.
A
So
once
a
year
you
set
out
all
of
this
strategy.
You
set
out
all
of
the
rewards
for
everyone
on
the
team
based
on
that
strategy,
and
then
you
send
them
out
to
go
and
do
it
now.
If,
at
that
point,
people
working
closely
with
the
customer
discover
that
the
customer
doesn't
want
what's
in
the
strategy.
A
A
There
is
that
the
employees
will
often
start
to
sabotage
the
people
who
are
trying
to
solve
customer
problems
because
they
know
that
they
won't
get
their
bonuses
if
they
don't
deliver.
The
milestones
that
are
in
the
plan,
and
so
the
plan
suddenly
conflicts
with
business.
Success
and
the
majority
of
your
staff
tend
to
opt
to
sticking
to
the
plan
rather
than
solving
the
business
problems.
C
A
Then
then,
what
happens
is
that
you
get
this
your
internal
corporate
antibodies,
where
the
the
organization
fights
change,
because
it's
incentivized
not
to
change.
B
That's
a
very
interesting
thoughts
and
on
discussion,
and
exactly
these
or
similar
discussions
about
loyalty
and
how
actually
loyalty
can
be
a
really
bad
things
in
the
situation.
You
just
described
very
loyal
to
the
goals
of
your
business
or
to
your
boss
to
bosses
goals,
but
when
those
goals
are
actually
detrimental
to
the
customers
or
to
deliver
the
whole
business,
then
you
have
to
the
right
thing
would
be
to
be
loyal
and
help
a
lot
of
business
and
the
customers.
B
But
that
depends
on
the
culture,
of
course,
and
really
it
doesn't
have
to
be
the
money
reward.
Also
in
norway,
we
have
the
largest
social
security
government
agency.
B
They
are
using
this
method
and
there
are
small
small
teams
with.
A
Yeah,
you
can,
you
can
work
around
the
problem,
but
you
you
have
to
recognize
that
the
the
culture
of
your
organization
is
directly
linked
to
your
capability
to
iterate,
fast
or
slow,
and
so
really
the
bulk
of
continuous
delivery
as
a
methodology
sits
in
the
business
space
rather
than
in
the
tooling
space
yeah.
A
Now,
what's
really
nice
about
the
tools
like
jenkins
x
is
their
ability
to
provide
a
very
simple
path
into
that
new
methodology
by
lowering
the
barrier
to
entry?
A
Now
the
jenkins
x
is
nice
because
it
bundles
up
most
of
that
complexity
and
hides
it
at
the
beginning.
So
so
you've
got
something
that
you
can.
You
can
deliver
into
an
organization
and
it
initially
puts
you
on
rails.
So
you
know
as
long
as
you've
you
follow
the
way
of
working
you're,
getting
all
of
the
main
benefits
of
using
that
cloud
native
infrastructure
without
having
to
understand
how
any
of
it
is
wired
up
yeah
and
then,
as
you
start
to
want
to
do
more
complicated
things
in
your
application.
A
A
A
But
then
you've
got
this
lower
level
piece,
which
is
oh.
We
want
to
be
able
to
follow
best
practice,
but
we
have
a
preference
in
terms
of
the
infrastructure
that
we're
using
or
a
particular
piece
of
tooling
or
a
particular
vendor,
and
so
that's,
where
being
able
to
plug
different
components
in
makes
it
easier
for
some
customers
to
to
adopt
because
they
have
hard
stops
in
terms
of
you.
C
A
What
their
enterprise
architecture
allows
in
in
terms
of
tooling
so
yeah
you'll
find
a
a
lot
of
organizations
will
be
heavily
microsoft
constrained,
and
so
you
know
it's.
It's
not
just
a
case
of
being
able
to
operate
on
an
azure
platform,
but
you
need
to
actually
be
able
to
tie
into
a
lot
of
that
microsoft,
tooling.
C
A
For
the
business
to
feel
comfortable
authorizing
it
all
right,
so
in
many
cases
it's
it's
a
cultural
problem
again,
but
couched
in
in
in
vendor-specific
terms,.
A
And
again,
it's
it's
one
of
those
cases
where
you've
always
got
to
remember
that
you've
got
two
demographics,
that
you're
addressing
you've
got
the
the
new
users
who
want
to
be
supported
in
learning,
how
to
use
the
platform
and
then
you've
got
the
power
users
who
who
want
to
be
able
to
use
it
as
quickly
and
efficiently
as
possible,
and
usually
those
two
demographics
have
competing
needs.
B
Yeah,
I
think
that's
you
have
to
be
careful
with
with
that,
but
yeah
we
have
one
summer
student
is
working
on
the
software
supply
chain,
security
and
the
other
one
on
the
user
interface.
A
Yeah
I
mean
that
user
interface
problem
is
a
is
a
big
challenge,
because
jenkins
x
has
had
three
or
four
user
interfaces
now,
and
none
of
them
actually
ended
up
solving
the
underlying
problems
in
in
in
any
sort
of
complete
way.
A
So
it
is
a
big
rabbit
hole
that
you
go
down
because,
of
course
you
quickly
hit
the
ban.
That
problem
of
you
know,
where
is
the
boundary
between
jenkins
x
and
just
pure
kubernetes,
and
how
much
of
this
stuff
do?
We
need
to
control
from
this
user
interface
before
you
bounce
people
out
into
another
user
interface,
and
then
that
might
be
fine
for
your
expert
users,
but
then
you're
confusing
your
new.
C
B
Native
cabernet's
resources
out
of
out
of
it,
but
it's
kind
of
just
started
and
at
the
moment
it's
about
being
able
to
start
and
stop
pipelines
in
addition
to
viewing
the
logs.
So
it's
kind
of
proceeding,
step
by
step.
A
Yeah,
I
I
think
visibility
is.
It
is
always
going
to
be
a
key
part,
so
helping
people
to
quickly
understand
where
something
has
broken
it
is
is
very
useful.
C
A
Much
harder
to
to
provide
a
a
good
view
on
what's
happening.
A
And
then,
when
I
was
deploying
things,
I
would
be
able
to
observe
the
behavior
of
multiple
facets
of
the
system
and
then
see
where
stuff
had
got
stuck
fairly
easily,
because
you
you're
looking
from
50
000
feet
on
on
multiple
views.
D
A
You
you,
when
you've
got
these
deeply
nested
forking
processes,
you
don't
know
where
to
drill
into
until
you've
done
that
50
or
60
times
and
have
got
a
feeling
for
what's
going
on
and
where
it
breaks.
C
A
B
B
I
think
it's
it's
mostly
about
victim
power
plans,
errors
and
how
much
further
they
will
go
in
debug
or
in
logging,
or
nothing.
B
You
know,
I
can't
really
add
the
handling
or
things
like
dns
and
certificates,
and
all
that
into
into
the
same
ui.
That
will
be
kind
of
too
much.
A
Yeah,
in
my
experience,
pipeline
failures
were
actually
relatively
rare
and
so
the
the
the
most
common
failures
the
get
web
hooks
not
getting
through
or
not
triggering
correctly
certificates,
not
getting
provisioned
in
a
timely
manner,
and
you
know
basic
problems
with
you
know:
kubernetes
yaml
not
being
generated
correctly,
so
stuff
would
break
outside
of
the
system,
and
there
was.
It
was
very
hard
to
find
that,
because
often
it
was,
it
was
edge
cases
sitting
around
the
the
outside
of
the
system.
C
A
Wasn't
even
communicated
to
the
user
that
this
stuff
was
going
on
yeah,
so
you
needed
to
drill
into
some
obscure
bit
of
the
application
to
find
out
that
there
were
extra
logs
that
you
didn't
even
know
existed
in
modules
that
you
know
were
running
that.
A
Okay,
that
thing
was
sent
from
github,
but
it
didn't
arrive
or
I've
never
sent
it
so
that
those
those
types
of
problems
are
the
the
ones
that
most
people
get
stuck
on.
B
Yeah
I
was
when
we
were
talking
about
thinking.
Perhaps
we
could
add
some
trace
id
to
things,
but
I
don't
know
if
that's
even
possible
with
these
interconnected
systems.
C
A
The
tooling
into
a
git
ops
repository,
would
you
expect
certain
things
to
happen
in
the
near
future
in
other
areas
of
the
application
right?
So
then
you
can
start
to
design
monitoring
systems
that
are
making
assertions
about
expectations
and
then
tracking
to
see
if
they
happen
and
then
that
helps
you
to
then
build
smarter
systems.
A
That
say:
oh
well,
the
user
did
this
and
I
was
expecting
the
following
things
to
occur,
but
they
didn't-
and
I
I
know
at
the
the
first
point
of
which
I
should
I
should
have
some
activity
and
I
didn't
see
activity
there.
Therefore,
the
problem
is
upstream
of
that
and
you
can
then
tell
the
user
to
go
and
look
in
a
particular
area.
A
So
it's
it's
almost
like
it's
the
the
reverse
of
logging,
as
you're
going
along
it
it's
it's
saying
you
should
expect
to
see
a
log
generated
from
this
place,
but
that
log
never
arrived.
Therefore,
your
problem
is
in
this
area
and
you
need
to
go
and
investigate
that.
A
A
Okay,
well
feel
free
to
share
if
you
need
a
hand
with
anything.