►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Repeatable Deployments with Kubernetes, Helm & Bazel - Rohan Singh, Hustle Inc
Can you run a single command to build your applications, generate the appropriate Kube manifests, and deploy everything to each of your clusters? If you've tried to set this up, you know that you can quickly end up with a rat's nest of custom scripts and repetitive YAML blobs. Even tools like Helm don't completely solve the problem. In this talk, we'll cover how to wrangle this complexity with Bazel, a multi-platform build tool from Google. With Bazel, we can build Docker images, generate Kube objects, and deploy to a live cluster in a single step. We'll also see how to use Bazel to parameterize YAML files and deploy slightly different configurations to different environments, without having to repeat and duplicate entire manifests. Finally, we'll cover how Bazel can be extended to compile and deploy Helm charts as well.
https://sched.co/MPYs
A
All
right
hold
on
folks.
We
have
full
room
again:
curly
CI
CD
is
a
popular
topic,
so
I'm
curious.
How
many
of
you
have
figured
out
your
you
know,
deployment
story,
and
especially
things
like
config
generation,
config
template
tank
any
of
that
stuff
right
and
how
many
of
you
are
really
looking
for
a
solution
in
that
space
that
any
current
tooling
doesn't
cover
all
right.
Interesting!
Well,
that's
that's!
B
So
yeah,
my
name
is
Rohan
and
I'll,
be
speaking
with
you
about
how
you
can
use
basil,
which
is
Google's,
multi-platform,
build
tool
to
manage
configuration,
deploy
things
to
cube
clusters
and
also
try
to
get
some
helm
in
there.
At
least
that's
what
my
session
abstract
says,
but
in
all
seriousness,
a
lot
of
fun
stuff
about
using
basil
with
Cube
has
been
covered
fairly
well
in
some
sessions
over
the
past
couple
days.
B
In
fact,
let
me
ask
how
many
folks
in
the
room
are
familiar
with
basil
at
all,
okay,
awesome,
well,
I
figured
we
could
change
it
up
a
bit
for
those
of
you
who
haven't
heard
of
basil
or
seeing
anything
about
it
at
cube
con.
Yet
no
worries
I'm
still
gonna
cover
the
basics,
but
I
also
want
to
tell
you
a
story
about
trying
to
wrangle
configuration
and
try
to
wrangle
code
while
introducing
cube
to
a
new
organization
story.
What
went
well,
but
also
a
story
of
what
all
perhaps
didn't
go
so
well.
B
So,
like
a
lot
of
stories,
this
one
has
a
prologue.
Let
me
just
quickly
tell
you
about
myself
and
how
I
ended
up
becoming
in
for
an
engineer.
I
originally
started
to
get
into
infrared
container
space
back
in
2013
working
on
Spotify
his
homegrown
container
framework
helios,
as
you
might
have
heard
at
some
point.
We
completed
and
released
this
agent
based
orchestration
platform
written
in
Java
literally
one
day
before
another,
somewhat
popular
project,
which
at
the
time
was
also
an
agent-based
container
orchestration
platform
written
in
Java
known
as
kubernetes.
Maybe
you've
heard
of
it.
B
B
I
spent
a
while
working
at
a
place
that
doesn't
really
use
cube
a
lot,
so
a
small
social
networking,
startup
kind
of
like
MySpace,
but
you
can't
edit
CSS
after
that
I
found
myself
at
hustle,
where
I
am
today
so
hustles
main
product
is
a
text
messaging
tool
confused
mostly
by
nonprofits,
and
political
campaigns
to
reach
donors
or
voters
works
pretty
brilliantly,
because
there's
a
person
behind
each
text
folks
can
respond,
have
an
actual
conversation
one-on-one,
but
also
more
interestingly,
from
the
infra
side.
Hustles
engineering
team
is
right
at
an
inflection
point.
B
B
Some
of
the
biggest
pain
points
I
noticed
right
away
at
Hustle
were
around
deployment
and
configuration
management.
The
process
were
rolling
out.
A
new
service
was
complicated
involved,
committing
code
also
making
changes
in
a
terraform
repo,
so
configuration
didn't
really
have
a
single
source
of
truth.
For
example,
the
value
of
an
environment
variable
might
live
in
terraform,
but
it
would
also
simultaneously
live
in
a
container
definition
in
AWS
ECS
ECS.
B
If
you're
not
familiar
with
it,
is
Amazon's
kind
of
docker
composed
plus
on
ec2
but
anyways
to
roll
out
a
new,
say
value
for
and
Bart
engineer
would
run
a
tool
to
change.
The
value
in
ECS
then
go
ahead
at
the
same
value
in
the
terraform
repo.
Also
kick
off
a
job
to
build
a
docker
image,
deploy
it
all
this
stuff.
Hopefully
this
would
all
be
done
in
a
correct
and
consistent
order
without
any
mix.
B
Ups
anywhere,
this
system
worked
about
as
well
as
you'd
expect,
which
is
to
say
it
actually
works
most
of
the
time,
but
then
it
fails
sometimes
and
then
it's
a
disaster,
but
this
is
areas
familiar
with
and
I
figured
a
good
place
to
start
on
a
project
and
I
also
figured
hey.
It's
been
a
couple
of
years,
I
think
the
last
time
I
checked
out
cube
at
this
point
was
2016,
maybe
2017.
B
The
ecosystem
around
cube
seems
to
be
getting
pretty
mature.
Let
me
take
a
look
see
how
it's
going
and
see
how
easy
this
eventually
I
wanted
to
get
to
a
point
where
all
the
configuration
for
a
service
would
live
with
that
services
code,
and
it
also
do
the
same
for
all
the
configuration
for
all
the
cube
infrastop.
We
needed
ingress
controllers
service
accounts.
What
have
you
pretty
quickly
ran
into
an
issue
at
hustle
like
a
lot
of
places,
we
have
a
few
different
environments:
dev
pre,
prod,
prod
local
developer,
workstations,
potentially
ephemeral
environments.
B
Each
of
these
environments
is
similar
but
different,
slightly
different,
slightly
different
config
Baria
Buhl's
different
setups.
One
of
the
first
questions
I
had
then
was
you
know:
do
this
Greenfield?
What's
what's
the
best
way
to
to
manage
all
this
configuration?
There's?
No,
we
weren't
really
tied
to
anything
at
the
point.
At
that
point,
so
I
figured
it
would
be
really
great
to
have
something
where
we
could
take
all
the
config
files
for
an
environment.
Have
some
sort
of
templating
or
substitution
be
able
to
build
images
generate
the
final
config
deploy
it
to
the
cluster.
B
Also
figured
that
you
know
this
would
surely
have
been
solved
right.
So
I
reached
out
to
folks
I
knew
who
were
running
fairly
large
cube
clusters
in
prod
and
I
asked
you
know.
How
have
you
solved
this
and
turns
out?
It
has
been
solved
kind
of
by
a
bunch
of
tools
and
projects
and
stuff
glued
together.
We've
got
things
like
Jason
net
case
annette
jenkins
x
scaffold.
How
am
your
favorite
bash
scripts,
even
even
terraform,
so
each
of
these
projects
in
its
own
way
attempts
to
address
these
issues
and
some
are
more
opinionated
than
others.
B
B
So
if
you
ask
basil
people
and
what
is
it
and
why
should
I
use
it?
They'll
be
quick
to
list
off
a
few
really
big,
positive
attributes
of
basil.
It's
fast
it'll,
speed
up
your
builds
can
build
everything.
Every
language
things
you
haven't
even
heard
of
you
can
set
up
a
massive
remote,
build
farm
cash.
Everything
build
your
entire
monetary
flow
in,
like
three
seconds
be
just
like
Google,
it's
gonna
be
awesome,
something
like
that.
B
So,
if
you
remember
like
my
original
problem
here
was
really
just
like
too
lazy
to
write
some
scripts
to
templatized,
something
a
mole
or
something
but
I
figured.
You
know
why
not?
Why
not
go
down
this
rabbit
hole
for
a
little
while
and
see
where
it
leads.
Honestly.
For
me,
though,
the
biggest
most
important
virtue
of
basel
and
what
made
it
worth
adopting,
even
though
it
can
have
quite
a
learning
curve,
is
that
it's
highly
deterministic
same
stuff
goes
in
same
stuff.
B
Comes
out
with
it,
you
stop
doing
things
like
running
docker,
build
and
just
running
cube.
Ctl
apply
on
whatever
the
result
is
fundamentally.
Basil
is
a
tool
where
you
define
some
inputs
and
just
like
any
other
build
tool,
and
you
define
actions
to
run
on
those
inputs
and
you
get
outputs.
For
example,
you
take
your
c
source,
you
run
GCC,
you
get
a
binary.
B
You
take
your
conflict
templates,
you
run
a
command,
you
get
the
realized
config
for
an
environment,
but
what
feasible
is
really
good
at
is
guaranteeing
that
when
the
inputs
are
the
same,
the
outputs
are
the
same
down
to
the
byte,
so
how's
this
different
than
then
doing
old-style
docker
built
and
just
working
with
the
result.
I
I
think
really
again.
What
stood
out
to
me
here
was
that
the
philosophy
behind
this
tool
I
think
matches
the
philosophy
a
lot
of
us
have
had
about.
You
know
we
treat
our
compute
as
cattle,
not
pets.
B
We
treat
our
clusters
as
cattle,
not
pets,
and
what
Bayes
is
allowing
you
to
do.
That
is
treat
your
deployment
artifacts
as
cattle,
not
pets,
so
instead
of
say,
docker
build
on
a
codebase
and
then
getting
a
specific
digest,
and
now
you
have
to
keep
this
image
around
forever
and
hope
you
never
lose
it
or
whatever
your
other
binaries
and
artifacts.
Are
you
know
that,
as
long
as
the
code
going
in
is
the
same,
you
get
the
same
stuff
out
so
going
a
little
deeper
into
how
this
works
with
docker
images.
B
Instead
of
writing
a
docker
file,
you
write
a
basil,
build
file.
It
says
what
your
inputs
are
to
the
image.
In
this
case,
just
a
single
javascript
file,
for
example,
and
basil
assembles
a
docker
image
with
those
inputs
since
on
some
level,
docker
image
is
just
a
tarball
of
sorts
and
you've
told
basil
about
all
the
files
that
are
supposed
to
go
into
that
tarball.
You
don't
even
need
to
mess
with
docker
itself.
You
don't
even
need
the
dr.
B
daemon
running
and
again
as
long
as
your
input
is
the
same,
the
resulting
image
is
the
same
right
down
to
the
image
digest.
Of
course,
if
your
image
consists
of
things
other
than
simple
files
on
disks
well,
it
gets
a
little
more
complicated,
but
you
can
still
do
that
as
well.
You
can
use
the
output
of
a
basil
target
as
the
input
to
another
target.
So,
for
example,
let's
say
you
have
a
target
that
compiles
some
Java
builds
a
jar.
B
B
At
this
point,
though,
you've
got
a
working
build
and
everything
is
looking
pretty
peachy.
All
you've
got
to
do
is
actually
deploy
this
somewhere
say
to
a
cube
cluster
and
fortunately,
there's
a
pretty
straightforward
way
to
do
that
as
well.
The
rules
KSR
project
provides
basel
rules
or
logic
for
interacting
with
cube,
so
you
just
make
a
new
basil
target
pointed
at
your
image
target
and
local
deployment
config,
and
it
will
happily
take
care
of
applying
changes
to
your
local
cube
cluster.
B
So
you've
got
multiple
cube
clusters.
That's
not
really
problem
either
Basil's
config
language,
star
lark,
is
basically
Python,
so
you
can
just
write
a
nice
macro
that
spits
out
a
target
for
each
of
your
environments,
using
a
different
configuration
for
each
and
you
know,
tada
you've
now
got
the
ability
to
build
images,
deploy
them
to
multiple
cube
clusters
just
by
running
a
single
command,
because
again
the
input
here
is
yeah.
B
Well,
the
output
is
some
other
gamal
and
and
that's
a
big
Basil's
good
at
handling
so
I
mean
at
this
point
clearly
had
motivations
other
than
just
cleaning
up
gamal.
Instead,
I
was
hooked
on
the
idea
that
we
could
make
our
entire
build
and
release
process
faster
and
we're
stable
just
by
defining
basil
targets
and
rules
for
it
and
all
the
pieces.
We
needed
to
make
this
work
and
and
seem
to
exist,
so
all
good
right.
B
Well,
there
was
just
basically
one
issue
which
is
that
to
make
everything
work
for
you,
you
really
need
to
define
targets
for
everything
you
want
to
build
in
your
repo.
You
really
really
just
have
to
commit
to
this
way
of
doing
things
and
hope
that
the
rules
exists
to
build
things
in
the
way
you
want,
which
they
probably
don't
totally
exist.
I
argued
hey,
you
know
what
basil
is
pretty
much
infinitely
extensible
the
behavior
of
each
basil
rule
is
defined
in
code.
The
basil
core
just
ties
everything
together
and
runs
everything
that
needs
to
run.
B
Well,
as
the
basil
docks
themselves
say,
quote:
rules
are
for
advanced
users.
We
expect
that
most
people
will
never
have
right
one.
They
will
only
load
and
call
existing
rules
and
honestly,
yeah
rules
turned
out
to
definitely
be
for
advanced
users.
While
up
to
this
point,
I
think
I've
explained
Basel
at
a
high
level,
took
a
fair
amount
of
time
to
become
familiar
enough
with
it
to
be
able
to
write
rules
that
work
like
they
should.
B
Probably
at
this
point,
only
a
fraction
of
our
engineering
team
has
even
written
any
Basel
rules
themselves,
even
though
it's
something
we've
had
to
tackle
to
meet
our
needs.
For
example,
we
at
this
point
had
all
of
our
build
processes
for
our
binaries
and
images,
and
arcade
s
manifests
defined
using
Basel
targets,
so
it
seemed
like
hey.
You
know
it's
a
really
good
idea.
Let's,
let's
just
try
to
run
all
this
locally,
it
would
be.
B
But
that
said,
it
would
be
nice
to
hide
a
lot
of
the
complexity
of
cube
for
developers
who
aren't
working
on
infra
ray.
So
one
great
tool,
I
found
for
this
was
tilt
tilt,
gives
you
a
friendly
UI
for
what's
going
on
with
your
build,
your
development
cube
cluster.
All
of
that
and
it
integrated
pretty
seamlessly
with
the
normal
way
of
building
dock
Ramage's.
It
would
even
keep
track
of
dependencies.
B
Rebuild
images
do
live,
reloads
people
liked
using
it
and
it
pretty
much
all
worked
out
of
the
box
as
long
as
you're
building
docker
images,
the
normal
way,
which
well
we
no
longer
are
so
to
take
advantage
of
tilt
and
probably
to
take
advantage
of
any
similar
tools
in
the
future.
We
have
to
drop
back
into
star
LARC,
the
basil,
config
language
and
write
rules
that
expose
the
parts
of
the
basil
graph
that
these
tools
need.
Honestly,
it
was.
B
B
That
said,
most
of
hustles
application
code
is
in
no
js',
and
this
has
been
a
fun
exercise
with
with
docker
files.
It
node
seems
fairly
straightforward
right,
like
it's
just
JavaScript,
you
put
it
in
the
container.
You
run
note:
how
hard
can
it
be
and
there's
also
beta
node
J
s
rules
available
for
basil,
but
they
only
cover
certain
scenarios.
B
So
if
you're
like
me-
and
you
had
your
head
kind
of
willfully
buried
in
the
sand
regarding
JavaScript
so
the
past
few
years,
you
buy
view
a
little
surprised
to
find
that
it
has
a
complex
and
thriving
build
tool
chain.
So
there's
various
flavors
of
JavaScript,
which
are
transpiled
to
plain
old
echo
script
using
various
transpilers
our
tool
chain
at
hustle,
includes
fun
tools
like
babble
and
flow
and
mocha,
which
unfortunately
Basil's
rules.
Nodejs
is
mostly
focused
on
plain
old,
JavaScript
and
typescript.
B
So
again,
we
ended
up
writing
our
own
rules
to
deal
with
things.
In
some
cases
we
were
definitely
blessed
because
we
found
contributions
by
Basel
community
members,
but
by
and
large
it's
been
DIY
on
this
front.
It's
been
particularly
fun
to
deal
with
when
it
comes
to
building
docker
images
on
developer
laptops.
B
B
B
It's
not
gonna,
be
a
e.l.f
binary.
It's
gonna,
be
you've,
now
got
Darwin
binary
that
you're
putting
in
your
docker
image,
because
you
use
basil
to
build
this
binary
on
your
Mac.
This
is
proven
to
be
a
particularly
tricky
problem
to
solve.
I
mean,
obviously
one
one
approaches:
okay,
everyone
switch
to
Linux,
but
that
hasn't
been.
That's
that's
not
something
that
we
were
able
to
do
overnight.
B
So
this
has
been
pretty
tricky.
Workarounds
aren't
great.
Yet
what
we've
been
doing
instead
is
using
an
experimental
basil
feature
that
lets.
You
run
certain
actions
in
a
docker
sandbox.
So
then
we
build
native
modules
in
that
sandbox.
If
you're
on
a
Macbook
that
sandbox
is
docker
and
a
winix
vm
you
get
linux
binary,
it
all
works
out,
but
even
once
we
have
these
modules
built
for
the
correct
architecture.
B
If
you're
not
familiar
with
this
problem,
which
I
wasn't
super
familiar
with
it,
you
can
go
read
about
it
and
it's
based
on
a
lot
of
old
decisions,
but
I
mean
for
most
node.js
apps.
This
works
out
fine,
once
you've
actually
built
this
giant
node
modules
directory
for
basil,
though,
to
be
able
to
cache
things
to
meet
guarantees
about
determinism
to
know
that
the
inputs
are
the
same
or
whether
the
inputs
have
changed.
B
B
That
said,
what
I
do
this
again
absolutely,
and
the
main
reason
is
because
so
the
local
development
side
of
this
didn't
work
out,
but
we
are
now
at
a
point
where
we
have
a
great
tool
for
building
and
deploying
services
to
our
actual
clusters.
So,
even
though
it
has
been
more
effort
than
I
expected,
our
builds
are
faster.
B
Our
tests
are
faster
and
we
actually
do
have
our
first
pilot
service,
where
the
code
and
config
all
live
in
one
place
and
basil
has
also
made
it
easier
now,
even
though
we
are
primarily
a
node
j,
s+,
Kotlin
shop
to
integrate,
go
or
python
or
whatever
into
our
build
process
where
it's
appropriate,
we
can
just
drop
it
in
without
having
to
make
major
chain.
So
all
in
all,
I
think
this
is
a
great
tool
that
fits
well
into
what
a
lot
of
us
are
doing.
B
But,
honestly,
just
like
cube
it's
something
that
you
really
need
to
understand
and
operate
for
a
bit
before
it
becomes
really
useful,
but
having
operate
of
sorry
skip
the
slide
there,
but
yeah
having
operated
it
now
it
it
has
it's
something.
I
would
do
again.
Also
I
mentioned
helm
earlier.
We
didn't
actually
end
up
using
home,
but
if
you
want
to
use
home
look
basil,
you
can
find
this
code
in
my
slide
deck
and
copy
it.
Hopefully
it
works.
C
B
Our
approach
for
secrets-
that's
that's
a
great
question,
so
we
originally
were
keeping
secrets
in
our
terraform
repo
with
get
Crypt,
and
that
was
not
the
greatest
way
to
do
things.
Instead,
what
we
ended
up
doing
is
as
part
of
the
process
where
our
yeah
mole
for
cube
is
generated
during
a
Basel
run.
We
also
run
a
tool
that
goes
to
in
our
case,
AWS
parameter
store,
but
you
could
go
to
vault.
You
could
go
to
whatever,
wherever
your
secrets
are
and
injects,
those
into
cube
secrets.
I.
A
D
Do
you
do
any
like
complicated,
more
complicated
deployment
like
cannery
deployments,
or
something
like
that
and
to
integrate
into
basil
in
some
way?
Sorry,
do
we
have
more
complicated
components
during
what
that
deployments
like
cannery
deployments,
and
things
like
that?
Do
you
do
that
and
if
you
do,
do
you
integrate
into
basil.
B
E
Think
starter
talk
and
do
you
have
a
way
to
do
you
figure
out
how
to
deploy
to
multiple
clusters?
I
mean
if
you
have
multiple
production
clusters
in
different
regions,
how
do
you
do
deployments?
What
do
you
do
if
one
deployment
phase
do
you
roll
back?
Everything
does
puzzle
help
you
with
that
or
no
sir.
B
E
B
Sorry
I
misheard
you
earlier,
so
how
did?
How
would
you
deploy
to
multiple
cube
clusters
using
this
model?
And
what
do
you
do?
One
deployment
fails
or,
or
something
else
like
that,
so
the
way
this
is
set
up
and
again
like
basil,
is
a
Rolls
engine
right.
So
it's
building
things
that
it's
executing
what
we
tell
it
to
the
way
we
have
it
set
up
when
we
run
a
single
command,
it
deploys
everything
to
one
cluster
and
then
we
actually
have
a
gated
before
going
to
the
next
environment
in
the
next.
B
If
you're
doing
like
multiple
clusters
per
se,
I
don't
know
cross
region
or
something
that's
something
that
if
you
used
our
model
where
it's
you
know,
one
command
deploys
the
one
cluster.
Then
you
could
orchestrate
that
or
synchronize
that,
however
you
want,
you
could
run
all
of
them.
You
can
run
one
weight
around
the
next
so
forth.
B
So
do
we
have
CIN
C
in
the
same
way
for
our
infra?
Yes
for
four
parts
of
it,
so
for
the
parts
that
are
in
queue,
then
yeah
this
all
gets
pulled
in
in
the
same
way,
because
we
have
in
this
same
repo
or
say
like
all
of
our
engine
X
and
grass,
our
CI
CD
server,
some
other,
like
all
the
other
fun
bits
and
pieces,
and
then
those
get
deployed
to
our
dev
environment
on
a
build
and
then
they
can
be
deployed
to
the
next
environment
in
the
next
environment.
G
B
B
One
thing
is
that
basil
keeps
a
warm
cache
of
everything
that's
built,
so
we're
using
build
Chi
for
CI.
That
means
we
run
the
CIA
agents
ourselves
do
the
same
with
I,
don't
know
Jenkins
or
whatever
right
but
running
the
CIA
agents
ourselves.
We
have
these
long-running
basil
processes
and
whenever
there's
a
change
that
they
need
to
build,
they
really
only
need
to
build
whatever
has
changed
since
the
last
commit
in
theory.
B
In
practice,
we've
had
to
do
more
to
actually
walk
the
entire
dependency
graph,
which
you
can
do
because
you've
built
a
dependency
graph
and
figure
out
hey
this
commit
affected
these
files
that
could
possibly
affect
these
targets,
which
could
possibly
affect
these
tests
and
then
just
build
those
change
things
and
then
test.
Only
the
tests
that
are
affected.
A
Yeah
before
before,
I
posted,
like
I,
had
another
question,
so
you
mentioned
the
learning
curve.
So
how
long
did
it
take
you
to
get
comfortable
with
basil,
and
just
just
just
so
that
you
show
the
rest
of
the
team
or
anybody
in
your
team?
How
long
did
it
take
them
to
learn
the
basics
and
then
later,
how
long
they
is
this
whole
project
just
to
give
a
timeline,
I
mean.
B
Yeah
sure
so
like
how
long
does
it
take
to
get
comfortable
with
basil?
What's
the
what's
the
timeline
for
something
like
this,
so
I
think
there's
actually
like
two
different
levels:
right,
there's
one
is
like,
can
use
the
tooling
and
then
there's
can
you
build
stuff
around
this
tooling,
and
you
can
see
the
same
thing
with
like
cube
right
like?
Can
you
build
stuff
using
Q
versus?
B
Can
you
use
keep
CTL
I,
think,
just
being
able
to
say,
do
basil
run
basil,
build
that
kind
of
stuff,
maybe
a
few
days
for
people
to
get
familiar
with,
like
you
know,
here's
here's
kind
of
paradigm
to
actually
be
able
to
write
rules
effectively
and
understand
all
of
what's
necessary
to
write
something
correct
that
took
at
least
a
couple
months
of
ramp
up.
This
whole
project
has
been
going
on
for
about
six
months
now
and
it's
ongoing.
H
B
Help
so
why
home?
So
that
is
a
funny
question,
because
in
the
end
we
didn't
actually
end
up
using
home
at
the
time
that
I
was
submitting
this
proposal.
We
were
so
I
evaluated
a
bunch
of
things
at
this
time
right,
a
lot
of
them.
You
saw
here
helm.
One
of
the
big
draws
part
I,
think
is
that
there's
a
huge
community
at
it
right,
there's
so
many
charts.
There's
this
you
can
you
install
things?
People
have
shown
you
how
to
package
stuff
for
cube
at
the
end.
B
H
B
Well,
I
I,
don't
know
you
know
we
used
it
experimentally
and
it
seemed
like
it
could
give
us
a
lot
of
speed-up
and
products
have
a
benefit
right
like
just
like.
We
can
just
install
things,
but
in
practice
no
I.
Don't
think
that
really
worked
because
nothing's
as
simple
as
just
helm,
install
and
everything's
gonna
be
great
in
production,
yeah
or
maybe
it
is
I,
don't
know,
maybe
because
there's
a
barrage.
A
few
more
minutes,
question.
B
I
B
So,
on
average,
how
fast
is
our
build
and
then
how
fast
is
like
build
to
see
a
container
running
in
the
environment
so
a
build,
so
we
have
Monterey
Bay
right
if
you
so
it
the
build
times
scales
with
how
much
you've
changed.
If
you
change
say
some
files
in
a
node.js
service,
we
can
complete
CI
in
around
90
seconds.
Now,
if
you
do
a
couple
services
or
something
like
a
complicated
back-end,
might
take
up
to
three
minutes
once
C
is
complete,
what
we
trigger
the
actual
release
to
release
to
our
environment.