►
From YouTube: CI and CD in Cloud Native (The Podlets, Ep 11)j
Description
A warm welcome to John Harris who will be joining us for his first time on the show today to discuss our exciting topic, CI and CD in cloud native! CI and CD are two terms that usually get spoken about together but are actually two different things entirely if you think about them. We begin by getting into exactly what these differences are, highlighting the regulatory aspects of CD in contrast to the future-focussed nature of CI. We then move on to a deep exploration of their benefits in optimizing processes in cloud native space through automation and surveillance from development to production environments. You’ll hear about the benefits of automatic building in container orchestration, the value of make files and local test commands, and the evolution of CI from its ‘rubber chicken’ days with Martin Fowler and Jez Humble. We take a deep dive into the many ways that containers differ from regular binary as far as deployment methods, build speed, automation, run targets, realtime reflections of changes, and regulation. Moreover, we talk to the challenges of transitioning between testing and production environments, getting past human error through automation, and using sealed secrets to manage clusters. We also discuss the benefits and drawbacks of different CI tools such as Kubebuilder, Argo, Jenkins X, and Tekton. Our conversation gets wrapped up by looking at some of the exciting developments on the horizon of CI and CD, so make sure to tune in!
For the show notes and transcript: https://thepodlets.io/episodes/011-ci-and-cd-in-cloud-native
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Special guest:
https://twitter.com/johnharris85
Hosts:
https://twitter.com/bryanl
https://twitter.com/apinick
B
B
So
today
we're
gonna
talk
about
CI
and
CB,
and
cloud
native
and
I
want
to
start
this
off.
With
this
whole
term
CI
and
CD,
we
talked
about
C,
we
talked
about
them
together.
There
are
two
different
things
almost
entirely,
if
you
think
about
them,
but
CI
stands
for
a
continuous
integration
and
then
we
have
CD
what
a
CD
stand
for
compact,
disc,
right,
three
and
actually
I've
used
that
too,
before
I
actually
do
agree,
but
what
else
is
CDs?
Therefore,
it's
continuous
deployment
right,
yeah
and
continuous
delivery.
Yeah
I
forgot
about
that.
A
B
That's
the
interesting
things
is
that
you
know,
as
as
we
talked
about
tech,
and
we
give
things
acronyms
CD
is
just
a
great
one.
You
know
change
directories,
compact
discs,
continuous
delivery
and
continuous
deployment.
So
here's
the
bonus
question.
Does
anyone
here
know
the
difference
between
continuous
delivery
and
continuous
deployment.
B
Everything
else
is
a
detail
of
the
system
you
choose
to
use
so,
whether
you
use
Jenkins
or
circle
CI
or
drone,
or
you
built
your
own
thing
or
you're,
using
Travis
or
any
of
the
other
online
of
CI
tools,
but
at
the
end
of
the
day,
you're
building,
either.
If
you're
doing
web
development,
maybe
you're
building
out
doctor
files
because
we're
in
cloud
mavis
I,
don't
dr.
B
A
A
B
Yeah
so
I
like
to
tell
people
whenever
you
start
any
project,
whether
it's
big
or
small,
especially
if
it's
on,
if
it's
not
on
Windows
I'll,
tell
you
something
different
if
it's
on
Windows,
but
if
you're
developing
on
a
Mac
are
developing
on
Linux,
the
first
thing
you
should
do
and
your
project
is
create
a
make
file
or
your
programming
language
equivalent
of
a
make
file,
and
then,
in
that
make
file.
What
you
should
do
is
write
a
command
that
will
build
your
software
that
runs
its
test
slowly
mm-hmm
and
also
builds
builds.
B
The
whatever
the
process
is
I
mean
if
you're
running
in
like
go.
You
do
a
go,
build
if
you're
using
rest,
you
know
build
with
rest
or
C++
or
whatever
before
you
even
write
any
code
and
the
reason.
Why
is
because
the
hardest
part
is
making
your
code
built
and
if
you
leave
that
to
the
end,
you're
actually
making
it
harder
on
yourself.
So
if
your
code
build
works
from
the
beginning,
all
you
have
to
do
is
change
it
to
fit
what
you're
doing,
rather
than
thinking
about
it
when
it's
crunch
time,
I
actually.
A
Builder
John,
you
and
I
have
been
talking
about
key
builder
quite
a
bit,
but
using
cue
builder
and
one
of
the
things
it
does
for
use
it
scaffolds
out
and
make
file
for
you,
and
that
was
like
that.
Going
from
me
doing
it
by
myself,
having
it
already
exist
for
you
or
just
having
it
at
the
beginning
was
so
much
better.
I
totally
agree
with
you
Brian.
So.
A
Cube
builder
is
a
tool
that
was
created
by
members
of
the
kubernetes
community
to
scaffold
out
the
creation
of
controllers
and
web
hooks,
and
so
what
a
controller
is
in
kubernetes
is
a
piece
of
software
that
waits
or
it
watches
a
specific
object
or
many
specific
objects
and
reconciles
them.
So
if
they
notice
that
something
has
changed,
and
you
want
to
make
an
action
based
on
that
change,
the
controller
does
that
for
you,
okay,
so.
B
A
Yeah,
so
if
you
know,
for
instance,
the
one
that
I
made
for
myself
was
a
tool
that
watched,
updated
and
watched
a
specific
CRT,
but
it
wasn't
necessarily
a
controller.
It
was
just
like
flagging
on
whether
or
not
a
change
occurred
and
I
used
the
dynamic
client-
and
that
was
a
huge
headache
on
of
itself
cube
builder,
has
like
the
ability
to
watch
not
just
your
DS
but
any
object
in
kubernetes
and
then
reconcile
them
based
on
changes.
It's
pretty
great,
alright,.
C
B
C
I
think
one
of
the
interesting
things
about
the
original
kind
of
philosophy
of
CI
outside
of
the
tooling
was,
like
you
know,
trunk
based
development
that
every
developers
changes
get
integrated
into
trunk
as
soon
as
possible.
You
don't
get
into
integration
to
hell
and
rebasing
and
I
think
it's
kind
of
interesting
when
you
apply
that
to
a
cloud
native
landscape
where,
like
you
know
when
that
stuff
came
out
with,
like
you
know,
Martin
Fowler
and
Jess
Humble,
probably
10-15
years
ago,
almost
now,
a
lot
of
dev
teams
were
co-located.
C
You
could
do
CI
like
I
think
there
was
a
rubber
chicken
method,
but
you
didn't
use
a
tool
that
was
just
whoever
had
the
chicken
was
responsible
for
the
build
and
they
just
to
pull
everyone
else's
changes.
But
now
it
seems,
like
you
know,
everything
is
branch
based
when
you
look
at
a
project
like
kubernetes
there's
a
huge
number
of
contributors,
all
geographically,
you
know
display
different
time
zones,
lots
of
different
parameters
and
features
going
on
at
the
same
time.
C
B
B
Yeah
he
did
so
John.
You
brought
up
some
good
things
about
about
see
I,
so
I.
Try
to
simplify
everything.
I
think
the
the
mark
of
someone
who
really
knows
they're
talking
about
is
being
able
to
explain
everything
in
the
simplest
where
it's
possible
and
then
you
can
work
backwards
when
people
understand
so
I
started
off
by
saying
that
CI
produces
an
artifact,
I,
didn't
talk
about
branches
or
anything
like
that
or
even
the
integration
piece.
But
then
let's
go
into
that
a
little
bit.
B
So
there's
a
lot
of
misconceptions
about
CI
in
general,
but
one
of
the
things
that
we
talked
about
is
that
you
have
to
run
tests.
No,
you
don't
have
to
run
tests,
but
should
you
yes,
a
hundred
percent
of
time.
You
should
you're
your
CI
process.
Your
integration
process
should
actually
build
your
software
and
run
the
test
because
running
a
test
on
this
dedicated
service
or
hardware
or
whatever.
Where
is
ensures
that
the
quality
of
your
software
is
there
at
least
as
much
as
your
developers
have
ensured
the
quality
and
the
test.
B
So
it's
very
important
if
those
run
and
a
lot
of
bugs,
of
course,
can
beast
can
be
spotted
by
running
CI.
I
mean
you
know,
we
are
all
sorts
of
developers
here
and
I.
Tell
you
what
sometimes
I
forget
to
run
the
test
locally
and
CI
catches
me
before
a
commit
mix
it
into
master,
and
it
has
a
huge
typo
or
a
whole
bunch
of
print
lines
in
there.
A
A
B
B
There
was
different
things
there
and
you
actually
could
compile
your
code
different
and
then,
when
46
came
out
and
then
when
we
have
introduction
of
Pentium
chips,
things
were
different,
but
now
you
know
we
can
pretty
much
all
target
AMD
64
and
in
some
cases
I
mean
there
are
some
chip.
Things
like
like
the
like,
the
the
bigger
encryption
things
that
are
in
the
the
newer,
the
newer
chips.
B
But
for
the
most
part
we
know
what
aren't
deployed
targets
going
speed,
but
the
cool
thing
is
also
that
we
don't
have
to
have
until
our
AMD
64.
It
could
be
arm
32
or
arm
64
and
with
the
addition
to
a
lot
of
the
work
that
has
been
going
on
in
Windows
Land.
Lately
we
can
have
Windows
images,
I,
don't
know
so
many
people
were
doing
that
yet
I'm
not
out
in
a
part
of
the
field
but
I
like
that.
The
opportunity
is
there.
There's.
C
Just
gonna
say
one
of
the
interesting
things
is
the
deployment
method
as
well.
You
know
now
with
containers
everything
is
kind
of
an
immutable
rip
and
replace
like
if
we
develop
an
application.
We
know
the
old
content
is
gonna,
stop
let
apply,
and
you
and
I
think
you
know
Netflix
we're
doing
a
little
bit
of
this
before
containers
and
some
other
folks
was
like
baking,
a
Mis
and
using
that
immutable
method,
but
I
think
before
that
it
was
you
know.
C
If
we
had
a
war
file,
we
had
to
throw
it
back
into
Tomcat,
let
Tomcat
pick
it
up
or
whatever,
and
you
know
that
everything
was
a
little
bit
more
flaky
in
terms
of
deployment.
We
had
to
do
a
lot
of
checks
around
deployment,
rather
than
just
you
know,
bring
something
out,
bring
something
back
in
blue,
green.
Whatever.
B
Hello,
I
actually
like
that.
You
brought
that
up,
because
that
is
that's
actually
one
of
the
the
greatest
parts
of
this
whole
cloud
native
thing
is
that
when
we're
using
containers
and
we're
deploying
with
containers,
we
know
it
are.
We
know
what
our
file
systems
going
to
look
like,
because
we
created
it.
There
was
not
be
some
rogue
file
or
another
configuration
there
that
will
chip
up
our
our
deployment,
because
at
built
time
we've
created
the
environment
and
it's
much
better
than
that
facility.
B
That
Netflix
was
doing
with
big
Mia
mice
in
a
previous
life,
I
actually
ran.
The
facility
for
baking
am
I
at
a
large
company
where
we
had
thousands
of
developers
on
more
than
a
thousand
dev
teams,
and
we
had
a
lot
of
spyware
and
whenever
you
had
to
build
an
image,
it
was
fine
in
one
account,
but
if
you
had,
let's
say
a
thousand
accounts
with
the
way
that
AWS
works
and
and
encrypted
images
you
actually
had
to
copy
all
the
images
to
all
the
accounts
couldn't
actually
boot
it
from
your
account.
B
So
I
am
glad
that
we
actually
have
this
thing
called
a
container
that
and
all
these
things
based
on
CRI,
they
contain
a
runtime
that
we
are
able
to
to
quickly
build
containers.
So
I
don't
want
to
just
limit
this
conversation
to
continuous
integration,
let's
get
into
the
other
parts
too,
with
deployment
and
delivery.
A
Think
to
me
it's
the
ability
to
have
your
code
or
your
artifact
or
whatever
it
is
whatever
you're
working
on.
When
you
make
a
change,
you
can
see
the
change
reflected
in
reality.
Whatever
your
reality
looks
like
without
your
intervention
right
hope.
Well,
I
mean
you
might
have
had
to
setup
all
the
pipelines
and
all
the
that
jargon.
But
when
you
know
you
press
save
and
vias
code
and
it
creates
a
branch
and
runs
all
your
tests
and
deploys
it
for
you
or
delivers
it
for
you
into
what
you
define
is
reality.
A
That's
just
so
nice
because
you
know
it's.
It
really
kind
of
sucks
having
to
do
be
like
okay,
I've
got
a
new
deployment,
destroy
the
old
deployment
put
in
the
new
one
or
like
rev,
the
new
image
tag
or
whatever
in
the
deployment.
Doing
all
these
manual
steps
again
thinkI
brain
juice.
It
takes
pieces
of
you
know
your
attention
away
and
having
these
pieces
like
added,
for
you
is
just
so
nice
yeah.
C
Yeah
I
think
you
know
something
in
this
day
of
DevOps.
We
pull
one
of
the
best
predictors
for
company
success
like
cycle
time
of
feature
from
ideation
to
production.
I.
Think,
like
you
know
the
faster.
We
can
get
that
cycle.
Everything
okay
kind
of
makes
me
interested.
You
know
like
how
long
does
an
application
take
to
build
if
it
takes
two
hours
like
how
good
are
you
were
getting
features
out
there
quickly?
Maybe,
but
there
you
know,
one
of
the
drivers
was
micro-services
smaller
pieces,
independently
deployed.
We
can
get
features
out
to
production
quicker.
C
B
We
can
now
easily
manage
multiple
deployment
environments
because
think
about
before
you
would
have
a
dev
environment,
and
that
would
be
the
Wild
West.
That
would
be
literally
where
it
would
be
awful.
You
might
have
to
rebuild
it.
Every
couple
of
months,
and
then
you
would
have
staging
and
and
then
maybe
you
would
have
some
kind
of
pre
prod
environment.
Just
as
like
your
final
smoke
test,
and
then
you
would
have
your
production
and
maintaining
all
the
software
on
all
those
was
extremely
hard.
B
But
now,
with
the
advent
of
containers,
now
it's
as
simple
as
identifying
the
image
that
you
want
and
and
basically
running
that
image
on
on
in
that
environment
and
and
I
like
where
we've
ended
up.
But
you
know
with
all
power
comes
new
problems,
and
just
because
we
can
deploy
quicker
means,
we
just
run
into
a
lot
of
different
problems
we
didn't
run
into
before,
and
the
first
one
that
I'll
bring
up
is
and
the
complexity
so
Auto
promotion
between
environments,
so
moving
code
between
test
staging
and
production.
A
So
I
would
I
guess
you
would
have
different
or
maybe
the
same
pipeline
but
different
targets
for
like,
if
say,
you're,
using
something
like
kubernetes.
You
could
have
one
part
of
your
pipeline
deploy
initially
to
this
like
kubernetes
context,
which
points
to
like
one
cluster,
so
splitting
up
clusters
by
environment
type
and
then
deploying
into
those
running
your
tests,
see
if
it
runs
properly
and
then
switch
over
to
the
next
context,
to
apply
that
image
tag
and
that
information
and
just
go
down
the
chain
until
you
get
to
production.
B
It's
now
we
take
that
software
and
we
spin
up
a
new
whole
environment
and
we
just
install
that
software.
So
for
that
one
particular
feature
that
you
worked
on.
You
can
actually
get
an
automatic
environment
for
that
and
then
what
we
can
do
is
we
can
take
that
environment
itself
and
we
can
say
we
can
now
merge
this,
maybe
into
a
staging
branch
or
tag
it
with
a
staging
like
label
and
that
automatically
gets
in
gets
moved
to
staging
and
depending
on
how
complete
how
complicated
you
are,
how
advanced
you
are
now.
B
C
It's
a
great
point
about
environments.
You
know
I,
think,
like
back
in
the
day
an
environment
used
to
be
a
set
of
machines,
and
then
tests
used
to
be
there
like
a
staging
was
where
there
were
kind
of
more
stable
versions
of
api's
and
folks
would
more
coordinated,
pushing
things
into
them,
but
like
what
really
is
an
environment
like
you
said
now,
we
push
you
know
microservices
or
whatever
or
service.
We
can
spin
up
an
entire
kubernetes
cluster.
Just
for
that
service
we
can
set
it
up.
We
can
run
what
abcess
we
want.
C
A
B
Mean
that's
where
we
want
to
be
I,
find
more
often
than
not,
that
people
have
separate
separate
clusters
for
Deb's
and
and
staging
and
production,
but
you
know
using
the
kubernetes
api.
You
don't
have
to
do
that,
because
what
we
can
do
is
we
can
force
deployment
or
a
workload
to
a
set
of
machines
because
based
on
their
label,
that's
that's!
Actually,
then
one
of
the
very
strong
positives
for
kubernetes,
you
know,
forget
all
the
complexity,
one
of
the
things
that
makes
it
easy
is
to
say
that
I
want
this.
B
This
particular
deployment
to
only
live
on
my
development
machines,
well,
which
development
machine
I
don't
care,
and
what?
If
we
increase
our
development,
pull
sighs
we
just
relabeled,
we
just
relatable
notes,
it
doesn't
matter
now
we
can
just
control
that
and
when
it
comes
down
to
controlling
cost
and
complexity,
this
is
actually
one
idea
that
kubernetes
is
leading
and
just
making
it
easier
to
actually
use
more
of
your
hardware.
A
Yeah
absolutely
and
like
that's
so
great
because
like
if
you
think
about
it
from
a
CIA
CD
standpoint
at
that
point,
all
you
have
to
do
is
just
change
the
label
to
where
you're
applying
this
piece
of
code
right
so
you're
like
no
node
selector
label
equals
dev.
Okay.
Now
it's
staging
okay!
Now
it's
prod
yeah.
B
A
Well
so
okay
I
mean
in
the
kubernetes
perspective,
you
might
be
using
something
that
gets
a
datastore,
but
like
everything
else
like
whatever
using
like
Travis
Wood,
is
terrible
store.
If
you
think
it
should
be,
everything
should
be
version
right.
Everything
should
yeah
a
hundred
of
good
land
mm-hmm,
so
I
would
soar
everything
there
as
much
as
possible.
Now
do
I.
Do
that
all
the
time-
god,
absolutely
god
I'm,
a
human
being
after.
B
B
Basically
it's
like
kubernetes
is
declarative
and
our
configurations
can
be
declarative
to,
because
what
we
can
do
is
make
sure
that
we
can
have
text-based
configurations
and
for
one
reason,
is
because
text
based
means
it
can
be
versioned,
it
can
be
dipped
and
we
take
those
text
versions
and
we
put
them
in
our
same
repository.
We
put
our
code
in
and
how
did
we
know
what's
in
production
at
any
given
time
or
any
given
time
in
the
past?
We
just
look
at
the
tags
of
what
we
did.
So
we
had
a.
B
We
had
a
push
at
at
5:15
on
August
13th
and,
of
course,
is
this
5:15
I'm.
You
can
see
time
because
any
other
time
doesn't
exist
in
computer
Lillian.
So
what
we
could
do
is
we
could
just
basically
tag
that
particular
version
as
like
2019
zero,
eight
one.
Three,
let's
say
if
I
said
five
so
1755
and
we
can
call
zero
one
two.
B
C
Yeah,
the
config
thing
is
so
important.
I
think
that
was
another.
Just
humble
quote
where
it
was
like.
Give
me
give
me
three
hours,
access
to
your
code
and
I'll
break
it,
but
give
me
five
minutes
with
your
configurations
and
I'll
break
it,
and
it
was
almost
like
every
big
bug
is
very
like
someone
was
accidentally
pointing
the
prod
server
to
the
staging
database
or
like
hoops.
C
The
API
was
pointing
to
the
wrong
pool
and
everything
came
down
or
we,
you
know,
changed
the
wrong
versions
or
whatever
so
I
think
you
know
and
I
think
that's
one
of
the
intersections
of
developers
and
operations,
folks
and
kind
of
talk
about
like
DevOps
and
things
like
that.
Like
I,
really
love
the
idea
of
everything
being
kept
and
gear
and
using
get-ups.
But
then
we've
got
things
like
secrets
and
you
know
configuration
they
shouldn't
be
seen
or
being
able
to
be
edited
by
developers.
C
B
C
It
allows
you
creates
a
CID
which
is
a
sealed
secret,
which
is
a
special
resource
type
in
your
cluster
and
also
creates
a
key
which
is
only
available
to
that
operator
running
in
your
cluster.
So
you
can
submit
a
sealed
secret
in
plaintext.
We
can
smear
secret
in
plaintext
and
it
will
throw
it
back
out
as
an
encrypted
secret
with
that
key,
and
then
you
can
check
that
into
version
control.
And
then,
when
you
go
to
deploy
your
software,
you
can
deploy
that
encrypted
secret
into
the
cluster.
The
operator
will
pick
it
up.
C
B
I
think
the
the
most
important
part
of
what
you
said
is
that
this
allows
us
to
have
no
excuses
about
what
we
can
store
in
our
repositories
for
our
configuration,
because
someone's
gonna
make
the
argument.
No,
we
can't
store
secrets,
but
someone's
gonna
be
able
to
see
them.
Well,
guess
what
we
never
even
stored,
an
unencrypted
secret
in
our
repository
they're
all
encrypted,
and
it's
and
still
see
Chris's
aes-256
I,
don't
know
if
anyone's
cracked
that
yet
I'm
sure,
maybe
a
state-level
actor
has
thought
of
it.
B
But
for
us,
regular
people,
and
even
our
companies
like
even
a
VMware
or
even
Google-
they
have
not
done
it
yet.
So
it's
still
pretty
safe,
so
I'm
thinking
even
further,
now
and
and
really
what
I'm
trying
to
paint
the
picture
of
is
not
just
how
do
you
do
CD,
but
really
what
CD
could
look
like
and
and
and
how
can
actually
make
you
happy
rather
than
sad?
So
the
next
item
I
wanted
to
think
about,
was
tools
around
CD
and
and
creating
tools
and
and
and
what
does
a
good,
continuous
delivery
system?
B
Look
like
I
kind
of
hinted
to
this
Memphis
earlier.
Whenever
I
was
talking
about
pipelines,
the
ability
to
take
advantage
of
your
hardware,
so
we
have
we're
deploying
to
let's
say
a
hundred
service
or
pulling
five
or
six
services
to
100
node
cluster.
We
can
do
those
all
at
once
and
what
we
can
do
is
you
want
to
have
a
system
that
can
actually
run
like
this
and
I
could
think
of
a
couple.
There
is
the
from
Intuit.
There
is
our
go
and
they
have
Arco
CD.
B
C
B
Spinnaker
they
quoted
me
in
their
book
and
and
I-
don't
remember
their
name.
Oh
I'm,
sorry,
anyone
in
the
firm
spinnaker
product
listening,
but
once
again
not
advocating
any
products,
but
they
have
the
concept
of
doing
pipelines,
and
then
you
also
have
other
things
for
like
free
projects
like
if
you're,
usually
open
source
drone.
B
A
I
just
have
some
thoughts
on
some
of
the
tools
that,
like
we've
used.
You
know
everyone.
Everyone
knows.
Jenkins
Jenkins
can
do
like
anything
that
you
wanted
to
do,
but
you
really
have
to
like
tighten
the
screws
on
it.
I
find
that
it
is
super
powerful,
it's
kind
of
like
bash,
like
bash
good
thing,
it's
super
powerful,
but
you
have
to
know
precisely
what
you're
doing.
Otherwise,
it
can
really
really
hurt
you
I
actually
I
have
used
spinnaker
in
the
past
and
I
really
liked
it.
A
B
Well,
since
we're
going
out
products
out,
Jenkins
does
have
Jenkins,
X
and
I
have
not
given
it
the
full
rundown
yet.
But
what
I
do
like
about
it
and
I
think
everyone
should
pay
attention
to
this
if
you're
doing
a
product
in
this
space
is
that
when
you
install
Jenkins
X,
you
install
it
locally
to
your
machine.
You
basically
get
this
binary
called
JX
and
you
then
tell
JX
to
install
it
into
your
cluster
and
instead
of
just
doing
cube,
control,
apply
eff,
a
whole
bunch
of
Yambol.
B
It
actually
asks
you
questions
and
it
sets
up
github
repositories
or
wherever
you
need
these
repositories,
and
it
sets
up
name
spaces
for
you.
So
there's
no
just
blindly
to
control
apply
F
of
space.
Http
colon
I
just
owned
your
system,
because,
okay,
that's
actually
a
problem,
and
then
it's
you
know
it
solves
the
Yambol
sprawl,
because
yeah
mole
is
just
the
yeah
mole
is
in
kubernetes
is
something
that
you
know.
So
it's
complaining
about
a
lot,
but
it's
how
its
configured,
but
it's
also
just
a
detail.
B
What
we're
supposed
to
be
doing-
and
we
actually
work
with
Joe
bata
and
not
going
to
talk
about
Tim
about
this
all
the
time
is
that
the
yeah
mo
is
the
implementation,
but
it's
not
the
idea.
The
idea
is
that
we
build
tools
on
top
of
that
that
create
yeah
moles,
so
users
have
to
see
less
gamble
and
I.
Think
that's
a
problem
with
Jenkins
is
that
it's
so
powerful
and
they're
like
well.
B
We
want
powerful
people
or
smart
people
to
be
able
to
do
smart
things,
so
here
you
go
and
the
problem
with
that
is
that,
where
do
I
start,
it
is
a
little
daunting.
So
I
do
think
that
they
definitely
came
with
their
with
with
a
much
stronger
game
because
j.x
command
and
just
as
a
little
sidebar.
We
do
it
as
well
with
our
Valero
projects
and
I.
C
Think's
interesting
about
the
options.
This
is
definitely
one
area
where
there's
so
much
nuance,
everyone,
you
know
any
time
you're
in
developer,
tooling.
Everyone
wants
to
do
something
slightly
differently,
so
all
of
these
tools
are
so
tweakable
that
they
become
so
general
I.
Think
it's
probably
one
of
the
criticisms
that
could
be
leveraged
against
Jenkins
is:
do
you
can
do
everything
and
that's
actually
a
negative
as
well
as
a
positive
right?
Sometimes
it's
it's
too
overwhelming.
B
Now
we
are
just
getting
to
the
point
where
we
actually
understand
what
a
good
decision
is,
because
there
was
a
lot
of
guesses
before
and
we've
done
a
lot
of
things,
and
some
of
these
have
been
good
ideas,
but
in
some
cases
they
have
not
been
great
ideas
and
even
you
know,
I
ran
the
project
case
on
it
great
idea
on
paper,
but
implementation
may
require
people
to
know
too
many
things.
So
you
know
we
learned
a
lot
of
lessons
from
that.
B
But
that's
what
I
think
we're
gonna
find
out
in
this
space
is
that
we're
gonna
learn
a
lot
of
lessons
and
I
say
this
project
for
my
last
project.
That
I
was
going
to
bring
up
is
something
that
I
think
has
learned
some
of
the
lessons.
Google
sponsors
a
project
called
Tecton,
and
if
you
go
to
it's
like
github.com,
/t
e
kto
and
I
believe-
and
they
have
some
continuous
delivery
stuff
in
there
and
they
implement
pipelines.
B
But
the
neat
part
is-
and
this
is
actually
the
best
part-
is
it's
actually
a
cloud
native
build
service,
so
every
step
of
your
delivery
process
from
from
creating
images
to
actually
putting
them
on
clusters
is
backed
by
a
docker
image
or
a
container
and
I.
Think
that
part
is
pretty
neat.
So
now
you
can
define
your
steps
and
what
is
your
step?
B
Well,
you
can
use
one
of
their
pre
baked,
run
this
command
or
if
you
have
something
special
like
that,
the
example
of
floral
is
giving
out
where
you
would
say
that
you
need
an
approval.
Maybe
it's
a
slack
approval,
you
send
something
with
slack
and
it
has
a
check
box
check.
Guess
if
you
like
me
and
what
we
can
do
now
is
we
can
actually
control
that
and
it's
easy
to
write
something
a
little
docker
image
that
can
actually
make
that
call
and
get
the
request,
and
then
it
can
move
it
on.
B
So,
if
you're,
looking
at
more
of
a
toolkit
full
of
good
ideas,
I
do
think
that
Tecton
has
definitely
has
some
lots
of
industry.
People
are
looking
at
it
and
it's
probably
the
best
example
of
getting
it
right
in
the
cloud
native
way,
because
a
lot
of
the
products
we
have
now
are
not
cloud
native
like
we're
talking
about
Jenkins
and
we're
timeout
spinnaker,
and
we
talk
about
drone
from
the
in
drone
and
Travis,
which
is
totally
a
SAS
product,
they're,
not
cloud
native.
B
Actually,
the
neat
part
about
techsan
is
that
it
actually
comes
with
its
own
controllers
and
its
own
CRTs.
So
you
can
actually
build
these
things
up
using
your
familiar
kubernetes
tooling,
which
means
in
theory
we
could
actually
use
the
tooling
that
we
are
that
we
are
pulling.
We
can
actually
control
in
the
same
way
our
applications,
because
it's
just
yet
another
object
that
goes
in
our
cluster.
A
A
I'm
kind
of
in
the
same
place,
I
think
it's
it's
a
good
idea
and
it
seems
really
neat,
but
I
need
to
kick
the
tires.
A
little
bit
more
I
will
say
that
I
really
like
the
UI,
the
structure
of
the
UI
is
really
nice.
Everything
makes
sense
and
anything
that
you
can
click
on
like
drills
into
something
a
bit
deeper.
I
think
that's
pretty
cool,
but
I
just
wanted
to
shot
that
one
out
too,
as
well
as
like
another
tool
that
I'm
aware
of.
B
Yeah,
that's
pretty
interesting,
so
we
are
we've
gone
about
40
minutes
now,
let's
actually
start
winding
this
down
and
well
the
reason.
The
way
that
I'm
gonna
suggest
that
we
wind
this
down
is
thinking
about
where
we
are
now
what's
missing
in
this
space
and
and
what
is
what
else?
Could
we
actually
be
doing
in
the
cloud
native
space
to
to
make
this
work
out
better
I.
A
Think
I'd
like
to
see
better
structured
or
better
examples
of
blue,
green
or
canary
deployments
with
tests
associated,
and
that
might
just
be
like
me,
not
looking
hard
enough
at
this
problem.
But
anytime
I've
begun.
Looking
at
blue
green
I
get
the
idea
of
what
someone's
done,
but
I
like
I
would
love
to
see
like
some
implementation
details,
I
like
or
any
of
these
opinionated
tools
having
opinions
around
blue
green
and
like
what
they
specifically
do
to
test
it
and
I
feel
like
I'm.
Just
not
seeing
that
so
with.
B
So
really
what
I
can
do
is
I
basically
have
two
versions
of
my
application
deployed
and
I
can
use
my
load
balancer
or
in
this
case
my
service
to
just
change
the
label
or
the
selector
in
my
service,
and
now
it
can
point
at
my
green
from
my
blue
and
when
I
wanted
to
play
again.
I
can
just
deploy
another
blue
and
then
change
my
label
selector
again.
B
C
Yeah,
integrating
you
know,
they're
tools
like
launch,
dot,
Klee
and
I.
Think
there
are
more
which
enable
you
know,
like
I,
think
we're
missing
the
business
abstractions
on
this
stuff.
So
I
thought,
like
you,
said
it's
kind
of
hard
to
do.
If
you
need
to
go
into
the
the
Gritty
of
it
right
now,
but
I
think
the
business
abstractions
over.
You
know
if
we
deploy
different
versions
whose
certain
subset
of
customers
can
we
get
all
of
those
metrics?
C
Can
we
get
those
traces
back
in
because
when
you
automate
it
roll
out,
you
know,
can
you
increase
the
percentage
of
customers
that
are
seeing
those
things
have
that
all
controlled
in
a
given
Eddie's
native
way,
but
having
rolled
up
to
a
business
and
I'm
more
of
an
abstraction
I
think
that
stuff's
currently
missing
I
think
like
that
the
underpinning
kind
of
technologies
are
coming
up
stuff
like
service
mesh,
but
I
think
it's
the
is
the
abstraction.
That's
really
gonna
make
it
useful
which
doesn't
exist
today.
Yeah.
B
Actually,
that's
pretty
close
to
what
I
was
going
to
say.
We
built
all
this
tooling
that
helps
us
as
basically
as
technologists,
but
really
when
it
comes
down
to
its
the
business
and
a
lot
of
the
things
we're
talking
about
we're
we're
talking
about.
Cd
is
important
to
the
business,
but
when
we're
talking
about
metrics
or
trace
collection,
that's
not
important
to
the
business
because
they
only
care
about
the
SLA
that
was
on.
This
is
on
the
SLO
side.
What
we
really
need
to
do
is
mature
our
processes
enough
that
we
can
actually
merit.
B
A
C
Open
a
can
of
worms
right
at
the
end
and
say
the
biggest
from
here
is
probably
going
to
be
data.
When
you
know
we
have
a
lot
of
systems
need
to
talk
to
each
other
and
we
need
the
data
to
align
between
the
systems.
We
have
now
proliferation
of
environments
and
clusters
like
how
do
we
get
that
data
reliably
into
the
places
there
needs
to
be
to
make
out
testing
robust
enough
to
get
things
out
there?
It's
probably
an
episode
on
some
yeah.
B
That's
a
that's
a
big
conversation
that
if
we
could
answer
it,
we
would
be
working
at
VMware.
We
would
have
our
own
companies
doing
all
these
great
things,
but
we
can
definitely
iterate
on
it
so
with
that
I
think
we're
going
to
wrap
it
up.
Thanks
for
listening
to
the
cubelets,
I'm
Bryan
Liles
and
with
me
today
was
Nicolas
Lane
and
Charlotte
yeah
and
John
Harris.
Thanks
of
him
all
right,
we'll
see
you
next
time.