►
From YouTube: Jenkins X Project Showcase - James Strachan, Laura Tacho
Description
Jenkins X Project Showcase - James Strachan, Laura Tacho
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
Cool:
hey
everybody,
I'm
Laura,
taco,
I
work
at
cloudBees
I'm
here
with
James
and
James
they're
gonna,
be
helping
me
tell
you
all
about
Jenkins
X.
You
have
to
make
this
I
didn't
make
the
rules.
You
have
to
make
this
gesture
when
you
say
Jenkins,
X,
I,
don't
know
what
happens
if
you
don't
James
gets
very
upset.
So
Jenkins
X
is
an
automated
C
ICD
tool
for
kubernetes,
but
it's
a
little
bit
more
than
that.
Jenkins
X
came
out
of
a
need
in
the
development
community
for
a
C
ICD
tool.
A
That
was
maybe
a
bit
faster,
moving
and
very
innovative.
We
kind
of
thought
about
all
the
great
problems
that
Jenkins
solves
and
we
thought
what
would
we
do
if
we
had
kubernetes
and
a
cloud
native
ecosystem
you
know
ten
years
ago.
How
would
we
solve
those
problems
a
little
bit
differently
and
these
problems
that
we
attempt
to
solve
with
Jenkins
X
are
representative
of
problems
that
you're
all
solving
in
your
daily
life
as
developers.
So
we
see
in
the
last
five
years
a
move
from
on-premise
to
the
cloud.
A
A
How
does
Jenkins
hel
X
help
you
as
a
developer
and
help
your
team
solve
these
problems?
One
short
answer
is
that
it
helps
you
automate
those
very
key
parts
of
the
process,
so
whether
it's
installation
configuration
upgrading
your
application
on
kubernetes,
Jenkins
X
can
help
you
do
that
and
it
sort
of
bootstraps
your
entire
development
experience,
including
creating
environments
for
you
as
a
developer,
to
work
on,
but
then
also
things
like
CI
NCD
and
the
environments
in
staging
and
production
themselves.
A
It
helps
you
with
things
like
docker
images,
helm,
charts,
getting
pipelines,
boots
strapped,
and
it
does
all
of
this
while
giving
you
sort
of
the
guardrails
of
aggot
ops
environment,
to
help
you
do
all
of
these
things
in
a
very
traceable
and
an
auditable
way
to
help
you
stay
organized
and
make
sure
you
have
a
really
good,
clear
picture
of
exactly
what's
running
where
and
everything
that
happened.
One
of
the
benefits
of
get
ops
is
that
you
get
lots
of
feedback.
A
This
all
sounds
great,
so
I'm
sure
you're
all
very
itchy
to
get
started
with
Jenkins
X
if
you're
not
using
it
already,
you
can
get
started
with
Jenkins
X
and
James
and
James
are
gonna,
give
some
wonderful
demos
in
just
a
bit.
But
if
you're
curious
sort
of
what's
the
very
first
thing
that
you
can
do
to
get
started
with
Jenkins
X,
that's
installing
the
command-line
tool,
there's
a
couple
different
ways
to
install
it.
A
If
you're
on
Mac
or
if
you're,
using
Linux
kind
of
your
standard
installation
patterns,
either
using
homebrew
or
our
good
friend
curl,
you
can
download
the
command-line
tool,
there's
some
documentation
up
on
Jenkins
Axio,
there's
a
getting
started
guide
with
some
installation
instructions
there.
If
you
want
to
check
out
the
documentation.
A
So
I
can
do
things
like
j'x,
create
cluster
gke
or
AWS
or
aks,
whatever
cluster
management
system
or
kubernetes
service
you're
using
to
have
a
cluster
created
for
you
directly
from
Jenkins
X,
and
it
kind
of
automates
that
workflow
for
you,
so
that
you're
not
sort
of
fiddling
with
all
those
little
knobs
and
and
levers
that
kubernetes
has.
If
you
have
a
cluster
already,
you
can
also
use
the
command
J
X
install
to
get
Jenkins
X
running
and
working
with
a
cluster
that
you
have
already
and
again.
A
A
Why
do
you
do
one
of
these
commands?
Let's
say
you've
run
create
cluster.
Your
very
first
experience
as
a
developer
is
going
to
have
this
entire
development
tools,
environment,
managed
by
Jenkins
X
through
the
Jenkins
X
CLI.
So
again
the
CLI
is
talking
out
to
whatever
public
cloud
account.
You've
instructed
it
to
do
so.
It's
going
to
give
you
a
complete
development
tools,
environment.
So
we
have
one
version.
Actually
the
default
now
running
on
with
Tecton,
so
as
Christy
mentioned,
Jenkins,
X
and
Tecton
are
very
close
and
and
we've
already
integrated.
A
You're
gonna
have
a
staging
environment
and
production
environment,
which
gives
you
everything
that
you
need
to
work
with:
kubernetes
locally,
develop
on
cobranet,
run
tests,
get
fast
feedback
and
then
using
get
ups,
promote
changes
to
your
application
from
your
development
environment
to
staging
and
then
to
production,
which
sounds
pretty
great
I'm,
pretty
excited
about
it.
So
I'm
gonna
invite
James
and
James
up
to
the
stage
to
give
you
some
demos
on
what
this
looks
like
in
practice.
A
B
So
we're
gonna
try
a
live
demo
now
on
Google,
Cloud
and
github,
and
let's
see
how
it
goes
so.
As
Laura
said,
Jenkins
X
supports
two
execution
engines.
We
can
either
use
static,
Jenkins
servers
as
your
CI
engine
or
we
can
use
Tecton.
We
love
Tecton,
we
think
is
awesome.
So
tech
tongs
now
our
default
execution
engine,
because
it's
completely
serverless
and
cloud
native
so
that
we
only
run
build
pods
when
you
need
them
and
then
everything
tears
down
when
you're
not
using
it.
So
we're
gonna
try
a
quick
start
right.
B
So
we've
installed
junkies
X
it's
running
on
gke
right
now
and
we're
gonna
type
J
X
create
Quick
Start.
So
we
have
a
whole
bunch
of
different
ways
of
creating
projects.
You
can
use
JX,
quick,
quick
start
to
create
a
brand
new
project
using
Java
gurnard,
rust,
Python
Ruby,
various
different
programming
languages.
B
If
your
spring
person,
by
the
way
this
JX
create
spring,
which
uses
the
spring
boot
initializer
thingy,
to
create
a
new
application,
so
we're
going
to
create
a
new
get
repository,
we're
gonna,
give
it
a
funky
name
like
cube
con
rocks,
say,
for
example,
okay,
awesome,
good
typing
james
yeah,
okay,
that's
brilliant!
So
we're
gonna
create
a
brand
new
git
repository
name.
So
we
create
a
new
project
which
should
we
do
go
yeah.
B
Let's
do
go
because
girls
cool
so
we're
gonna
do
a
go
lang,
demo
right
now,
so
we've
given
it
an
organization
we've
given
it
a
repository
name.
This
is
the
initial
git
repository
git
commit
and
then
a
couple
of
seconds
later.
If
github.com
is
up
everything's
looking
good.
So
what
we've
basically
done
is
created
a
brand
new
QuickStart.
It's
a
hollow
world
go
micro
service.
It's
create
the
source
code
on
your
file
system
is
create
a
git
repository.
It's
pushed
the
code
up
to
github
comm.
This
is
the
curl.
B
Now
on
get
a
pack
on
there,
you
can
see.
We've
just
created
it
a
few
seconds
ago,
so
we
create
a
brand
new
micro
service.
We
create
the
source
code,
we've
done
a
whole
bunch
of
stuff
behind
the
curtain,
so
we've
created
a
git
repository.
We've
created
web
hooks
so
that
whenever
you
do
a
git
merge
or
a
pull
request
on
that
git
repository,
it
will
trigger
CI
in
CD.
So
we've
automated
all
of
the
cncd
with
one
command,
which
is
pretty
cool,
so
you
don't
have
to
write
any
technology.
Are
these?
B
You
don't
have
to
look
at
yeah
mo.
If
you
don't
want,
we've
done
CNN
CD
for
you.
So
if
we
do
yet
j:x
get
build
logs,
we'll
be
able
to
see
the
pipeline
running
there.
We
go
on
the
master
pipeline
so
because
we've
pushed
to
the
master
repository
what's
triggered.
Now
is
the
release
pipeline,
so
the
release
pipeline
is
going
to
clone
the
curd.
It's
going
to
tag
and
get
it's
going
to
create
a
new
get
version,
so
it
starts
at
0,
0
1,
then
0,
0,
2
and
so
on
and
so
forth.
B
It's
gonna
tag.
It
is
then
gonna
build
the
executable.
In
this
case.
It's
a
go
behind
array.
We're
going
to
push
that
to
github
we're
then
gonna,
though
we've
tagged,
github
or
gates
already,
and
we're
then
going
to
make
a
docker
image
we're
going
to
tag
the
docker
image
with
0
0
1
we're
gonna
push
that
to
GC
our
Google
container
registry.
We're
then
gonna
make
a
helmet
and
tag
that
0
0
1
we're
gonna,
push
the
help
shots
of
chap
museum
and
to
store
the
immutable
helmet
chart.
B
So
we
can
install
this
application
on
any
kubernetes
cluster
at
any
point
in
time,
then
we're
gonna
do
we've
already
done
it.
We've
created
a
pull
request.
You
see
at
the
bottom.
So
now
we've
done
the
release.
We've
tagged,
0
0
1,
we've
pushed
the
docker
image,
we've
generated
the
helm,
sure
now
we're
going
to
promote
0,
0
1
to
our
staging
environment.
We
use
something
called
git
ops
to
do
promotion
and
what
that
basically
means
is
using
a
git
repository
to
store
each
environments.
Configuration
so
staging
is
a
git
repository.
B
Production
is
a
git
repository,
so
we
have
in
there
git
repository
all
the
versions
of
all
the
apps
that
are
in
staging
and
all
the
versions
of
all
the
apps
are
in
production.
So
to
do
a
promote
we're
basically
just
to
a
pull
request
to
do
a
git
commit
which
changes
the
versions
of
the
application
that's
winning
is
staging.
So
we've
done
to
put
as
a
portal
Quest
merge
yet
yeah
the
progress
merged.
So
now,
because
we've
merged
to
master
of
the
staging
environment,
a
pipeline
is
going
to
be
triggered.
B
The
Tecton
pipeline
is
going
to
trigger
on
them
master
branch
of
the
staging
environment,
which
is
then
going
to
do.
Q
CTL
apply
of
that
helm.
Chart
right.
So
in
one
command
we
tap
one
command
and
we've
got
a
go
micro
service.
Is
it
running
yet
I?
Guess
it
just
about
this?
It's
promoting
right
now,
so
we
type
one
command.
B
We've
got
the
girl
micro
service,
we've
got
all
the
source
code
created,
we've
got
CIN
CD
created,
we've
got
Tecton
pipelines
to
do
releasing
pour
requests
and
promotion,
and
it
should
be
running
any
minute
now,
which
is
pretty
cool,
so
one
command
one
command
and
we're
good
to
go.
Now
you
could
use
any
programming
language,
you
like
you,
can
use
maven,
you
can
use
Gradle,
you
can
use
Python
php.net,
whatever
we've
got
bill
packs
for
most
programming
languages.
B
If
you've
got
a
funky
programming
language
that
we
haven't
covered
yet
come
and
let
us
know,
join
the
community
we'll
make
a
bill
pack
for
you.
We've
got
pluggable
bill,
packs
that
you
can
extend
to
use
any
different
tool
or
programming
language
or
build
tool
or
whatever
you
like,
and
there
you
go
hello
world.
So
we've
created
a
brand
new
micro
service
ingo
and
it's
in
staging
already
now
wait
what
wait!
James,
okay
I
should
say
by
the
way.
Just
before
this
talk,
I
managed
to
trash
my
cluster.
B
So
thank
you
James
for
having
the
cluster
that
works.
Don't
trust
your
cluster
before
a
demo
is
a
lesson
that
should
we
do
a
pull
request?
Should
we
do
so,
let's
walk
through,
so
we
did
the
release
of
the
new
project.
Let's
show
you
how
to
do
a
pull
request.
Now.
An
important
thing
to
remember
by
the
way
is
once
you've
imported
a
project
to
create
the
project
developers
just
use,
get
and
the
your
editor
of
choice.
B
It
could
be
very
max,
it
could
be
IntelliJ
IDE
or
it
could
be
even
Eclipse
use
whatever
tools
you
like,
but
developers
then
just
sit
in
their
source
code
and
use
git
developers
don't
need
to
know
or
care
about
Jenkins,
x
and
Tecton,
and
all
this
wonderful
CIC
these
stuff,
it
just
kind
of
happens
for
you
automatically
behind
the
curtain.
So
what
we're
gonna
do
now
is
we're
gonna,
do
a
pull
request.
Let's
do
a
code
change.
B
Look
at
this
amazing
girl
code.
It's
awesome
so
we're
going
to
change
that
message
to
something
really
cool
like
yeah.
That's
really
cool!
So
we're
gonna
change
the
source
code
to
the
to
the
girl
service,
hello,
buster.
We
love
it
yeah.
We
love
puzzle
and
it's
awesome.
So
we've
we've
changed
the
source
code,
so
we're
now
gonna.
Do
it
do
a
branch?
First,
are
you
on
a
bridge?
Okay,
sorry,
I,
missed.
Okay,
so
we're
gonna.
Do
a
git
commit.
If
you
were
head
to
me
so
we're
gonna.
B
B
Then
they
gonna
2jx
create
PR,
yeah
good
god,
so
you
can
create
a
Porticus.
However,
you
like
you,
can
use
your
IDE.
You
could
use
the
github
com
website,
whatever
PR
grip
here,
just
peer
yeah
that
you
we
have
a
command-line
tool
that
does
it
for
you,
if
you
like,
where
you
just
hit
return
and
then
down.
Okay,
okay,
forget
that
command!
Let's
do
let's
do.
If
I
had
a
week,
you
can
use
hub
as
well.
If
you
like,
hope,
I'm
sorry
about
that.
That's
my
fault.
Okay,
then
we've
got
a
pull
request.
B
If
you
couldn't
okay,
so
we've
just
created
a
normal
pull
request.
You
could
do
this,
however,
you
like
using
any
tool
of
your
choice,
preferably
one
that
works
and
then
now,
because
we
create
the
pull
request.
The
automated
CIN
City
is
kicking
in
again.
So
whenever
you
push
to
master
the
master
branch,
we
do
a
release
and
we
tag
everything
and
release
it
and
promote
it.
When
you
create
a
pull
request,
we
have
a
different
pipeline
for
pull
requests
which
is
similar.
It's
just
not
quite
the
same.
B
So
we
want
to
make
it
easy
for
our
team
members
to
review
code
changes
before
we
agree
to
merge
them.
So
the
more
reviews
and
testing
we
can
do
before
we
merge
the
code
to
production,
though
the
better
we
are
right.
So
a
preview
environment
is
a
way
of
previewing.
The
code
change
before
you
agree
to
merge.
For
example,
it's
surprisingly
easy
in
humanities
to
make
an
innocent-looking
change
to
an
environment
variable
and
all
of
a
sudden,
you
break
your
app
right.
B
So
the
preview
environment
gives
us
a
way
of
testing
that
the
code
still
runs
in
the
Kuban
ities
cluster
that
the
container
bills,
the
container
starts,
the
liveness
checks,
ro,
the
readiness
probe
hasn't
buffed
and
everything
starts
up.
Okay,
so
we've
done
the
pull
request.
That
pipeline
is
running-
hopefully
now,
oh
yeah,
sure
eachother
Tecton
recesses.
While
we
wait
for
this
pull
request
to
build,
let's
do
cube.
Ctl
get
pipeline
run.
B
So
here
you
can
see.
All
the
different
pipeline
so
pipeline
runs
were
cute
Tecton
resource
Tecton
makes
a
pipeline.
The
pipeline
run
the
task,
a
task
run
and
a
pipeline
resource
I
think
and
each
one
of
these
is
automatically
created
via
the
Jenkins
x-pipe
line,
so
Jenkins
X
Y
amel,
is
a
DSL
as
Chrissy
said,
and
we
take
that
dsl
and
we
generate
the
Tecton
CR
these
under
the
covers.
So
the
CI
in
see
the
engine
behind
the
curtain
in
Jagger's
X
is
all
completely
vanilla.
B
B
B
Whoa,
okay,
so
that
was
the
demo.
It
was
awesome,
so
just
do
what
walk
through
what
should
have
happened
in
the
curtain,
so
jiggies
ex
has
a
support
for.
Did
it
work?
Okay,
there
you
go
so
you
see
that
URL
day,
if
we
open
that
URL,
so
you
can
see
the
pipeline
that
went
green.
It's
built
the
code.
It's
got
this
new
hello
message
which
is
awesome.
So
this
is
code,
that's
running
in
Cuban
eighties,
in
the
preview
environment.
So,
what's
basically
happened
behind
the
curtain.
Is
the
pipeline
has
run
on
the
pull
request?
B
It's
created
a
new
docker
image,
a
preview
docker
image.
It's
built
the
code
deployed
it
to
a
preview
environment.
A
preview
environment
is
just
the
temporary
kubernetes
namespace.
So
each
pull
request
gets
its
own
unique
namespace,
we
spin
a
per
cube.
Init
is
no
space.
We
deploy
the
code
in
flat,
no
space.
Then
we
expose
the
URL
of
the
app
running
in
there
and
then
we
comment
on
the
pull
request,
the
URL
to
where
the
apps
running
so
all
of
your
teammates.
B
As
soon
as
you
do
a
pull
request,
all
your
teammates
can
soon
as
they
see
that
URL
up
here,
they
could
just
click
on
the
code
and
view
the
running
code
before
you've
merged
a
master
right
now,
if
you're,
building
a
web
UI,
for
example-
and
someone
changes
some
CSS
if
you're
doing
a
code
review
of
diffs
on
CSS
I,
don't
know
about
you,
but
it's
kind
of
hard
to
know
what
that's
gonna
mean
right.
You
look
at
the
def.
Anything
you've
changed
the
font
awesome.
But
what
does
it
look
like
with
preview
environments?
B
You
can
click
on
the
URL
and
you
can
see
the
effect
of
the
coach
in
running
one
thing
we
found
initially
when
we
first
made
Jenkins
X,
we
kind
of
thought
we'd
do
things
the
traditional
way,
we'd
merge
the
master
we'd,
do
a
release,
we'd
move
it
to
the
testing
environment,
we'd,
look
at
it
and
then
we
go
to
staging
in
production.
What
we've
kind
of
found
is,
if
you
have
a
single
staging
environment,
that's
kind
of
a
single
environment.
B
So
if
you
have
many
people
making
many
pull
requests,
you
have
a
single
place
to
test
by
using
preview
environments
you
can
test.
In
parallel.
Each
pull
request
has
a
separate
testing
environment.
So
the
more
you
use
preview
environments,
the
more
you
can
do,
testing
on
each
preview.
So
a
preview
is
just
a
helper
to
deploy
the
thing
you're,
building
plus
arbitrary
of
the
dependencies,
so
your
preview
chart
could
be
MongoDB
or
Postgres
you
could
you
could
deploy
Kafka,
you
could
deploy
arbitrate
backing
services
and
then
your
preview
chart
can
also
run
system
tests.
B
So
every
time
this
pv
environment
is
created,
you
could
run
arbitrary
jobs
right.
You
could
run
selenium
tests.
You
could
run
Cypress
testing.
You
could
do
BDD
tests,
any
testing
you
like
so
the
more
we
use
preview
environments
and
the
more
we
move
testing
back
into
the
preview
we
can
test
in
parallel
and
dynamically,
spend
up
test
environments
for
each
pull
request,
which
is
pretty
awesome.
So
there
we
go.
We've
created
a
new
application
in
one
command.
B
We
create
one
pull
request:
we
got
a
preview
environment
and
then,
if
we
agree
to
merge
that
change,
it
will
then
most
a
master
and
then
0:02
will
be
created
and
that
will
go
to
staging
a
quick
point
on
the
environments.
By
the
way
you
can
have
as
many
environments
in
the
team
as
you
like.
We
default
out
of
the
box
in
Jamie's
ex
to
have
a
staging
environment
and
the
production
environment,
so
each
team
can
just
go
to
staging
whenever
they
like
and
in
production
whenever
they
like.
B
We've
made
the
defaults
so
that
we
automatically
promote
to
staging
and
you
manually
choose
when
to
go
from
staging
to
production.
What
we'd,
like
you
to
do,
is
over
time
automate
all
that,
so
you
automatically
go
to
production,
but
we've
left
it
as
a
kind
of
a
safe
default.
So
you
automatically
go
to
staging
every
merge
to
master
once
it's
merged,
it's
released
and
goes
to
staging
automatically.
B
You
can
change
this
if
you
wish
and
go
manual,
it's
up
to
you,
so
we
always
go
to
staging,
and
then
you
manually
choose
when
to
promote
to
production.
If
you
want
20
environments,
just
create
new
environments
and
environment
is
a
custom
resource.
Actually
you
want
to
do
cube.
Ctl
get
env
on
the
command
line,
cube
CTL
get
get
E&B,
so
Jackie's
ex
uses
custom
resources
just
like
Tecton.
Everything
is
a
CRD.
Basically,
so
environments
were
CID,
get
providers
overseer
these
secrets
or
CID,
so
each
of
our
environments
is
defined
as
a
custom
resource.
B
So
any
point
in
time
you
can
create
more
environments
and
environment
has
a
git
repository,
there's
the
git
repository
for
each
environment
and
so
on
and
so
forth.
You
can
use
github
to
manage
the
development
environment
as
well.
So
when
you're
installing
Jenkins
X,
you
can
choose
to
enable
the
get
absorption,
which
means
it
creates
a
git
repository
for
the
development
environment
so
that
all
of
the
installation
of
Jenkins
X,
so
the
version
of
Tecton
you're
using
the
version
of
Jenkins
X
using
the
nexxus,
the
whatever
it
is,
is
all
managed
in
git.
B
So
then,
when
you
do
upgrades
you're
doing
pull
requests
on
the
development
environment,
which
then
does
rolling
upgrades
of
Jenkins
X
itself,
so
we
can
get
ops,
Jenkins
X
itself,
which
is
awesome.
So
there
we
go
I,
think
that's
all
the
demos,
so
we
one
command
will
create
the
new
microscope.
It's
a
1:1
git,
pull
request
that
we've
got
the
preview
environment
and
they
were
most
omastar
and
we
get
a
release.
Any
questions
about
Jenkins
X
at
all,
yeah.
B
Correct
question:
let
me
try
to
repeat
what
you
just
said:
if
you
have
a
back
end
and
the
front
end,
how
do
I
use
preview
environments
and
so
far
it's
a
great
question.
We've
found
this
quite
a
lot.
We
do
the
same
thing
ourselves
internally.
We
use
Jenkins
X
to
make
Jenkins
X,
so
we're
always
iterating
on
Jackie's
X
to
make
it
better
really
and
make
it
work.
So
a
very
common
thing
is
you're.
Writing
a
micro
service
like
a
front
end
and
you
need
a
back
end
to
test
your
front
end.
B
So
how
do
you
get
the
front
end
and
the
back
end
to
work
together?
So
a
preview
environment
is
defined
in
your
source
tree.
You
want
to
just
open
the
gate
proposal.
Yeah
you're
ahead
of
me
all
right,
mind
reader.
So
this
is
the
git
repository
for
the
app
we
just
created
and
the
preview
folder
contains
all
of
the
helm
charts
which
defines
your
preview
environment.
B
So
you
can
add
into
your
preview
environment
any
dependencies
you
like
right,
you
could
add
you
could,
on
the
back
end
in
this
front
end
and
then
whatever
now
one
interesting
thing.
We
found
so
initially
we
just
thought
you'd
deploy
all
of
the
services
you
need
in
your
preview
environment,
which
is
great
as
soon
as
you
have
multiple
teams,
working
together
on
micro
services
having
to
deploy
other
teams.
Micro
services
sometimes
gets
a
bit
tricky,
because
different
services
need
different
configurations,
all
that
kind
of
stuff.
B
So
another
thing
you
can
do
is
rather
than
deploying
all
the
services
in
each
preview
environment.
You
can
serve
this
link
to
the
things
you
need
so,
rather
than
actually
deploying
20
different
micro
services
to
test
the
front
end,
you
can
service
link
to
the
those
micro
services
running
in
your
staging
environment
so,
rather
than
actually
adding
20
different
health
shots.
B
Here,
you
could
do
service
linking
to
link
to
those
services
running
in
your
staging
environment,
so
we
find
ourselves
doing
service
linking
a
little
bit
more
so
that
you
can
link
to
your
staging
environment
for
your
back
end,
but
you
deploy
the
new
version,
the
front
end
or
vice-versa.
So
basically,
you
can
define
whatever
you
want
in
this
home
jar
in
the
home
chart
you
can
define
the
requirements,
so
you
can
add
new
charts
and
you
can
also
edit
the
values
Yambol
to
configure
those
charts
with
preview
specific
values.
B
Yes,
that's
a
great
question,
so
the
question
is:
do
we
support
all
the
gate
providers?
So
we
have
to
execution
engines
Tecton
and
Jenkins
when
you're
using
Jenkins,
we
support
gait,
lab
github,
github
Enterprise,
bitbucket
cloud
bitbucket
server
and
get
iya
when
you're
using
Tecton.
We
support
github,
but
we
are
working
on
supporting
more
gate
providers.
The
the
limitation
is
nothing
to
do
with
Tecton,
and
so
the
object
is
X.
The
limitation
is
when
we're
using
technology
execution
engine.
B
We
use
a
project
called
prowl,
Pierrot
W,
which
is
a
web
hook
handler
it's
more
than
that,
but
it's
a
web
hook,
Handler
thingy
that
supports
get
ops,
that's
a
top
story.
So
it's
a
way
of
having
a
conversation
on
pour
requests,
so
you
can
type
slash
tests
to
rerun
a
test
and
so
forth
and
slash
approve
to
approve
a
pull
request.
So
we
look
and
you
can
get
cats,
you
can
get
cats,
which
is
the
most
important
thing.
So
we
love
prowl
prairies
awesome,
the
one
limitation
these
prowl
is
currently
github.
B
Only
we
have
a
Cosman
did
the
pull
request.
Two
days
ago,
where's
Cosman,
coming
to
the
podcast
two
days
ago,
to
start
to
refactor
prowl
to
use
a
pluggable
interface
for
working
with
git
providers,
so
prowl
will
have.
Is
it
most
yet?
No
I
guess
not
nearly
so
soon
we'll
have
a
pull
request
in
prowl,
which
lets
us
have
pluggable
gate
providers
so
currently
prowess
getup
only
but
hopefully
soon
we'll
support
many
good
photos.
Any
other
questions
see
another
cat
do.
Do
you
want
to
do
another
meow?
B
B
B
B
So
the
at
the
center,
so
Jackie's
ex
uses
something
called
a
bill
pack,
so
we
have
bill
packs
for
lots
of
different
programming
languages
and
based
on
the
what
we
basically
do
when
you
import
a
new
project
or
create
a
new
project.
We
look
at
the
source
code
and
we
detect
the
programming
language
of
based
on
the
programming
language.
We
pick
the
build
pack,
you
can
manually
specify
a
bill
pack
if
you
wish,
but
by
default
we
we
have
a
bill
pack
for
most
programming
languages,
so
go
Russ,
Python,
PHP,
Russ
newbie
there
yeah.
B
So
if
a
whole
raft
of
different
bill
packs,
this
is
just
a
git
repository.
So
if
you
want
to
build
your
own
bill
packs,
you
can
just
fold
this
repository
create
your
own
repository
whatever.
But
what
we
trying
to
do
is
we're
trying
to
basically
automate
cncd
for
developers
so
you're
free
to
write
your
own
pipelines
if
you
want,
but
we
would
rather
automate
them
for
you.
So
we
trying
to
build
a
library
of
bill
packs
for
all
programming
languages.
B
One
thing
I
didn't
mention
by
the
way:
is
we
refactored
our
bill
packs
so
that
we
have
a
classic
bill
pack
which
just
as
releases
of
node
or
go
or
Java
or
maven
or
whatever?
Then
we
have
the
Cuban?
It
is
bill
pack
that
knows
about
how
on
and
get
ops
and
that
and
docker
images.
You
could
write
your
own
bill
pack
for
different
platforms
than
kubernetes.
B
So
you
could
extend
Jake
his
ex
in
different
programming
languages
or
in
different
deployment
strategies
or
to
use
different
tools
right,
we're
hoping
to
get
some
spinnaker
integration
at
some
point,
so
we
could
have
a
Bill
pack
for
spinnaker
if
you
wanna
use
spinnaker
as
your
deployment
engine.
So
we're
hoping
to
do
that
at
some
point,
any
other
questions
and
then
it's
it's
lunch
soon.
B
Great
question
multiple
clusters,
so
this
is
probably
the
first
question.
I
normally
get
asked,
especially
when
we're
talking
with
customers
is.
Do
you
spot
multiple
clusters,
so
by
default,
when
you
just
do
JX
create
cluster
gke
or
aks
or
eks
or
whatever
it
creates
three
namespaces
one
for
development,
one
for
staging
or
production,
most
people
when
you're
doing
a
real
installation.
You
want
production
to
be
on
the
different
cluster
and
staging
to
be
a
different
cluster
and
development
through
a
different
cluster.
So
normally
in
a
real
world
scenario,
you'd
want
to
separate
those
clusters.
B
You
probably
also
want
to
separate
the
service
account,
so
a
different
you
know,
Cloward
account
would
run
production
and
different
cloud
account
will
do
in
staging
and
you
probably
want
Chinese
walls,
so
they
can't
see
each
other
or
talk
to
each
other
or
share
any
data
and
all
that
kind
of
stuff.
We
have
some.
We
have
multi
cluster
support
in
Jenkins
X,
using
something
called
an
environment
controller.
And
what
basically
happens
is
you
install
your
development?
B
Cluster
is
normal,
and
then
you
find
your
production
cluster
and
you
run
JX,
create
add-on
environment
controller
and
that
installs,
this
tiny
little
controller,
which
is
basically
Tecton
and
one
of
the
micro-service
and
that
basically
deploys
to
staging
or
production.
So
instead,
your
production,
those
are
typically
lockdown
clusters,
we
very
strict
our
back
and
security
and
yeah
yeah,
the
other.
B
The
only
thing
you
need
to
run
in
those
clusters
is
this:
these
two
little
controllers,
the
of
the
environment
controller,
which
is
two
little
micro
services,
and
that's
basically,
the
thing
that
gets
the
webhook
from
github
get
over.
Whatever
your
get
father
is
and
does
the
cube
CTL
apply.
Basically
they
go
so
it's
a
small
little
micro
service,
so
your
production
environment
is
then
just
this
tiny
little
micro
service
and
then
that's
it
so
production
the
staging
can
be
on
any
cluster
in
any
account.
B
It's
completely
separate
and
the
only
thing
you
really
need
for
the
environment
controller
is
you've,
got
a
git
repository
and
in
docker
image
registry,
and
you
can
see
where
your
helmet
charts
live.
So,
apart
from
that,
it's
completely
isolated
any
other
questions,
Hey
hi
great
Hey.
Do
you
have
a
question.
B
B
B
Yes,
it's
great
question,
so
the
general
gist
I
think
is:
do
you
only
run
pipelines
if
contributors
would
create
a
pull
request
and
you
don't
automatically
run
pipelines?
So
when
we're
using
Tecton
as
the
CI
engine
we
use
prowl,
which
automates
the
triggering
of
pipelines
on
poor
request
prior
uses,
something
called
an
owner's
file,
so
only
people
who
create
pull
requests
who
are
in
the
owners
file
gets
automatic
CI
created.
B
So
if
some
random
person
comes
along
and
creates
a
poor
request
on
your
project
that
says,
email
me,
your
secrets
from
the
cluster
or
something
kind
of
dodgy
or
Bitcoin
mining
and
in
the
pipeline
the
pipeline
doesn't
run
by
default.
A
an
approver
has
to
do
slash,
approve
or
slash
okay
to
test,
so
an
approver
has
to
say,
okay,
the
test.
Then,
if
an
approver
says
okay
to
test,
then
prowl
then
triggers
the
pipeline
and
then
once
that
pipeline
has
been
triggered.
B
If
ever
you
want
to
rerun
the
pipeline,
you
do
slash
test
and
you
can
rerun
the
test
whenever
you
like.
You
can
actually
define
many
pipelines,
so
we
have
a
whole
bunch
of
BDD
tests
whenever
we
do
a
new
release
of
Jenkins
X.
We
test
on
all
sorts
of
different
kubernetes
clusters.
Each
BDD
test
is
a
separate
pipeline
in
Jenkins
X
and
we
can
test
all
of
them
independently
or
all
together
by
typing,
slash
test,
all
slash
test,
cheese,
slash
test
whatever,
so
we
love
prior
prowess
doing
this
magic
for
us.
B
B
Kans
spinnaker
and
jagged:
yes,
the
quickly
the
coke
and
Jackie's
excellence
pinnacle
were
together.
The
quick
answer
is
yes,
so
Jackie's
ex
is
really
trying
to
reuse
the
Best
of
Breed
open
source
tools.
We
can
find
to
give
you
a
great
developer
experience.
So
we
under
the
covers,
were
using
Tecton
we're
using
helm.
We're
using
can
occur,
we're
using
scaffold,
we'll
use
anything.
B
We
can
find
that
helps
people
be
predictive,
we've
not
done
it
yet,
but
we
would
love
to
see
a
build
pack
for
spinnaker
so
that
we
can
do
CI
and
CD
with
Jenkins
X
orchestrating
spinnaker
or
helm
or
QC
GL
apply
or
whatever
it
is.
So
the
quick
answer
is
we'd
love
to
see
a
spinnaker
integration.
One
of
the
things
I'm
the
most
excited
about
CDF
is
really
seeing
Jenkins
Jenkins,
X,
Tecton
and
spinnaker
in
the
foundation
together.
So
we
can
foster
that
collaboration
in
the
integration,
so
the
plan
is
definitely
to
integrate
the
two.
B
By
Carlos
who's
here,
where's
Carlos,
it
was
hey
Carlos,
who
rather
kubernetes
plug-in
by
the
way
awesome
so
Jenkins
girls,
which
is
great
so,
if
you're,
using
the
Jenkins
server
as
the
execution
engine
in
Jackie's
ex
it's
using
Carlos's
plug-in
to
implement
the
bill
pods.
So
the
question
was:
do
we
support
shared
pipeline
libraries
so
which
is
a
great
question?
So
the
quick
answer
is
if
using
Tecton
there
is
no
Jenkins.
B
So
there
is
no
shared
library,
but
Jackie's
ex
pipelines
supports
something
like
shared
libraries,
we
use
build
packs
which
let
you
have
reusable
yamo
of
pipeline
steps.
So
we
have
something
like
shared
pipeline
libraries
in
Jackie's
ex,
but
if
you
literally
have
a
jenkins
file-
and
you
literally
have
a
jenkins
shared
library-
and
you
wish
to
use
it-
you
can
either
use
the
Jenkins
server
as
the
execution
engine
for
your
team
or
we
support
Jenkins
as
an
app
inside
Jenkins
X.
So
jaggi's
X
has
an
extension
model
where
you
can
install
different
apps.
B
One
of
those
apps
is
called
Jenkins
just
to
be
a
slightly
meta,
so
you
can
install
a
custom
Jenkins
server
inside
Jenkins
X
using
Jenkins
X,
and
then
you
can
have
some
pipelines
running
the
Jenkins
server
and
some
pipelines
run
in
Tecton.
So
you
can
have
kind
of
a
mixed
world
where,
if
you've
already
written
the
Jenkins
file
and
you've
created
that
drink
is
fine,
you
want
to
keep
it.
That's
great
use
a
Jenkins
server
for
that.
B
B
There
was
no
Jenkins
server
in
the
demo
today
there
was
not
a
single
Jenkins
server.
Everything
was
a
hundred
cent
Tecton.
However,
if
you
create
a
cluster,
when
you
create
a
cluster
in
the
install
during
his
X,
you
get
a
choice
of
using
Jenkins
or
Tecton.
The
demo
is
identical.
Actually
with
using
Jenkins
or
tectonic
looks
the
same.
It's
got
the
same,
CLI
the
same
the
same
commands
the
same.
B
It
looks
and
feels
the
same
yeah
we
have
a
UI
coming
fairly
shortly,
that
visualizes
pipelines
build
logs
and
environments
of
promotions,
Lolich
and
stuff,
and
again
that
looks
the
same,
whether
using
Jenkins
servers
or
Tecton
ADA
looks
and
feels
the
same.
Basically
under
the
covers
were
making
custom
resources
for
everything,
so
it
just
looks
the
same
whether
using
Jenkins
or
Tecton.
B
Great
question:
the
question
was
basically:
how
much
resources
do
you
need
for
your
cluster?
It
depends.
It
depends.
The
quick
answer
is,
with
other,
just
enable
lots
of
scaling,
and
that
will
tell
you
is
the
quick
answer,
one
of
the
things
we
haven't
quite
done
yet,
where
there's
quite
a
few
little
micro
services,
if
you
do
cube
CT
I'll
get
pod,
there's
quite
a
lot
of
pods
running
for
controllers
that
are
watching
to
see
how
these
and
doing
various
things
there's
quite
a
few
of
them,
and
we
we
should
ought
to
scale
those
really.
B
Oh
I
haven't
mentioned
it.
Yet
we
support
care
narrative
now.
So,
if
you
install
care
native
into
your
cluster
once
you've
installed,
a
native
all
of
the
pipeline's
look,
the
same
and
everything
works
the
same,
but
rather
making
a
kubernetes
deployment
and
the
humanity
service
free
app.
We
create
a
care
native
service
so
that
your
app
becomes
service
and
scales
up
and
down
automatically.
B
B
B
Great
question
and
the
person
who
did
all
the
work
is
right
over
there
cosmic,
so
we
out
of
the
box,
if
you
just
to
create
Jenkins
X,
we
assume
just
we're
using
cuban
any
secrets
and
that's
it,
but
there
is
a
das
vault
option.
When
you
install
Jenkins
X,
which,
if
you
do
desktop
bolt,
we
install
the
vault
operator,
which
means
all
secrets
of
ends,
maintain
the
stored
in
vaults.
So
you
can
trust
your
cluster
re
credit.
We
did
this
because
we
kept
deleting
your
prediction
cluster.
B
It's
surprisingly
easy
to
do,
delete
prediction
cluster,
so
we've
went
through
trial,
an
error
we
found
we
needed
to
recreate
prediction
really
quickly,
so
we've
we've
moved
all
of
our
secrets
into
vault
now,
so
we
can't
rush
the
prediction
cluster
by
accident
and
then
bring
it
back
really
really
quickly.
Now.
So,
if
use
vault,
basically
all
secrets
and
installed
in
vault,
then
everything
else
is
starting
gates.
So
all
the
non
secret
stuff
is
in
get
and
everything
else
is
involved.
B
Yeah,
here's
another
cool
thing.
One
thing
we
found
two,
so
the
first
thing
was:
we
went
with
a
vault
operator
which
is
great
and
then
the
next
thing
we
found
is
we
wanted
to
make
it
easier
to
inject
into
Hell
charts
secrets
from
vault.
So
we
have
this
nice
little
URL,
thingy
that
if
you
have
your
values
Yamma.
So
this
is
traditional,
vanilla,
hell
stuff,
but
if
your
values,
yeah
Mel,
includes
vault
URLs,
we
automatically
use
the
vault
operator
to
fetch
those
secrets
and
inject
them
into
the
helm
chart.
B
So
it's
a
really
easy
way
of
using
the
vault
operator
but
from
inside
helm,
so
that
you
just
do
vanilla,
helm
stuff.
But
we
inject
your
secrets
from
vault
for
you,
which
is
awesome,
any
other
questions,
and
then
we
can
eat
the
Christmas.
Well,
thank
you
very
much.
Oh
there's
a
talk
on
Thursday
right,
Thursday,
there's
a
taco
Thursday
about
jiggy
sexy
fluency,
a
bigger
demo,
will
probably
even
demo
the
UI
then
as
well,
which
will
be
awesome.
So
thank
you
very
much
enjoy
the
conference.