►
From YouTube: CDF SIG Best Practices - Aug 22, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
C
So
when
it
comes
to
sort
of
the
some
of
those
things,
I
think
I
would
like
I'd
be
interested
in
kind
of
doing
a
little
bit
of
that,
but
also,
I
think,
there's
a
few
things
in
there
that
I
saw
that
might
be
useful,
because
I
also
have
a
background
in
working
at
a
lot
of
banks
and
so
no
understanding
sort
of
compliance.
Audit
legal
requirements
is
also
really
good
from
the
cd
sort
of
perspective,
and
then
you
know
my
other
thing
more
from
the
technical
side
is.
C
Yeah
agreed
on
that
that's
actually
separately,
something
that
that
also
very,
very
interested
in
is
like
that
sort
of
end-to-end
software
delivery,
life
cycle,
piece
of
that
sort
of
thing
of
like
what
goes
in
what
comes
out
and
not
just
purely
the
the
technical
side
of
it,
but
also
like.
Where
are
those
decisions
getting
logged,
and
you
know
like
the
thing
that
you
want
to
make
sure
of
right
is
just
as
an
example.
C
Nothing
with
a
an
incorrect
license
should
be
allowed
in
in
the
first
place
before
you
get.
You
know
like,
which
is
one
of
the
problems
right
is,
is
working
at
a
several
banks
that
sort
of
thing
gets
caught.
You
know
two
days
before
production,
you
go,
oh
wait,
there's
there's
some!
This
should
have
been
caught
earlier.
B
So
this
is
the
the
first
cut
across
this
reference
architecture,
and
this
part
is
just
about
establishing
who
are
the
players
in
any
given
organization
in
in
terms
of
needing
a
stake
in
that
delivery
process
on
what
are
their
views
and
viewpoints?
How
how
are
they
seeing
the
problem
what's
important
to
them,
because
when
we
move
on
to
the
next
step,
we're
going
to
be
looking
at
their
individual
concerns
and
how
those
need
to
play
into
the
automation
that
we
start
to
build
in
order
to
get
a
successful,
overarching
process.
C
B
Yeah
feel
free
to
have
a
stab
at
those.
If
you,
if
you
read
through
the
other
ones,
you'll
see
I've,
I've
taken
a
sort
of
style
for
structuring
them,
so
the
the
first
part
is
a
sort
of
third-party
description
of
what
the
viewpoint
is,
you
know,
what
does
this
general
rule
do
and
then
the
second
part
is
written
from
the
perspective
of
the
person.
B
B
B
C
C
C
Let
you
do
the
bad
thing
and
there's
stuff
like
dagger
io,
there's
things
that
are
kind
of
coming
out,
there's
like
one
or
two
other
ones
that
I
saw
that
are
similar
to
sort
of
like
dagger,
which
is
trying
to
say
oh
ploy,
ghost
from
red
hat,
which
sort
of
says
you
could
use
jenkins.
You
could
use
tekton
whatever,
but
here's
a
higher
level
abstraction
that
generates
those
ci
tools
and
also
tries
to
do
that.
C
Sdlc
kind
of
thing
like
what
you're
sort
of
describing
here
is,
you
know,
here's
the
best
practices
and
how
do
we
codify
that,
as
essentially
an
abstraction,
so
whether
it's
people
or
people
process
or
literal
automation?
For
that
thing,
how
can
folks
like
what
does
that
look
like
from
the
cd
foundation
perspective?
Just
to
give
you
the
summary.
A
C
A
Do
it
both
okay,
thank
you
and
then
how
do
you
think
sort
of
hijacking
this
right
now,
but
since,
since
you've
been
so
cooperative
to
to
talk
more
about
it,
how
do
you
think
this
should
sort
of
be
encompassed
all
these
new
tools
that
are
coming
out
that
are
really
interesting?
We
should
have
them
on
the
landscape
like
how
how
best
to
place
that.
C
I'm
not
sure,
that's
that's.
One
of
the
reasons
why
we
wanted
to
reach
out
regarding
this
is
it's
almost
like
some
folks
are
looking
at
codifying
the
software
delivery
lifecycle
as
itself
sort
of
an
abstraction
you
can
imagine
like
similar
to
if
you,
if
you've
ever
used
tools
like
servicenow
right
servicenow
lets
you
sort
of
develop
a
workflow
for
when
you
know
somebody
when
a
new
project
gets
spun
up.
C
These
are
the
things
that
happen
and
they
get
you
know
a
budget
and
they
get
a
naming
scheme
and
all
that
great
stuff
and
then,
when
they
go
into
get
ready
to
do
development,
you
know
they
automatically
get
like
a
github
or
whatever,
like
you
know,
code
repositories
and
then
when
they
go
to
deploy
to
staging.
This
is
what
that
looks
like
and
so
on
and
so
forth,
and
some
of
the
things
that
are
starting
to
kind
of
come
out
of
this
is
how
do
we,
like
you
know?
C
C
What,
if
you
just
sort
of
said
great,
it
checks
all
the
boxes
you
get
to
go
into
production
or
it
checks
all
the
boxes
which
allows
somebody
to
actually
click
the
button
to
send
it
to
production.
Those
sorts
of
things
of
like
codifying
that
at
some
level
is,
is
kind
of
where
that's
starting
to
to
go
and
I'm
not
sure
what
we're
calling
that.
But
that's
kind
of
the
way
that
we've
been
seeing
people
push.
B
Yeah-
and
I
I
think
this
is
quite
an
interesting
area
for
discussion,
because
it
it
really
touches
on
the
big
differences
between
the
cultures
of
the
two
different
types
of
organizations.
So
obviously
the
continuous
delivery
methodology
comes
from
that
lean
startup
model,
which
is
all
about
optimizing.
The
pace
at
which
you
can
do
experiments
in
real
world
environments.
B
So
it's
a
case
of
saying
we
expect
everything
to
blow
up
and
we
are
able
to
react
to
that
instantly.
Roll
something
back,
get
a
fix
in
place
and
roll
that
out
again
in
a
matter
of
hours
and
therefore
our
overall
business
exposure
is
actually
lower
than
in
a
situation
where
we've
been
very
risk-averse.
It
takes
us
six
months
to
deploy
something,
and
then
we
still
encounter
something
we
didn't
expect,
and
now
it's
going
to
take
us
a
year
to
get
a
fix
in
place
to
react
to
it.
C
Yeah
yeah,
that's
that
that
all
makes
sense
to
me.
I
I,
I
think,
that's
the
thing
that
we're
trying
to
also
get
across,
and
it's
something
that's
that's
coming
also
out
of,
I
think
a
little
bit
of
the
like
this.
This
space,
which
is
just
like
you're
you're,
also
starting
to
apply
zero
trust
rules
to
your
entire
sdlc.
C
Where
you're
saying
before
you,
you
were
doing
a
lot
of
just
different
things,
a
lot
of
very
risk-averse
things,
but
now
you're,
saying
hey,
you
can
actually
get
a
lot
of
lift
by
saying
who
is
who
is
actually
responsible
for
what
what
are
their?
You
know
what
we
trust
them
to
do
in
what
contexts
and
so
on.
To
then
be
able
to
sort
of
say
here
is
here's
how
we
can
safely
deliver
stuff?
B
Because
if,
if
you
segment
too
much,
then
you're
going
back
to
a
situation
where
you
need
a
different
team
for
every
function.
Each
team
has
its
own
set
of
roles
and
then
suddenly
you're
back
into
dependency
management.
Hell
again,
because
you
you've
got
lots
of
teams
working
in
isolation
and
you
no
longer
have
a
product
team.
C
So
I
think
that
was
the
just
to
tie
that
back
yeah.
So
I
think
that's
the
majority
of
the
stuff
from
from
the
landscaping
side
is
just
like
hey
as
we
build
out
the
best
practices.
I
think
it's
it's
like
some
of
what
we
you
know
even
just
sort
of
looking
at
the
organization.
It's
like
how
do
you
you
know?
How
does
one
begin
to
like
look?
You
know
once
we
figure
that
sort
of
stuff
out.
C
B
You
are
splitting
the
world
up
into
the
development
team
and
everyone
else
and
the
development
team
is
saying
this
is
ready
to
go
and
everyone
else
is
saying:
no
isn't
because
we
haven't
even
looked
at
it
yet,
and
so
you
you
get
this
problem
that
there's
a
team.
That's
been
working
on
this
for
x
amount
of
time
and
nobody
else
has
been
paying
any
attention
and
then
you
want
to
put
it
live
and
then
suddenly
a
lot
of
people
will
say
no
not
until
we've,
given
it
some
attention.
B
C
C
I
I
it's
it's
significantly
more
of
a
like
it's
less
of
the
like
complete
risk,
averse
like
no.
No,
we
can't
have
anything
it's
more
of
like
no,
no
well,
let's
look
at
what
we're
trying
to
protect.
This
is
what
we're
trying
to
protect.
So
this
means
well,
if
it
costs
more
to
protect
that
thing
than
it
does,
of
the
the
cost
of
losing.
That
thing
like.
C
Are
we
really
actually
gaining
anything
in
in
stuff
along
those
lines
and
because,
like
the
things
that
we're
looking
to
sort
of
do
there
right
is,
is
make
sure
that
you
know
as
we
pull
in
software,
like
you
can
sort
of,
say,
here's
the
policy
for
pulling
in
software.
Here's
the
policy
for
licensing,
here's
the
policy
for
all
these
different
pieces,
and
so
at
the
end
of
the
build
you
also
get
some
additional
sort
of
checks,
like
the
inputs
of
the
build,
are
all
those
things.
B
B
C
C
If
we
take
sort
of
the
the
cloud
native
build
practices
that
are
coming
out
of
the
cncf,
all
these
things
combine
them
into
something
that
then
the
open
ssf
can
start
to
really
push
for
others
to
really
start
to
address,
and
even
maybe
show
like
from
the
open
source
perspective
like
hey,
like
a
lot
of
what
you're
describing
makes
sense
for
also,
you
know
companies
of
any
size
right.
You
know,
smaller
companies
are
gonna
apply.
C
It
may
be
slightly
different
than
larger
companies,
but
I
think
one
of
the
other
things
that
that
folks
are
starting
to
ask
is
hey.
How
does
this
start
to
apply
to
open
source
projects
as
well,
and
that
maybe
don't
have
those
same
sorts
of
resources
and
potentially
can
the
open
ssf
come
in
and
say
well,
we'll
help
run
almost
like
a
sdlc
for
you
like
we'll
provide
resources
for
the
licensing
sorts
of
stuff,
we'll
provide
the
you
know
some
of
the
stuff
from
the
perspective
of
what
was
it?
C
What
was
the
other
thing
like
some
of
the
other
things
that
you
sort
of
listed
out
right,
like
security,
engineering
or
or
some
of
the
other
roles
there,
as
well
as
just
generally
like
the
stuff
that
isn't
you
know,
I
guess
open
source
sometimes
gets
a
bad
rep.
That
is
just
oh,
it's
only
hands
on
keyboard
and
how
do
we
make
sure
that
folks
also
recognize?
No,
no
we're
looking
at
this?
C
Also
from
the
perspective
of
how
do
we
enable
open
source
to
be
able
to
do
those
things
that
make
people
feel
more
comfortable
with
using
open
source
because
they
feel,
like
you
know,
it's
not
just
one
person
in
a
basement
somewhere,
writing
some
code
and
now
lots
of
people
you
know
rely
on
it.
Yeah.
B
But
that's
not
what
continuous
delivery
is
all
about.
Continuous
delivery
is
about
optimizing.
The
ability
of
an
organization
to
address
its
customers
needs
driven
by
the
customer,
not
by
the
organization,
so
so
that
there
tends
to
be
a
lot
of
anti
patterns
in
open
source
projects
that
don't
align
to
the
behaviors
that
you
should
be
doing
if
you're
actually
doing
continuous
delivery.
C
Yeah
that
I
think
that
so
that
actually
answers
a
lot
of
questions,
and
I
think
that
that's
actually
a
really
that's
a
really
really
really
good
point.
I
think
that
there's
there's
potentially
some
areas
where
I
do
think
the
linux
foundation
is
trying
to
take
a
little
bit
more
of
that
approach
where
they
are
trying
to
say,
hey
look.
C
How
do
we
become
a
bit
more
customer
focused
as
in
like
just
the
end
users
of
let's
say
kubernetes
or
something
like
that,
but
I
agree
with
you
that,
generally
that
that
does
not
fit.
For
you
know
the
hey,
I
I
wrote
a
little
library
for
myself
and
somebody
you
know,
and
now
it's
being
used
by
people
so
anyway,
thanks
for
that.
B
B
B
C
Yeah,
I
really
like
what
you
said
there.
We
need
to
build
tools
that
are
teaching
systems
right.
It's
it's!
I
think.
That's
that's
really
important,
because
I
know
you
know
my
background.
Right
is
mostly
in
sort
of
the
hands-on
keyboard,
ci
cd
stuff,
with
like
inside
of
systems
like
jenkins,
tecton,
etc,
and
one
of
the
problems
is,
is
without
the
right
sorts
of
guardrails
around
some
of
that
sort
of
stuff.
It's
like.
C
C
B
A
B
B
And
certainly,
if
you
look
at
what's
going
on
in
some
of
the
larger
organizations,
especially
places
like
apple,
where
your
your
product
is
a
a
physical
object
with
a
huge
amount
of
software
behind
it,
you
need
to
very
closely
tie
those
things
together,
because
if,
if
you
allow
them
to
drift
too
far
apart,
you
you
end
up
with
something
that
looks
like
it's
very
unstable
and
unreliable
and
and
part
of
that
commercial
advantage.
That
apple
have
is
that
they're
extremely
good
at
managing
their
supply
chain
in
both
the
physical
and
the
software
space?
A
Some
of
the
comments
that
were
said
earlier
from
the
cf
perspective
security
is
very
important,
so
and
and
across
the
board,
for
enterprise
and
and
also
open
source
projects.
So
we
don't
think
that
you
know
like
from
how
we're
beginning
to
think
about
it.
It's
not
just
cd
is
not
just
primarily
concerned
with
the
door
metrics,
but
also
security
being
vital
and
that
maybe
for
open
source
projects,
the
door
metrics
are
less
relevant,
but
security
certainly
is
so
that's,
maybe
an
overlap.