►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
CD Foundation Best Practices SIG - Tara Hernandez, Google & Terry Cox, Bootstrap
Virtual Track
Speakers: Tara Hernandez, Terry Cox
The CD Foundation Best Practices SIG will host a round table discussion and workshop opportunity for community members to discuss the current descriptions, compare their organization's CI/CD pipeline against the documented best practices, and potentially contribute an overview of their solution as an example use-case to be published as a community doc contribution.
A
Okay,
so
I'm
terry
cox,
I'm
co-chair
of
the
cdf
best
practices,
special
interest
group,
and
I
have
been
spending
the
past
a
year.
I
guess
now
working
with
a
great
team
of
people
trying
to
identify
some
of
the
challenges
in
the
continuous
delivery
space
and
help
to
codify
those
into
a
set
of
information
that
we
can
share
with
everybody.
B
B
B
B
B
So
here
is
the
site.
It
is
at
the
moment
a
work
in
progress
in
case
you
can't
tell
if
anybody
has
a
a
mind
towards
good
content
organization
and
color
scheming,
not
quite
sure
about
that
chocolate,
milk,
chocolate
color
there,
for
example,
we're
looking
for
all
kinds
of
different
types
of
contributors
and
as
you
go
into
the
site,
the
big
area
that
we
have
been
focusing
on
up
to
this
point
is
the
learn
section
and
right
now
where,
where
we're
at
with
this
is
kind
of
the
overview
topics
that
we
have.
B
Relevant
to
the
latest
research-
that's
going
on
around
the
industry
as
far
as
the
definition
types
tool
stacks
and
what
have
you?
We
also
have
a
community
site
which
we're
hoping
to
focus
on
for
the
next
year,
which
is
bringing
in
those
external
examples.
So
that'll
be
an
area
of
focus
and,
of
course,
finishing
out
the
site.
There
are
some
areas
that
aren't
completely
that
aren't
complete
as
yet
we
have
a
github
repo
here
where
you
can
clone
and
do
pull
requests.
B
A
B
On
the
community,
under
the
community
section
in
the
site
shows
the
contribution
guidelines.
I'm
just
noticing
that
they're
slightly
out
of
date,
netflix
is
actually
set
up.
It
is
how
we
are
publishing
this
site.
I
guess
I
have
another
fix.
I
need
to
put
into
the
content.
Another
aspect
is
the
tagging
system.
It's
still
a
work
in
progress,
but
the
hope
is,
as
the
community
contributions
come
in
and
we
do
have
those
examples
that
terry
was
talking
about.
I
will
be
able
to
reference
them
back
into
these
categories.
B
B
B
A
B
And
continuously
change
management,
in
other
words,
is
a
big
part
of
that
right.
Exactly
but
then
continuous
deployment
means
you're,
actually
doing
it
and
pushing
your
stuff
live,
because
you
have
figured
out
all
of
those
intricacies
which
is
very
hard
by
the
way,
not
a
lot
of
places.
Do
it
truly
so
cole
says
git
lab
ci
to
build
test
and
deploy
as
far
as
cd
automate
prod
deployments
on
tagging.
Okay,
excellent
tagging
in
this
case,
meaning
the
git
tags.
B
Well,
nicole,
is
thinking
about
that
answer
tagged
manually,
I'm
not
sure
we
could
truly
deploy
at
any
time.
It's
all
right
goals
so
another
another
question
that
we
that
we
thought
of
and
terry
I'd
love
for
you
to
take
the
the
lead
on
this
one,
which
is
you
know,
so,
there's
a
certain
amount,
nicole
in
this
case
that
we're
picking
on
her
of
automated
testing
that's
in
place,
and
one
of
the
interesting
questions
that
we
talked
about
is
how
do
you
automate
testing
at
scale?
A
Well,
I
I
think
the
the
the
thing
with
testing
is
that
it's
it's
one
of
those
infinite
rabbit
holes
where
you
you
can
test
forever
and
and
never
be
comfortable,
deploying
anything.
But
this
is
why
it's
important
to
come
back
to
continuous
delivery
as
a
methodology,
rather
than
just
a
set
of
techniques.
A
A
B
B
I
don't
always
test
my
code,
but
when
I
do
I
do
it
in
production
or
I
was
like
that's
really
the
most
trickless
thing
ever
and
yet
here
we
are,
and
that
is
actually
considered
to
you
know
to
your
point
actually
valid
and
possibly
more
efficient,
because
the
signals
that
you're
getting
are
actually
the
most
accurate
because
they're
reflective
of
the
production
environment.
So
then
yeah,
absolutely
the
what's.
A
A
This
is
one
of
those
ones
where
we
tend
to
ignore
the
fact
that
code
rots
and-
and
so
when
we
when
we
run
a
build
pipeline,
we
think
we've
got
good
code,
but
actually
we've
only
got
good
code
at
the
moment
that
that
pipeline
completed
because
all
the
world
around
us
is
continuing
to
move
and
our
dependencies
may
be
changing.
Our
environments
may
be
changing
and
there
are
many
things
that
that
can
invalidate
the
build
that
we've
just
done.
A
So
it's
insufficient
to
run
a
build
once
if
you're
not
gonna,
go
straight
into
production
with
that
with
that
build,
and
even
if
you're
in
production,
you
should
really
be
continuing
to
run
that
build
and
run
those
tests
on
a
regular
cadence
to
tell
you
that
you
can
still
build
this
thing
and
that
all
of
your
dependencies
are
still
valid
so
that,
if
you
do
need
to
change
something
in
a
hurry
you
you
can
get
a
change
through
the
system
at
maximum
speed.
Knowing
that
everything
is
still
good
to
go.
B
And
you
think
about
something
like
a
a
canary
deployment
model,
which
you
know
it's
like
you,
if
you
think
about
that,
as
both
something
that
allows
you
to
do
a
big
roll
out
in
a
in
a
in
theoretically
a
safe
way.
So
you
know
five
percent,
ten
percent
twenty
percent.
You
gradually
turn
up
the
dial
and
then
now
your
big
change
is
fully
deployed.
B
You
to
your
point,
terry,
you
know
you
could
also
continue
to
use
that
where
you
have
a
canary
deploy
on
that's,
maybe
always
running
at
one
or
two
percent
rate
and
maybe
behind
a
further
feature,
flag
style
restriction,
so
that
you
really
have
a
special
category
of
people
who
are
always
basically
seeing
your
world
life
right.
That
would
be
a
truly
aggressive,
but
fundamentally
awesome
ability
to
be
able
to
say
and
like
that,
nicole,
what
you
were
saying
is
that
you
don't
know
that
you
could
truly
deploy
at
any
time.
B
So
my
question
to
you
would
be
to
think
about
and
no
pressure.
You
know
what
what
do
you
think
is
holding
your
organization
back
from
that
right?
Is
it
perhaps
a
lack
of
confidence
in
the
coverage
in
the
lack
of
confidence
in
you
know,
turnaround
time
so
failure
to
resolve
or
your
I'm
sorry,
your
time
to
resolve
rate?
What
sorts
of
things
do
you
think
make
that
challenging?
So
take
your
time
give
a
thought
about
that.
B
The
other
thing
about
testing
at
scale.
So
I
think
you
know
what
you're
talking
about
terry,
which
is
freshness
then
there's
like
true
scale,
so
a
lot
of
what
companies
do
yelp.
That
was
a
great
example
of
this
is
they're
like
okay.
Well,
you
know
this
cloud
thing
is
pretty
awesome
and
aws
has
these
spot
instances?
And
you
know
those
are
cheap,
so
we
can
just
test
as
much
as
we
want
and
then
the
rule
of
thumb
is
the
tests
are
as
fast
as
the
slowest
test.
B
You
try
to
parallelize
things
as
much
as
possible,
but
then
you
start
running
into
oh
gosh.
The
spot
instances
are
actually
becoming
unavailable
because
the
you
know
the
tendency
of
those
instances
are
getting
overloaded
and
and
very
practically
it's
like.
Oh,
this
isn't
working
anymore
right
and
then
you
also
think
about
okay.
B
Well,
even
if
with
spot
or
if
you
decide
spot
is
too
unpredictable
and
you
go
to
dedicated
residency,
there's
cost
management
right
and
so
there's
you
know,
how
do
you
evaluate
the
roi
of
your
infrastructure,
investment
where's,
the
inflection
point
to
when
you
know,
you're
spending
the
right
amount
of
money
and
not
too
much
or
too
little?
So
I
think,
there's
a
definitely
an
art
to
that
discussion
as
well.
I
wish
I
wish
we
could
go
with
a
good
heuristic
on
that
one.
Maybe
that's
a
good
exercise
that
someone
could
try.
A
Well,
I
I
was
rather
thinking
that
right
now,
the
primary
reason
for
not
being
able
to
deploy
is
because
the
business
isn't
ready
and
and
that's
where
we
hit
one
of
the
fundamental
challenges,
which
is
that,
if,
if
you're
driving
your
continuous
delivery
adoption
purely
from
an
engineering
perspective,
you
run
the
risk
of
getting
stuck
at
some
point,
because
the
business
as
a
whole
has
release
processes
which
sit
outside
of
the
engineering
space
and
those
might
be
marketing
or
legal
or
a
range
of
different
timing.
Issues
that
need
to
be
sorted
out.
A
A
B
Yeah,
that's
a
great
point
and
there
may
be
completely
legitimate
reasons
why
you'd
have
variety
in
that
like
for,
for
example,
I've
recently
learned
that
the
core
server
comes
out
more
annually
for
a
major
revision
and
then
quarterly,
for
you
know,
maybe
some
minor
tweaks,
but
you
don't
we
as
a
business.
We
don't
actually
want
to
go
faster
than
that,
because
it's
a
database.
B
You
know
our
customers
don't
want
to
take
constant
change,
but
there's
a
whole
ecosystem
around
that,
especially
in
the
cloud-based
services
and
hosting
where
it's
you
know,
the
continuous
delivery
is
an
actual.
Continuous
deployment
is
an
actual
goal
legitimately
because
it
works
well
for
our
business
and
works
well
for
customers.
B
Nicole,
says
we're
generally
disorganized
and
could
certainly
improve
test
coverage
or
entire
organs.
Less
than
20
people,
aha
you're
a
little
company
that
is
fantastic.
It
means
that
you're
already
looking
in
into
investing
and
doing
it
right,
and
so
you
will
be
more
successful
in
the
long
run.
Well
done
a
lot
of
times,
companies
wait
until
they
have
more
than
100
people
before
they
start.
Thinking
about
this
stuff.
B
Right
and
I
think
the
important
lesson
that
we
can
offer
you
nicole,
is
that
much
like
your
product
will
evolve
and
your
organization
will
evolve.
Your
your
continuous
delivery
pipeline
also
will
need
to
evolve
so
anyway,
we
are
just
about
at
the
end
of
time.
This
was
a
good
discussion,
nicole,
good
luck
with
your
startup
very
exciting
stuff.
Excellent.