►
From YouTube: The Future of CI/CD With Kubernetes - B. Jung, C. Wilson, C. Sanchez, R. Zuber, S. Vohra
Description
The Future of CI/CD With Kubernetes - Brandon Jung, Christie Wilson, Carlos Sanchez, Rob Zuber, Sameer Vohra
Join us for KubeCon + CloudNativeCon in Shanghai June 24 - 26 and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hi
everybody
I'm
Christie
Wilson
from
Google
and
I'm
moderating
this
panel
on
the
future
of
CI
CD
with
kubernetes.
So
on
our
panel
here
we
have
Carlos
from
cloudBees.
We
have
Rob
from
circle
CI
we
have
Brandon
from
get
lab
and
we
have
Samir
from
pivitol,
so
I
think
maybe
we
could
start
off.
But
when
I'm
the
moderator
so
I'm
going
to
try
to
practice
aggressively
interrupting
when
things
start
taking
too
long
so
just
be
prepared
for
that.
I,
don't
know
how
you'll
know
it's
about
to
happen:
I'll
just
jump
in
anyway.
A
B
B
C
Hello,
I'm
Rob
I'm,
the
CTO
circle
CI
circle
CI
is
a
CIN
City
platform.
You
can
run
it
on
our
cloud
or
in
yours
and
we're
focused
on
helping
developers
get
their
their
code
into
production
faster
and
better,
been
there
about
five
years
and
I,
don't
know:
kubernetes
kubernetes
kubernetes.
We
run
a
big
part
of
our
platform
on
kubernetes
and
we
help
other
people
deploy
to
kubernetes.
We
do
all
kinds
of
kubernetes.
C
D
Subbing
in
for
my
awesome
colleague,
Priyanka,
who
wasn't
able
to
make
it
but
I
work
on
partnerships
and
everything
for
gitlab
and
we're
focused,
obviously
I
think
you
probably
know
us
as
a
source
code
management
tool.
We
obviously
also
have
a
pre,
robust
CI
and
we're
kind
of
tackling
have
been
tackling
us
for
a
while
around
a
single
DevOps
tool
chain.
You
can
give
me
feedback
on
that.
If
you
want
to
chat
because
people
seem
to
have
opinions
here
and
then
think
that's
the
big
one
hi.
E
A
We
can
probably
hang
on
to
the
mic.
We
can
just
go
backwards
next
time,
yeah,
so
kubernetes,
kubernetes
kubernetes.
I
feel
like
a
few
years
ago.
It
was
like
doctor
doctor
doctor.
So
that's
a
interesting
switch
okay.
So
maybe
the
next
question:
let's
talk
about
changes
in
the
CI
CD
landscape,
so
specifically
I
guess
around
kubernetes
and
containers.
Do
you
see
that
causing
significant
differences
in
how
we
view
a
delivery
deployment
integration?
That
kind
of
thing
do
containers,
make
things
easier
or
harder
go
back
through
that
I.
E
Mean
I
think
there's
definitely
pros
and
cons,
I
think
from
the
perspective
of
delivery
and
deployments.
I
think
there
is
a
difference.
Containers
are
great
where
they
package
things
up,
so
that
everything
is
super
easy
to
run
and
portable.
However,
you
do
end
up
losing
some
flexibility,
especially
when
something
along
the
lines
of
security
issues
come
up,
because
everything
is
packaged
up.
You
cannot
lose
that
so
make
some
things
easy
make
some
things
harder,
I
think
it's
kind
of
a
trade-off.
D
It
certainly
allowed
us
on
the
CI
space
to
think
about
it
quite
a
bit
differently
than
it
had
been
before
Cooper
a
great
place
to
run
it
and
I
think
probably
says
all
this
work
is
really
interesting
to
know
how
we
come
to
a
more
similar
answer
to
that
question:
we're
on
scheduling
but
certainly
really
useful,
even
if
even
where
we
are
today
I
think
anyone
would
argue
that
building
a
pipeline's,
far
easier
with
docker
and
kubernetes
than
then,
where
you
were
before.
That
said
well,
we're
all
pretty
biased
towards
kubernetes
in
the
room.
C
I
think
from
an
overall
future
of
CIN
City
perspective.
The
thing
that's
really
interesting
to
me
is
what
sort
of
our
use
of
docker
and
kubernetes
is
reflective
of,
so
they've
come
along
at
a
time
where
we've
been
shifting
architectures
from
things
that
are
very
monolithic
to
things
that
are
much
more
services
based
and
how
we
approach
the
incb
has
changed
a
lot
as
a
result
of
that.
C
B
Think
containers
have
revolutionized
see
ICD
in
the
sense
that
now
the
promise
of
this
bill
won't
run
anywhere
that
we
heard
many
times
with
different
languages,
different
runtimes
kind
of
container
docker
containers.
Specifically,
he
mostly
do
the
fact
that
you
can
run
a
container
and
get
a
totally
different
environment
in
seconds.
This
is
something
that
was
very
used
in
in
see
ICD
for
ever,
like
I
need
to
have
these
versions
of
Java
with
these
versions
of
this
other
thing,
and
now
I
have
to
have
20
VMs
with
totally
different
configurations.
B
I
think
containers
have
killed
that
we
must
not
forget
that
containers
are
not
yet
there
for
things
like
our
Internet
of
Things
devices.
There's
a
long.
A
big
chunk
of
things
are
not
there
yet.
So,
yes,
we
are
inside
this
kubernetes
bubble,
but
but
this
has
improved
the
life
of
our
CI
CD
configurations
for
a
lot
of
people,
so.
A
Maybe
just
to
elaborate
on
something
that
you
mentioned
Rob,
so
you
mentioned
that
maybe
with
the
complexity
of
the
systems
that
we're
working
with
now,
it's
a
fool's
errand
to
try
to
kind
of
piece
together,
something
exactly
production
like
for
testing.
Do
you
think,
do
you
think
that
it's
still
worth
attempting
to
test
before
you're
in
production,
or
do
you
think
that
this
means
we
have
to
leave
more
until
later?
And
then?
How
does
that
affect
this
whole
kind
of
shift
left
movement
where
we
want
to
do
more
earlier,
I,
like.
C
That
I'm
totally
not
dealing
with
this
question
kind
of
responsive,
here's,
a
microphone
so
so
I
think
yeah.
It
would
be
nuts
to
say,
like
we
should
stop
testing,
but
I
think
that
the
boundary
of
how
much
we
can
test
effectively
in
a
in
a
CNC
the
platform
before
pushing
is
shifting
a
little
bit
so
I
think
it
for
me
personally.
C
I
think
a
lot
about
designing
services
to
maximize
the
amount
that
you
can
test
within
the
constraints
of
a
single
service
versus
trying
to
put
the
whole
system
together
and
do
kind
of
ant
it
and
complete
testing.
And
then
it
changes.
So
I
think
it
changes
my
perspective
anyway
on
on
how
I
think
about
what
I
want
it.
C
What
I
want
to
build
to
make
it
as
testable
as
possible
in
a
small
component
and
then
how
I
sort
of
monitor,
manage
and
operate
a
system
once
it's
been
deployed
with
effectively
the
expectation
that
I'm
going
to
do.
You
know
a
slow
rollout
like
how
I
think
about
CD
changes
and
then
I'm
going
to
manage
the
expectation
that
at
some
point,
something's
gonna
fail
in
that
rollout
and
I'm
prepared
to
handle
that,
and
this
is
it
to
me,
that's
a
very
different
model
than
we
use
back
in
the
days
of
simple
monoliths.
B
Yeah
I
love
that
question,
because
I've
been
talking
about
progressive
delivery,
a
lot
in
the
last
months
so
progressively
livery
us
as
this
concept
that
groups
together
things
like
qunari
deployments,
Bluegreen
I
mean
progressive.
Delivery,
really
makes
something
really
scary,
like
continuous
deployment,
makes
it
easier
for
people
to
to
manage
and
to
be
bris
control.
Let's
say
and
I
think
that
we'll
see
more
and
more
these
I
guess
you
could
call
it
like
testing
in
production,
where
you
just
apply
to
some
people
and
see
what
happens
and
an
automatic
automate.
B
All
these
steps
and
I
think
it's
where
we're
gonna
go
because
it's
totally
impossible
to
I
mean
you
can
only
test
for
what
you
know.
You
cannot
test
for
what
you
don't
know.
So,
at
the
end
of
the
day,
is
you
have
to
control
these
blast
radius
when
you
deploy
and
have
the
tools
that
automate
a
safe
deployment
process,
I.
E
Guess,
just
to
echo,
it
was
said
previously.
The
one
kind
of
interesting
thing
that
our
modern
platforms
allow
us
to
do
specifically
kubernetes
is
to
differentiate
what
would
be
like
business
requirements,
testing
which
could
be
shift
left
and
really
happen
early
on
versus
the
more
experimental
side,
which
would
be
more
understanding
how
our
users
are
going
to
use
applications
which
fundamentally
becomes
much
harder
problem
to
reason
about,
and
you
generally
cannot
come
to
an
answer
other
than
trying
it
out.
E
A
D
I'll,
take
a
first
crack
at
this
I
think
we
already
saw
most
a
lot
of
the
movement
already
I
think
just
bluntly
in
the
industry.
I've
seen
a
lot
of
consolidation,
so
I
think
that
everyone
has
seen
that
I'm
biased.
We
tend
to
think
of
the
world,
more
I,
guess
more
monolithic
just
get
lab.
We
think
of
a
lot
more
in
one
application
than
historically,
where
it's
been,
it
seems
like.
Maybe
it's
going
that
way,
I
mean
I.
D
D
The
problem
is
that
every
individual
developer
has
their
favorite
tool
to
use
and
at
some
point
at
scale,
you
have
to
choose
something,
and
so
I
think
that
many
many
many
choices
that
have
been
made
over
the
years
are
gonna
have
to
start
coming
together
and
some
of
it
don't
naturally
come
together
through
acquisitions
or
decisions
also
see
that
security
shifting
left,
which
isn't
that
it
hasn't
already
been
there.
But
how
do
we
make
sure
we're
automating
that,
as
far
and
as
early
as
possible
is
something
we're
seeing
a
lot
more
from
our
customers?
Oh.
D
C
Just
to
take
the
very
vendor
specific
approach,
this
prediction
and
following
Brandon's
needs
a
little
bit.
I
think
that
one
thing
that
that
we
see
a
ton
from
where
we're
sitting
at
circle
CI
is
people
moving
away
from
wanting
to
do
a
lot
of
these
things
themselves
like
managing
the
tools,
building
and
customizing
tools.
So
they
can
focus
on
the
core
of
their
business.
C
I
would
say
from
an
overall
perspective,
I
think
I'm,
trying
to
figure
out
how
to
describe
what
I
was
saying
earlier,
but
like
yes,
we're
trying
to
take
as
much
as
possible
and
shifted
to
the
left,
but
I
think
there
we're
finding
points
where
that's
challenging
right,
where
there
are
certain
things,
I
think
just
Amir's
point
of
like
we
can't.
Yes,
we
can
do
the
functional
testing
early.
C
We
can
zoom,
you
may
have
a
clear
set
of
business
requirements
whatever,
but
there
are
things
we
just
we
aren't
going
to
understand
and
so
building
more
resilience
into
the
product
and
into
your
own
product
and
then
thinking
about
testing
happening
in
phases
all
the
way
out
into
production
and
focusing
on
resilience
out
at
the
right
kind
of
on
the
right,
so
that
we
can
recover
from
those
sorts
of
situations.
I.
B
B
Think
we'll
see
more
democratization
of
progressive
delivery,
type
of
features,
so
something
like
canary
deployments
that
right
now,
Netflix
or
Facebook
are
doing
we'll
see
how
that
reaches
the
masses
and
not
everybody.
You
don't
need
to
be
a
Facebook
to
do
to
do
that
and
that
will
reach
more
with
the
tooling
and
hopefully
the
tuning
will
we
are
building
at
cloud
vision
with
Jenkins
X
will
you
will
be
able
to
gain
the
benefits
of
doing
canary
deployments?
We
have
having
to
do
complex,
an
app
or
be
a
huge
organization
to
manage
them.
E
I
think
one
thing
that's
been
great
to
see
is
like
the
tooling
has
adopted
and
really
improved,
wear
first,
especially
like
the
some
of
the
deployment
platforms
that
are
available,
the
tooling
is
really
integrated
with
them.
I
think
the
thing
that
I'm
kind
of
interested
see
in
the
next
little
while
is
how
companies
are
able
to
adopt
this
tooling,
especially
have
pivotal.
E
We
work
at
work
with
really
large
enterprises
and,
while
developers
are
super,
enthusiastic
about
adopting
these
technologies
and
there's
some
growth
in
terms
of
like
learning
how
to
use
them
effectively,
it's
the
the
process,
size
changes
or
the
organizational
changes
required
to
actually
effectively
have
the
company
use
those
products.
I
think
that's
where
there's
a
lot
of
challenges
and
I
think
they'll
be
interested
to
see
how
that
kind
of
plays
out
where
the
technology
is
there,
but
the
process
still
has
a
shift
to
adopt
that
technology.
So.
A
Maybe
kind
of
a
related
question,
so
we
talked
a
bit
about
companies,
maybe
offloading
some
of
this
work.
We
talked
about
companies
being
able
to
take
on
more
sophisticated
deployment
strategies,
and
you
talk
about
organizational
changes
that
you
have
to
make.
Do
you
see
what
is
the
role
of
engineers
in
this
like?
Do
you
think
that
I
think
we
also
talk
about
engineers
focusing
on
delivering
business
value?
Should
engineers
care
about
their
CI
NCD
pipelines?
D
Loading
I
mean
I,
think
yeah,
I,
guess
I
I'd,
say
I.
Think
everyone's
gonna
need
to
know
continue
to
engage
in
this
space
and
even
I'll
be,
but
even
if
we
pretend
it's
not
developers
will
so
I,
don't
suspect
that
many
developers
are
just
going
to
advocate
on
having
an
opinion
they
want
to
work
where
their
tools
are.
D
We
had
a
customer
who
started
someone
spent
a
bunch
of
time
trying
to
get
them
hired
and
literally
the
person
quit
in
the
first
day
because
they
didn't
have
the
tools
they
wanted
so
and
that's
a
huge
company.
So
it
happens
still
that
that
matters
I
mean
whether
you
should
over
optimize
suit.
I,
don't
know,
I
also
think
from
the
standpoint
of
them
being
engaged
back
to
like
security
becoming
more
and
more
important.
They're
gonna
have
to
know
how
that
runs.
They're
gonna
have
to
be
engaged
in
it.
D
E
I
think
I
think
for
me
as
an
engineer,
I've
really
enjoyed
knowing
what
my
company's
mission
is
and
from
that
perspective,
I'm
biased.
That
way,
I
feel,
like
most
engineers,
really
get
a
sense
of
contentment
by
being
aligned
with
the
company's
mission.
So
if
it
matters
how
a
product
is
operated
and
like
how
the
CI
CD
set
up,
then
for
sure
they
would
care
to
know
and
be
involved
in
that.
Having
said
that,
I
think
the
promise
of
cloud
native
and
what
the
kind
of
revolution
is
happening
right
now
is.
E
So
it's
not
like
you're
only
doing
one
thing,
but
you're
only
doing
one
thing
at
a
time
which
then
allows
you
to
like
really
be
zoned
in
so
from
that
perspective
there
might
be
a
session
or
a
time
where
you
really
care
about
how
your
CI
CD
set
up
and
really
just
improve
that
process,
because
that
might
lead
to
business
improvements
and
any
much
of
your
focus
again
and
working
on
something
else.
At
that
point,.
C
Yeah
I
would
totally
agree
with
Samir's
point
about
being
mission,
driven
like
as
an
engineer,
I
want
to
be
driving
the
value.
That
is
what
my
company
is
trying
to
drive,
but
I
would
say
being
in
the
middle
of
this
space,
as
we
all
are.
If
the
tools
are
getting
in
your
way
and
frust
like
preventing
you
from
getting
something
out
like
the
ability
to
build
something
and
then
see
it
in
the
hands
of
your
users,
is
a
big
part
of
that
kind
of
enrichment
of
being
mission
driven.
C
If
the
tools
are
getting
in
your
way,
then
that's
gonna
frustrate
you
as
an
engineer,
and
it's
gonna
force
you
to
be
really
thoughtful
about
where
you
know
the
tools
that
are
being
used,
I
think
you
mentioned
in
there
specific
groups,
I
do
see
a
shift
and
it
depends
on
the
size
of
your
company,
but
many
companies
already
have
this
towards
and
I
think.
The
previous
speaker
was
talking
about
a
meet-up
of
developer
productivity
groups.
C
Right,
like
that
notion
of
teams
that
are
in
we
focused
and
really
trying
to
build
out
the
best
possible
tooling
to
help
the
engineers
then
focus
on
the
very
small
thing
that
they're
concerned
about
today,
which
is
hopefully
not
the
pipeline
today,
because
the
pipeline
is
there
and
it
just
works
if
I
as
a
product,
engineer
I'm
trying
to
build
something
for
customers
and
every
day,
I'm
thinking
about
how
can
I
get
this
pipeline
to
work
properly?
For
me,
that's
a
sign
of
a
pretty
bad
pipeline,
I
would
say
I.
B
You
know
like
this
broad
because
some
machine
is
down
or
because
the
clouds
is
not
working
today
or
something
and
yeah.
It's
it's
something
that
you
you
want
to
automate
things,
but
at
some
point
you
will
just
want
them
to
work,
and
then
you
just
want
to
move
on
to
the
next
thing.
So
it's
something
that
it's
hidden
from
a
lot
of
people
and
a
lot
of
people
only
know
what's
going
on
and
the
effort
it
takes
to
set
up
those
things
when
they
brought
when
they
break.
A
B
Mainframes
yeah
I
think
we
are,
as
I
said
before
we
are
in
that
bubble.
We
are
all
kubernetes
funds,
then
you
talk
to
people
and
they're
like
oh
yeah.
I
cannot
use
kubernetes
because
you
know
I'm,
building
device
firmware
and
so
I
have
to
run
it
in
this
device
or
I
have
to
do
these
other
things.
So
there
is
a
lot
of
use
case
out
there
that
are
not
covered
by
coronaries.
There's.
C
Yeah
I
mean
I.
Think
that's
the
key
is
what
is
your
deployment
target
right
like
the
thinking
about
and,
of
course,
there's
two
sides
to
this
like?
Where
is
the
thing
I'm
building
going
and
then
how
do
I
operate
the
tooling
to
do
the
testing
right
now?
Those
are
those
are
sort
of
two
things
they're
testing
in
deploy,
so
some
of
the
things
you
mentioned
are
top
of
mind.
For
me,
I
mean
people
still
build,
desktop
apps,
that's
a
thing
right.
Mobile's
I
mean
we.
C
C
We
see
try
to
think
of
other
examples,
yeah
I
guess
we
see
a
lot
of
demand
for
specific
hardware
types,
for
example,
even
on
server-side
applications
like
GPU
and
stuff,
like
that.
That
feels
like
it's
still
a
stretch,
you
know
specific
virtualization
capabilities
like
there's
just
more
stuff
than
I
would
have
thought
that
people
are
losing
that
are
kind
of
an
independent
of
our
view
of
that
everything
can
be
abstracted
into
a
container.
D
I'll
just
check
it
out.
We
see
a
whole
lot
of
stuff.
That's
not
kubernetes,
so
I
also
think
a
lot
of
our
discussions,
implicitly
sort
of
suggest
that
what
everyone's
trying
to
develop
is
at
massive
scale,
I
mean
at
the
point
they're
saying
you're
going
to
Canary
deployment,
you're
implying
you
have
a
pretty
large
application,
which
is
fantastic,
but
the
majority
of
applications
aren't
actually
that
so
I
still,
we
still
see.
We
still
still
see
a
lot
of
need
for
the
different
environments
and
and
I
don't
see
that
changing
anytime
soon.
D
So
I
think
this
is
very
useful,
but
as
much
as
it
can
be
abstracted
in
any
way
shape
or
form
to
serve
the
rest
of
what's
outside
of
kubernetes
is
going
to
be
a
really
important
part.
If
we
want
this
to
serve
the
rest
again,
I
think
if
we
want
to
put
our
heads
down
say
most
SAS
applications
agree,
kubernetes,
I,
think
most
people
never
look
like
yeah
sure
we
agree
with
that.
D
E
Yeah
I
totally
agree
what
you
just
said:
we're
for
concourse
just
some
numbers.
We
have
a
roughly
about
a
quarter
of
our
deployments
on
kubernetes,
but
we
still
have
ton
of
like
Windows
applications
being
built,
Mac
OS,
X
applications
or
iOS
apps,
where
users
want
to
be
able
to
like
use
our
system
to
test
their
and
to
build
builder
applications.
E
So
we
don't
see
that
going
away,
I
think
for
us
it's
how
we
can
evolve
our
products
such
that
we
don't
leave
those
behind,
but
are
so
able
to
leverage
the
things
that
are
offered
on
kubernetes,
for
example,
so
figuring
out
how
we
can
balance
both.
So
you
kind
of
deliver
both
that's.
Definitely
a
challenge
that
we're
kind
of
looking
forward
to.
A
Okay,
so
maybe
four
four
people
in
the
audience
so
assuming
that
you're
bought
into
the
idea
of
continuous
delivery
in
general,
which
maybe
maybe
that's
not
the
right
assumption
to
make
so
just
correct
me
if
that's
wrong,
but
assuming
your
butt
into
that.
What
do
you
think
is
the
biggest
like
like
what
change
could
people
make
today?
A
That
would
give
them
the
most
benefit
and
do
you
have
any
stories
around
seeing
that
kind
of
thing
everyone's
been
really
great
to
moderate
so
far,
because
everyone's
been
taking
a
very
reasonable
amount
of
time
so,
but
feel
free
to
dive
into
stories.
If
you
like,
I,
can
jump
in
if
they're
too
long.
E
E
E
I
think
the
biggest
thing
for
us
would
be
getting
buy-in
from
all
of
the
kind
of
component
groups
or
the
functional
groups
in
an
organization
as
opposed
to
kind
of
just
working
with
developers.
So
if
the
whole
company,
or
all
the
folks
kind
of
involved
that
are
touching
an
application
from
committing
the
source
code,
all
the
way
to
the
application
delivery
or
having
it
deployed
if
everyone's
kind
of
involved,
we
kind
of
call
that
pivotal.
E
D
So
if
that
whole
cycle
isn't
all
be
able
to
run
really
quickly,
it's
just
like
doing
a
it's
like
having
a
supply
chain
right
or
having
a
in
a
supply
chain,
and
you
have
a
constraint.
So
if
you
open
up
the
constraint,
you
can
deliver
really
quickly.
If
you
can't
get
back
upstream
to
where
you're
planning
and
that's
all
tied
together
again,
you
won't
get
there
and
tools
are
a
piece
of
it.
People
are
piece
of
it
in
process
or
a
people
are
part
of
it,
but
I
think
we
find
obviously
with
get
lab.
D
So
they
had
to
be
able
to
think
about
the
way
in
which
they're
actually
building
into
smaller
and
smaller
little
pieces
right.
So,
instead
of
saying
we
say,
MVP
I
think
an
MVP
is
nice,
but
it's
still
a
big
chunk
of
work,
like
think
of
it
as
a
minimal,
viable
change.
Right,
I
will
ship
literally
if
I
change,
one
word
I'll
still
one
one
word
changes,
but
it's
better
than
it
was
yesterday
I'll
ship.
It
now
CD
enables
that.
But
you
have
to
start
with
the
notion
of
innovation
or
of
iteration
at
the
very
front.
D
You
have
to
be
willing
to
take
everything
on
the
front
end
all
the
way
through
and
get
into
that
mindset
of
turn
turn
turn
turn
ship
and
that
I
think
that
whole
tools
where
you
gotta
have
all
the
pieces,
because
otherwise
you're
able
ship
at
the
end.
But
no
one
at
the
front
end
is
still
you
know,
con
bonding
and
up
to
a
bunch
of
little
P,
a
bunch
of
big
pieces
and
those
chunks
aren't
gonna,
make
it
through
as
fast
so
I.
Think.
That's
what
we
see
I.
C
Would
agree
with
that
I
wanna
go
back
to
the
risk
mitigation
idea
for
a
second
I.
Think
one
of
the
thing
I
remember
in
2011
I
started
a
company
with
someone
and,
and
he
was
sort
of
doing
product
and
I
was
leading
technology,
and
he
and
sort
of
CD
was
becoming
a
thing
at
the
time.
Rather
some
Etsy
blog
posts
or
who
knows
and,
and
he
said,
I
think
we
should
do
this
continuous
deployment.
I
was
like
no
you're
crazy
deployments
are
risk
and
risk
is
scary
and
I'm.
C
The
one
that's
gonna
have
to
do
it
and
I
don't
want
your
scary
risk
and
like
it,
only
took
about
24
hours
of
actually
reading
the
blog
post
to
be
like
wait
a
second.
This
makes
sense,
because
what
we're
doing
is
taking
that
risk
and
minimizing
it
right
into
these
tiny,
tiny
little
except
acceptable
chunks,
and
it's
it's
really
that
shift
in
mindset
that
I
think
has
to
happen
inside
the
organization.
I
mean
Brandon's
points
like
tool.
Tools
are
great,
but
tools
just
enable
you.
C
The
other
thing
that
I
would
say
in
terms
of
tools
to,
but
now
now
going
back
to
tools
how
to
think
about
this
in
a
way
to
help
you
get
over
the
hump
really
feeling
confident
in
what
you
have
deployed,
meaning
improving
your
observability
things,
like
exception,
I,
don't
know
what
they're
called
the
roll
bars
of
the
world.
I'll
just
give
a
shout
out
to
my
friends
over
there
like
being
able
to
so
when
something
does
go
wrong.
C
B
Think
continuous
delivery
is
first
and
foremost
a
cultural
change
right.
It's
you
need
the
culture
of
your
group
or
company
to
change
and
understand
what
it
means
and
tear
down
the
silos
and
adopt
DevOps
I
mean
this
is
what
all
DevOps
was
about
at
the
beginning
before
every
everything
was
DevOps,
and
so
that
was
the
that's
the
main
idea.
I
mean
you
need
a
cultural
change
first
and
then
tools
will
follow.
B
Obviously,
it's
pretty
hard
to
do
continuous
delivery.
You
don't
have
the
tools,
I
would
say
it's
impossible,
but
cultural
change
is
first,
you
cannot
have
operations,
people
developer
some
different
sides
of
the
wall
and
fighting
over
who
has
to
deploy
or
maintain
what
and
that's
that's
the
main.
That's
the
main
issue
you
have
to
face,
and
the
sooner
the
positive
this
soon
is
the
puzzle.
The
better.
A
Okay,
so
along
the
lines
of
sort
of
advice
for
people
in
the
audience,
do
you
have
any
advice
about
how
to
get
the
right?
The
right
size
of
CI
CD
for
your
organization
like
whether
you
need
to
have
use
tools
that
require
an
entire
team
to
run
versus
something?
That's
just
quick
and
fast
and
works
well
and
like
when?
When
and
when,
should
you
have
a
dedicated
team
that
that
runs
your
CI
CD
versus
just
like
small
things
that
work
for
each
individual
team.
B
That's
an
interesting
question
because
for
some
time
there
was
the
opinion
of
you
know
everybody
should
not
do
the
verbs.
Everybody
should
be
in
the
same
doing
the
same
things
and
not
just
throwing
something
to
the
dev
ops
team
I
mean.
Definitely
you
should
not
call
your
operations
team,
the
dev,
ops
team.
That's
we've
seen
that
a
lot.
B
B
B
A
C
Have
thoughts
a
couple
things
so
on
the
team
front,
I
totally
agree:
I
rant
about
like
DevOps
team's
constantly
as
a
title,
I
apologize
to
anyone
in
the
room,
who's
in
the
demos
team,
but
I
think
this
notion
of
developer
productivity
engineering
efficiency,
like
teams
that
do
shared
work,
basically
not
I'm,
building
your
pipeline
for
you
but
I'm,
building
the
common
tools,
yeah
building
common
tools
that
other
teams
can
use
to
deliver
that
stuff.
So
so
for
us
I
mean.
C
Obviously
we
we
run
a
cloud
hosted
CI,
so
our
CI
n
CD,
and
so
we
don't
really
think
about
you,
giving
that
to
another
team
in
your
org,
but
rather
giving
a
much
of
it
to
us.
But
even
if
you
do
that,
you're
going
to
have
some
standard
pipeline
that
you
might
use
across
multiple
projects
right
and
so
building
that
kind
of
tooling
and
sharing
it
across
team.
So
they're
not
rebuilding
the
same
things.
You
know
that
are
tied
to
how
you
think
about
building
out
your
repos
or
how
your
deploy
runs.
C
You
know,
whatever
those
things
are
having
you
know
and
a
small
in
a
small
org.
It
might
just
be
that
you
get
together
and
chat
about
it
and
someone
implements
it
in
a
slightly
larger
org.
You
might
start
to
have
one
person,
two
people
who
are
responsible
for
this
engineering
efficiency,
developer
productivity,
whatever
you
want
to
call
it
and
I.
Just
think
that
is
it's
leverage
at
some
point
right,
letting
everyone
build
their
own
version
of
the
pipeline
on
top
of
the
tool.
D
D
So
I?
Guess
it's
a
little
different,
because
at
least
if
you
adopted
gitlab,
you
would
end
up
with
a
bunch
of
different
pieces.
That's
it.
We
still
have
you
seen
a
great
with
a
lot
of
different
places.
I
think
the
the
planning
is
the
part.
That's
its
most
intriguing
to
me,
as
of
late
is,
is
the
planning
team
have
visibility
into
the
pipeline
and
vice
versa,
because
that's
usually
where
the
break
kind
of
becomes
like
someone
might
run
your
pipeline?
D
But
if
they,
if
the
team
that's
doing
the
planning
sees
when
their
pipeline
gets
implemented,
they
can
see
it.
There's
there's
a
different
level
of
interaction.
If
they
have
the
visibility
there,
then
then
I
think
we'd
seen
before,
but
I
think
it's
a
newer
area.
Whether
at
least
this
fully
integrated
notion
is
a
newer
idea
when.
D
E
That's
slightly
out
there
for
performance
reasons
or
any
other
reasons
where
then
they
really
want
the
flexibility
and
then
they're,
probably
going
to
take
the
trade-off
of
like
managing
their
own
system
and
kind
of
taking
that
burden
on
looking
at
it
internally
at
pivotal,
we
use
Concours
extensively
at
pivotal.
At
this
point,
it's
about
500
engineers
can
are
using
the
system,
what's
kind
of.
E
Naturally,
or
an
organically
kind
of
a
wall
is
we
have
a
managed
sister
or
managed
version
of
concourse
that
my
team
actually
runs
so
that
any
team,
if
they
just
care
about
running
a
pipeline,
they
don't
want
to
take
on
the
burden
of
managing
the
system.
They
cannot
have
that
available,
but
other
there
are
teams.
E
There
are
teams
that
run
the
version
of
conquerors
themselves
as
well,
and
the
reason
they
choose
to
do
so
is
because
they
there's
one
team
that
is
building
artifacts
in
multiple
cloud
regions,
and
this
way
they
have
workers
distributed
across
the
globe.
There
is
another
team
that
is
built
working
on
data
products
and
they're
like
shipping
artifacts
that
are
usually
about
5
to
10
gigabytes
in
size
and
what
they
have
done
with
their
deployment
of
concourse
is
like
optimize,
the
network
topology.
A
E
Think
for
me,
there's
no
like
one
tool
that
kind
of
solves
a
problem.
I
think
I
prefer
to
think
about
it
as
like
pick
the
best
tool
that
gets
the
job
done
and
really,
if
it's
cloud
native
or
not
that
doesn't
matter
as
long
as
they're
kind
of
continuously
thinking
about
the
reasons
and
then
re-evaluating
those
pick
the
to
let
works
the
best
and
also
work
on
process
process
is
important.
B
I'm
gonna
say
something
that
happened
15
years
ago
when
we
were
beating
Apache
maven
to
the
CTO
of
American.
Express
people
were
complaining.
Like
you
know,
maybe
it
was
all
about
the
standardization
of
your
bill
and
people
were
saying.
Oh,
but
my
bill
is
special
under
his
answer
was
like.
Maybe
it
shouldn't
be.