►
Description
Experienced Python, Node, React, and Java developers can find it difficult to adopt Kubernetes. Successful deployments require a strong DevOps pipeline. This session will highlight personal experiences working with Tekton, Argo CD, and Kubernetes in production environments. We will demonstrate code and patterns that our team developed in these real-world deployments. (https://github.com/ibm-garage-cloud). Examples include using Argo CD to deploy Tekton Pipelines with Kubernetes Configurations. The session will also highlight end to end pipeline examples inclusive of CI/CD/Artifacts/Testing/Ops stack.
Presenters:
Roland Barcia, CTO Solution Engineering @IBM
Sean Sundberg, Lead Architect, Cloud Native Toolkit @IBM
A
All
right
welcome
everyone
thanks
for
joining
us
today.
Today's
CN
CF
webinar
is
titled,
helping
app
developers
adopt
kubernetes
with
Tecton
and
Argo
automation,
I'm,
helping
host
this
webinar
and
Phil
Estes,
one
of
the
CN
CF
ambassadors
and,
interestingly
enough
I
actually
worked
in
IBM's
cloud
platform
group
as
a
distinguished
engineer
and
it's
kind
of
fun
to
lead
off
a
webinar,
hosted
by
a
couple
of
my
colleagues
at
IBM,
so
I'd
like
to
welcome
roland
bar
SIA,
who's,
CTO
of
solution,
engineering
and
shun
Sundberg,
a
lead
architect
cloud
native
toolkit
at
IBM.
A
They
both
work
in
IBM's
garage,
which
they're
going
to
tell
you
more
about
that.
It's
really
connecting
a
lot
of
these
great
cloud
native
technologies
that
some
of
us
work
on
an
open
source.
Some
of
us
use
they're
getting
that
in
the
hands
of
practitioners
and
developers
and
users
and
they'll
talk
to
you
a
lot
more
about
that
in
a
few
minutes.
First,
before
I
turn
it
over
them
a
few
simple
housekeeping
items.
Obviously
this
is
a
webinar
you're
not
going
to
be
able
to
talk
to
our
presenters
today
as
an
attendee.
A
What
we'd
love
for
you
to
do
is
use
the
Q&A
box.
That's
that's
there,
for
you
at
the
bottom
of
your
screen
and
zoom
feel
free
to
drop
any
questions
in
there
any
time
throughout
the
presentation.
The
presenters
are
going
to
try
and
keep
an
eye
on
that
since
there's
a
couple
of
them,
somebody
can
be
watching
for
QA
and
they'll,
either
deal
with
it
in
the
presentation
or
or
type
out
a
response
to
you
there.
A
This
is
an
official
webinar,
the
CNC
F
and
therefore
the
CNC
F
code
of
conduct
is
in
effect
and
basically
what
we'd
love
for
you
to
do
is
not
add
anything
to
the
chat
or
the
questions.
It
would
be
in
violation,
code
of
conduct
and,
of
course,
that
just
means
be
respectful
of
the
fellow
participants
and
the
presenters
all
CN
CF
webinars
are
recorded,
including
this
one.
A
B
You
Phil,
hopefully
everyone
can
hear
me.
Phillip-
did
a
great
job
kind
of
introducing
our
roles
just
a
little
bit
more
as
Phil
said,
I'm
role
of
Marcy
I'm.
Also
a
distinguished
engineer
in
IBM
and
CTO
of
our
solution.
Engineering
team
I
lead
a
team,
I'm
going
to
say
a
tribe
of
different
squads
really
in
the
garage
we
focus.
B
C
I've
been
working
in
customer
guidance
for
all
of
my
time
here
in
IBM
long
time,
I'd,
IBM
and
within
the
garage
have
have
led
a
couple
of
kubernetes
based
open
ship
based
engagements
as
well,
and
that,
like
I've,
been
working
on
and
leading
a
team
building
out
a
garage
cloud
native
toolkit
that
helps
that
will
help
us
make
our
developers
more
productive
and
our
projects
more
effective
on
open
Shipton
committee
to
use
the
best
of
what's
available
in
the
tools
and
we'll
walk
through
some
of
that
here.
A
little
bit
yeah.
B
And
I
guess
some
of
the
goal
here
is,
from
a
practitioner
perspective,
a
consultant
type
role
that
uses
a
bunch
of
different
open
source
projects
with
clients.
It's
it's
interesting.
You
know
when
you
work
with
large
banks,
insurance
companies,
government
companies
etc.
There's
always
a
mix
of
multiple
open
source
and
commercial
products
that
need
to
be
mixed
together
to
deal
with
things
like
security,
compliance
testing
and
an
automated
pipeline
and
there's
always
a
level
of
risk.
You
know,
do
I
start
using
new
open
source
projects
at
the
right
time
of
maturity.
B
Do
I
introduce
one
or
two
of
them
into
a
larger
pipeline
and
out
of
necessity,
working
with
our
clients,
we
have
to
create
various
different
ways
of
working
right.
Do
we
go
into
a
client
and
they're
like
well?
We
have
a
Jenkins
farm
already
deploying
legacy
things
and
it's
doing
our
security
scan
and
if
you
using
a
bunch
of
plugins
and
and
so
we
need
to
integrate
that,
but
we'd
like
to
adopt
our
go
to
start
managing
our
kubernetes
configuration
and
sean
is
going
to
take
you
through
the
toolkit.
B
But
I'm
gonna
give
you
as
a
CTO
of
you.
My
engineers
try
to
keep
me
out
of
the
code,
because
they're
scared
that
I'm
gonna
break
it
or
do
something
to
it.
Kind
of
give
you
a
getting
started
point
of
view
around
Tecton
and
Argo,
and
so
Tecton
is
to
me,
is
a
really
exciting
project,
because
its
first
native
kubernetes
a
lot
of
great
opportunity
to
not
only
it
run
in
a
cluster
but
actually
treat
Tecton
pipelines.
B
The
same
way
I
treat
my
application
and
so
the
ability
to
define
yeah
moe,
the
fine
infrastructure
as
code
inclusive
of
that
pipeline
and
being
able
to
deploy
that
like
an
application
and
the
pipelines
for
pipelines.
It
creates
great
opportunities
for
something
like
Arnaud
to
actually
push
out
the
pipeline
itself.
Argo
is
another
great
tool
from
a
perspective
of
C
D
and
not
just
C
D,
but
really
get
ups
and
driving.
B
You
know
how
clients
might
be
able
to
work
with
infrastructure
as
codes
and
developers
developers
for
a
while
have
been
used
to
having
yet
as
the
center
of
truth,
leveraging
C
ICD
doing
continuous
integration
and
deployment
operations.
Teams
coming
from
a
VM
background
have
different
degrees
of
comfort
working
in
that
space.
So
it's
it's.
You
know
we
work
with
kind
of
an
adoption
model
there,
and
so
a
very
simple
example-
and
this
is
just
kind
of
integrating
two
open
source
projects
together
and
we're
you
them
using
open
shift.
Doesn't
like
kubernetes
environment
here.
B
B
You
know
build
out
and
build
out
a
pipeline
out
of
you
know:
Tecton
artifacts
and
use
Argo,
which
can
be
configured
as
an
operator
using
the
operator
framework
CRD
onto
a
kubernetes
cluster
and
then
have
an
integration
around
you
know.
Taking
Tecton
having
Tecton
do
build
and
publish
up
images
into
an
environment
and
then
having
Argo
kind
of
drive.
The
deployment
of
a
particular
use
case
so
kind
of
doing
a
couple.
Devops
flows-
and
you
know
I
did
my
own.
B
B
So
integration
into
build
up,
for
example,
which
is
another
cool,
open
source
project
for
building
out
container
and
images
as
well,
as
you
know,
using
things
like
pod
man
and
other
types
of
things
and
different
levels
of
cluster
tasks
that
we
make
used
to.
So
you
know
from
a
pipeline
perspective,
you
know,
I
can
put
together
a
pipeline
which
is
a
template
and
I
create
some
pipeline
resources.
So,
for
example,
you
know
where
is
my
git
project,
and
where
is
my
image
repository?
B
This
could
be
something
like
way.
It
can
be
docker
hub.
It
could
be
anything
and
I
create
some
hard-coded
ones,
because
I
want
to
be
able
to
run
a
pipeline
manually,
let's
say
through
there
and
I
can
take
a
pipeline
which
are
made
up
of
tasks
and
I'm
using
predefined
tasks
here,
which
kind
of
show
the
reusability
of
Tecton
right,
where
I
want
to
use
a
build,
the
tasks
to
build
and
publish
my
image,
maybe
getting
my
base
image
from
something
like
way,
my
standard
docker
file.
B
Node
web
project
and
I
have
the
pipeline
already
deployed
and
the
steps
I
should
be
take
that
pipeline
and
run
it
and
I'll
do
that
in
a
moment.
I
want
to
get
it
a
little
bit
into
Argo
I'm
using
visual
side
of
Argo,
because
it
kind
of
demos
better,
there's
a
full
command-line
interface
to
it.
Where
you
know
it
takes
all
of
my
deployed.
So
I
have
two
applications:
I
have
a
node
application
which
I
just
talked
about
hello
world
and
I
have
my
pipeline
as
well,
and
right
now,
yep.
B
Thanks
and
so
you
know,
you
have
the
various
resources
to
find.
So,
let's,
let's
look
at
that
right.
Besides
the
pipeline
and
the
resources,
the
next
thing
is
I
want
to
trigger
a
bill
from
the
outside
world.
Most
a
web
hook,
usually
from
git
or
you
know,
get
lab
and
different.
You
know
different
techniques
for
that
I'm
using
a
very
simple
you
know
web
hook
for
illustration
around
get
push.
B
Obviously
you
know
there's
all
different
ways
to
do
it,
we're
branching
and
tagging,
but
a
trigger
template-
and
this
is
areas
where
you
know
hoping
the
open
source
community
drives
to
you
know
getting
less
artifacts
to
create.
You
know
things
from
the
outside
world,
but
there's
reasons
for
that
trigger
template
kind
of
gives
me.
You
know
a
way
to
define
a
template
for
how
I
want
builds
to
run
dynamically
so
I,
you
know,
I
recreate
some
of
the
pipeline
resources
and
I
might
want
to
and
I
hear
I'm
hard
coding,
but
I
could
change.
B
For
example,
the
tag
I
want
I
can
grab
the
input
from
the
web
hook
request
and
really
do
a
bit
more
dynamic
things
and
then
create
a
pipeline
run
out
of
these
resources
and
then
there's
an
event
that
event
ends
up
being
a
pod
that
runs
in
in
my
kubernetes
environment.
That's
listening
for,
for
you
know,
web
hook,
request
and
I
expose
it
through
an
open
shift
route.
B
You
can
use
ingress,
you
can
use
note
ports
whatever
and
then
a
binding
to
bind
the
template
to
that
require
so
minding
the
incoming
webhook
requests
to
the
the
build
and
that's
a
good
decoupling
practice,
because
I
might
have
different
types
of
source
control.
Repos
and
I
want
to
reuse
pipelines
in
the
large
organization,
and
so
these
are
different
kind
of
techniques.
To
do
that,
I've
also
configured
some
secrets:
I
won't
throw
the
secret
I,
have
a
template
for
the
secret
I've
I.
You
know,
even
though
we
talk
about
get-ups.
B
Probably
get
is
the
wrong
place
to
store
secrets.
Credentials
probably
want
to
grab
that
out
of
some
type
of
vault
environment
and
pull
that
from
there.
But
the
template
of
you
know
you
know
where
I
connect
to
my
server
user,
ID
and
password
and
so
I
check
all
that
in
and
you
see
that
node
argo
CD
is
actually
has
my
pipeline
in
sync,
etc,
and
and
I
can
kind
of
make
changes
to
that.
So,
if
I,
let's
see,
if
I
make
a
quick
change
to
the
to
the
resource.
B
B
B
As
well
there's
a
lot
of
different
advantages
to
that
some
people
are
very
comfortable
with
Ruby
scripting,
and
things
like
that.
You
know
it's.
Just
preference
I
really
kind
of
like
that,
and
then
so
now.
I
have
that
pipeline
deployed
I'm
going
to
go
into
that
project,
and
so
the
next
change
is
kind
of
from
a
Tecton
perspective.
I
showed
my
pipeline
deployed.
B
B
B
Now,
let's
make
it
one
about
six,
save
that
I'm
gonna
update
my
deployment
as
well.
It's
good
to
have,
if
you're
going
to
have
different
versions
to
do
things
like
canary
testing
Bluegreen
deploys
it's
good
to
have.
You
know
very
static
type
of
deployment
files
for
each
deployment
that
you
really
you
know
represent
so
I'm
going
to
go
ahead
and
push
that
into
an
environment
and
you're
gonna.
B
B
It
should
take
two
minutes
kind
of
tested
that,
but
you
can
see
we
can
get
access
one
to
a
few
things.
So
you
know
open
shift
as
a
pass
on
top
of
a
kubernetes
environments
out
of
a
lot
of
interesting
views
around
certain
things.
So,
from
a
developer
perspective,
I
have
my
trigger
and
I
no
running,
I'm
gonna
actually
go,
and
you
see
this
was
the
old
version,
while
I'm
still
building
so
I'll
close
that
out
and
you
can
get
a
lot
of
different
views.
B
You
can
actually
see
if
I
go
to
my
Argo
CD
namespace,
the
Argo
different
things
all
installed
with
a
single
operator,
including
my
art,
mode
dashboard
as
well,
and
you
see,
things
are
syncing
up
again,
which
what's
interesting
is
Fargo
detects
actual
pipeline
runs
and
it
detects.
It
is
out
of
sync,
even
though
it
I
needed
to
put
an
ignore
resource
in
there,
because
pipeline
runs
are
probably
things
that
are
gonna
there.
B
So,
if
I,
if
I
kick
it
off
from
the
web,
console
I
have
some
statically
defined
resources
or
I
can
in
put
them
in.
But
if
you
want
to
be
able
to
track
the
type
of
resources
together
with
the
pipeline
run-
and
you
can
do
that
so
here,
the
two
stages-
it's
doing
my
build
and
my
push
my
Argos
think-
should
happen.
Kind
of
the
zoom
thing
gets
in
the
way.
So
let
me
go
back
to
my
to
my
project.
D
B
B
Actually
you
see
here
that
it's
ramping
up
my
pots,
because
I
had
three
replicas
and
if
I
go
out,
you
see
a
hello,
CFCF,
hello,
new
pipeline
11.6,
so
the
goal
here
is:
you
know
this
there's
quite
a
bit
of
work
and
integrating
these
things
and-
and
so
you
know
one
of
the
things
that
we
work
a
lot
with
our
clients
from
the
garage
perspective.
Is
this
notion
that
and
I'm
gonna
hand
this
over
shortly
to
Sean?
Is
this
notion?
Is
it's
never
just
two
tools
right?
B
It's
always
a
mix
of
things
right
you
get
into
things
like
helm,
you
get
into
things
like
an
OP
stack
and
one
of
the
things
that
my
team
is
focusing
on
is
really
coming
in
and
saying:
hey,
you
know
what
is
the
tools
profile
for
a
particular
project?
Well,
you
know:
how
do
we
bring
these
together?
How
do
we
integrate
them?
How
do
we
do
that?
C
All
right
so
mentioned
earlier
kind
of
in
the
introduction
we've
been
and
as
Roland
mentions.
While
we
were
working
on
this
cognitive
toolkit
to
help
stitch
together
these
tools,
there
are
a
number
of
tools
and
know
this.
This
group
knows
better
than
than
anyone
just
the
landscape
of
the
many
different
tools
that
different
options:
how
to
put
them
together
to
make
a
solution.
C
So
we've
we
put
the
tool
to
get
to
the
others,
a
starting
point
for
initially
to
help
get
our
development
team
up
to
speed
with
building
containerized
applications,
and
then
it
turns
turned
into
something
we
use
for
projects
to
accelerate
our
projects.
The
way
that
our
projects
work
in
the
garage,
not
that
different
from
many
others,
but
we
work
in
an
agile
way
using
Lean,
Startup
and
other
approaches
where
it's
very
data-driven
decision-making.
We
we
come
up
with
a
hypothesis
at
the
beginning.
C
We
have
a
very
quick
MVP
that
we
build
to
prove
that
hypothesis,
maybe
four
to
ten
weeks,
and
we
really
don't
have
time
to
spend
a
lot
of
spend
a
lot
of
time,
building
out
an
infrastructure
and
making
these
tool
choices
and
making
them
work
together.
So
this
toolkit
helps
us
to
do
that
rapidly.
We
start
with
a
default
set
tools,
and
then
we
work
to
customize
it
based
on
the
environment.
C
So
in
an
environment
where
there
are
no
tool
choices
or
where
they're
new
to
cloud
native,
you
might
just
take
all
the
defaults,
but
then
we
can.
We
can
make
choices
on
top
of
that.
So
this
is
all
the
open
source
that
we're
building
this.
This
page
is
for
our
developer
guide.
That
gives
a
lot
of
what
I'm
going
to
go
through
will
be
kind
of
a
walkthrough
of
what's
found
here
in
this
developer
guide.
C
There
is
the
the
link
here
at
the
bottom
to
the
get
or
get
hello
org
that
has
all
the
other
content,
and
so
when
we
start
we're
really
looking
to
build
an
environment
to
support
DevOps
and
best
practice,
DevOps
in
containers,
so
building
containerized
applications
within
the
container
platform.
We
support
kubernetes
and
OpenShift
to
be
able
to
run
these
tools
and
then,
with
each
type
of
tool.
There's
continuous
integration.
There's
choice
amongst
those
we've
started.
C
You
know
we
ourselves
are
working
in
an
MVP
approach
where
we
start
with
the
common
ones
and
then
add
on
as
we
encounter
them
or
through
community
contribution
to
get
more
tools
added.
So
you
know
some
of
the
basics:
continuous
integration
code,
inspection,
contract,
testing,
continuous
delivery
with
Argo
or
it
could
be
done
with
Jenkins
or
Tecton
as
well,
but
separating
those
out
conceptually
artifact
management
and
the
image
registry,
and
so
we've
we
have
a
set
of
automated
scripts
to
terraform
scripts.
C
To
provision
this
environment,
which
you
make
your
tool
selections,
lay
down
all
of
the
tools
and
hook
them
together
through
config
maps
and
secrets
within
that
the
container
environment,
so
that
the
pipeline's
know
where
those
tools
live
and
how
to
connect
to
them.
So
then
we
can
get
up
and
running
quickly,
so
we'll
walk
through
one
where
I've
already
set
up
the
cluster.
We
have
Jenkins
and
Tecton,
both
they're
using
artifactory,
Jaeger
pack
broker
course
owner
cube,
so
we'll
we'll
walk
through
that
environment
and
see
what
the
development
experience
is.
C
There
we've
also
as
a
part
of
this
created
two
other
components:
a
CLI
to
help
smooth
over
some
of
the
some
of
the
more
complex
pieces
taking
for
developers
that
are
used
to
remember
more
has
like
environment,
so
just
simplifying
the
interface
in
the
access
to
the
to
the
tools
and
then
a
dashboard
just
similar
thing
that
helped
bring
to
the
developer
surface
those
tools
surface
to
the
activation
links
and
some
of
the
other
components.
So
with
our
container,
with
our
tools
in
place.
C
First
thing:
I'll
do
is
look
at
the
dashboard
and
we
we've
integrated.
We've
integrated
our
our
CLI
is
a
plug-in
to
cou
control
and
the
open
ship
CLI.
So
it
takes
us
to
the
where
you
can
see
here
some
information
about
the
cluster,
the
version
and
the
type,
the
resource
group
and
region,
some
of
the
for
the
IBM
cloud
where
that's
located
and
which
image
registry
we're
pointing
to,
in
this
case,
we're
using
yeah
in
cloud
image
registry.
C
But
that
could
be
the
internal
in
cluster
registry
or
some
external
one
as
well,
and
then
the
tools
that
have
been
installed
here
we'll
be
going
through
an
example
of
Tecton
and
Argo
using
artifactory
as
our
helm
repository.
So
our
default
pipeline
will
package
up
your
helm,
artifacts
into
a
helm,
repository
and
artifactory,
and
use
that
to
deploy
sonar
cube
for
for
security
scanner
for
for
code,
scan
quality
scanning
pack,
testing
contracts
and
and
Jager
for
the
end
and
trace.
So
we
also
the
part
of
this
dashboard
surfaced.
C
Some
activation
link,
some
data
coda
and
other
content
to
help
educate
and
bring
the
team
up
to
speed
on
the
technologies
that
we're
using.
And
then
we
provide
a
set
of
code
pattern,
starter
kits
for
getting
up
and
running
quickly.
If
you
have,
you
know
starting
any
project
and
you
are
working
in
a
particular
technology.
C
We
also
give
the
ability
to
if
you
have
your
own
starter
kit,
that
you
prefer-
or
you
have
existing
code,
to
be
able
to
enable
that
code
by
laying
down
some
helmet
chart
a
jenkins
file
so
that
it
will
build,
they
can
be
run
in
the
pipeline.
So
if
we
take
the
example,
we'll
start
with
make
typescript
micro
servus,
so
if
I
click
this,
it
takes
us
into
the
the
repository
where
we
have
this
again.
It's
all
public
github
and
we're
using
the
templating
engine
that's
available
in
github.
C
C
And
now
I've
got
my
own
version
of
the
application.
I
could
I
could
run
locally,
but
really
what
I
want
to
do
now
is
get
that
into
a
pipeline.
I
need
a
namespace
first.
So
all
we
give
this
this
command
sink,
which
essentially
it
creates
the
namespace
or
the
project
if
it
doesn't
exist
yet,
but
it
also
synchronizes
the
pool
secrets
and
sets
it
up
with
the
config
maps
that
describe
where
all
the
tools
are.
C
C
C
I
need
to
register
my
pipeline
I'm
gonna
use
Tecton,
so
we
already
have
picked
upon
installed
because
the
tools
were
installed
and
I
just
ran
flying
a
pipeline
today,
and
it
will
ask
what
type
since
we
support
both.
In
this
case
we
want
tech,
Tom
and
it's
going
to
read.
Well,
first,
it's
going
to
set
up
a
resource.
What
Roland
just
showed
it's
gonna
show
a
resource
that
contains
the
get
information
in
it.
C
So
it
read
from
there,
apart
from
my
local
file
system,
which
depository
connected
to
I,
tell
it
which
branch
I
want
to
build
off
of,
and
then
it's
gonna
read.
We
have
some
template
pipelines
that
have
been
created,
and
so
it's
going
to
read
those
from
the
environment
and
ask
which
one
I
want
to
apply,
since
this
is
a
node
based
application,
I'll
pick
our
node
pipelines,
and
so
it's
it's
has
created
the
pipeline
resource
with
the
git
repository
a
pipeline
resource
for
the
image,
and
now
it
has
created
a
pipeline.
C
Is
going
to
run
through
and
build
the
stages
of
our
built,
so
you
can
see.
There's
a
the
build.
Intestine
says
this
typescript.
There
is
a
build
stage
where
we
do
the
the
trans
filing
of
the
typescript.
We
run
our
unit
tests.
We
have
the
PAC
testing
that
if,
if
the
repository
has
any
PAC
tests,
it's
a
contract
testing
that
it
includes
they
will
get
executed.
If
not
it'll
skip
it.
Does
the
sonar
scan
run,
we
tagged
the
release
and
get
so
we're
using
it
as
the
source
of
our
version.
C
So
using
get
tagged
so
it
when
to
build
runs.
It
reads
from
get:
if
there
are
any
tags
that
are
available,
if
there
are
it
takes
the
latest
and
increments
it,
and
then
adds
that
tag
back
to
the
git
repository
and
uses
that
tag
to
version
the
helm
charter
version
the
image
so
they're
all
tied
together.
It
also
means
that
our
build
process
is
completely
ephemeral.
So
if
our,
if
we
kill
the
this,
you
know
Tecton
insensibly,
we
kill
the
Jenkins
instance
and
then
we
recreate
it
we'll
pick
up
our
builds
where
we
left
off.
C
C
So
so
this
and
I
I
see
there's
a
question.
You
don't
need
openshift
for
this.
We
support
a
code
gray
container.
So
if
you
run
code
ready
containers
which
is
openshift
on
your
machine,
you
can
run
all
this
there
locally.
Now
we
have
a
cut-down
version
if
you're
running
locally,
because
you
don't
need
as
many
resources
and
there's
some
parts
that
don't
make
sense,
you
could
also
run
it
on
kubernetes
instance,
as
well,
so
in
Guinea,
Kubb
or
another
service.
C
C
That
logic
is
the
same
or
your
content
container
a
mentor
guess
that
logic
is
the
same
regardless
of
what
the
source
is.
So
that
is
now
generic
task.
That's
reused
same
thing
for
deploying
into
the
cluster:
that's
a
shared
task
that
we
use.
Now
we
for
the
packet
verification,
that's
specific
again
through
the
platform,
so
we
we
bury
there
but
packaging
the
helm,
chart
and
get
ops.
Those
are
those
are
all
common,
regardless
of
the
language,
so
we're
able
to
reuse
those
tasks
quite
a
bit,
and
you
know
we
compose
those
tasks
into
a
pipeline.
C
C
We
are
doing
a
sonar
scan,
were
you
doing
PAC
verification,
so
this
one
uses
a
little
packet
verification
I
go
back
here
so
impact
if
you're
not
familiar,
is
a
contract
testing
framework
to
be
able
to
model
your
API
s
and
then
validate
them
between
the
consumer
and
the
provider.
So
this
is
the
BFF
consumer
and
a
provider
the
contract
defined
between
them,
and
so
you
can
define
these
patients.
This
contract
is
a
series
of
interactions.
Each
interaction
is
when
I
send
this
information.
C
This
is
my
expected
response,
and
so
we
see
that
this
ran
and
in
fact
there
was
an
error
in
validating
the
service.
The
last
time
this
ran
and
if
it
would
have
it
failed
the
build
of
the
service
at
that
time.
This
is
a
different,
a
couple
versions
after
this
is
a
version
different
than
the
one
that
we're
looking
at,
but
it
it
will
validate
and
prevent
you
from
deploying
broken
or
code
that
breaks
the
contract
between
the
consumer
and
the
provider.
So
we're
validating
that
with
each
deployment.
C
So
it
failed
the
build
because
of
the
because
of
that,
so
you
could
we're
enforcing
that
quality
and
again
it
can
be
configured
based
on
the
environment.
We
have
some
defaults,
we're
also
in
a
satiated
we're
using
the
open
source
version
of
all
these
tools
as
a
starting
point,
but
that
can
be
that
can
be
updated
with
a
licensed
version
and
get
full
features.
So
similarly
we're
using
artifactory
as
our
helm
repositories
as
the
as
the
build
progressed.
We
deploy
it
to
the
DCI
environment
to
validate.
C
If
it's
valid,
then
we
publish
our
home
chart
into
the
helm
repository.
Since
this
is
the
open
source
version.
We
are
using
the
local
storage
to
Newark
local
storage.
So
this
is
one
you
see
that
it
built,
and
this
is
the
helm
repository
the
version
that
was
built
previously
or
I,
guess
I
think
that's
still
in
progress
and
then
the
ones
that
were
built
again
as
the
for
the
inventory
that
we
were
showing.
So
it's
it's
based
on
the
tag.
C
I've
linked
here,
so
it's
it's
essentially
hooking
into
our
git
ops
repository
that
was
configured
that
was
created
previously
so
for
each
component,
the
build.
What
it's
doing
is
updating
since
we're
using
helm.
We
have
a
reference
to
the
home
chart
that
was
built
as
a
part
of
the
part
of
the
process
that
helm
chart
includes
the
image
version
that
matches
the
version,
and
so
the
automated
build
is
just
updating
the
version
number
with
each
build
that
occurred.
So
it
gets
incremented
that
kicks
off
a
deployment
in
our
go
into
our
test
environment.
C
And
then
we
have
this
test
branch
as
the
default,
and
then
the
staging
environment
is
handled
through
the
staging
branch.
So
we've
opted
in
this
case
to
use
git
flow
as
the
approach
for
for
handling
versions
across
environments
so
that
we
can
use
things
standard
things
from
get
like
pull
requests
to
promote
changes
from
one
environment
to
the
next.
So
we've
got
the
deployment
in
so
you
can
see,
there's
a
different
version
of
the
UI
and
staging
then
it's
currently
in
test
and
so
that
all
got
deployed
into
our
go.
C
Look,
let's
see
so
we've
each
component
has
been
deployed
into
both
the
tests.
Namespace
and
the
staging
namespace
is
separate
applications.
So
if
we
look
at
anyone
we
can
see
these
is
a
fairly
straightforward
application.
At
this
point,
let
me
see
the
deployment
and
the
pod
there's
one
pod
there
with
each
new
build
of
this.
It
will
get
refreshed.
This
is
all
set
to
auto
sync
at
the
moment.
So
if
I
were
to
change,
this
is
our
test.
Pff.
C
Again,
we're
taking
the
defaults
at
this
point
because
it's
simple,
but
you
know
whatever
custom
configuration
to
the
helm
chart
would
be
required,
would
be
added
here
in
the
values
file,
so
it
would
be
whatever
varies
by
environment
would
be
updated
here
and
managed
as
a
part
of
that
process.
So
let's
upgrade
the
replicate
count.
This
is
a
easy
change
to
make,
typically
in
a
real
environment
you'd
let
the
autoscaler
do
this,
but
for
purposes
of
the
demo
this
works
pretty
well
to
show
just
how
again
in
this
get
office
environment
our
NGO
is
watching.
C
If
we
waited,
it
would
automatically
sync
I'll
go
ahead
and
sync
it
to
have
it
find
those,
and
so
it
will
detect
that
there
was
a
change
and
then
see
that
it's
out
of
sync
and
it
will
bring
it
into
sync,
just
like
that.
So
with
each
deployment
is,
it
is
going
to
synchronize
the
changes
and
see
that
a
new
version
is
available
and
push
that
version.
If
there's
new
config
available,
it
would
change,
it
would
push
that
and
then
we
can
use
again
the
value
of
get-ups.
C
C
We're
building
a
UI
component,
a
BFS
that
is
graph
QL
and
a
Java
spring
back-end
application
right
now,
it's
not
connected
to
a
particular
back-end,
but
we
in
this
case
for
the
purpose
of
the
demo,
we
were
using
a
canned
response,
so
we
can,
with
the
starter
kits
that
we
provide
we
every
one
of
them
has
swagger
UI
that
it
provides
and
they're
by
default.
The
ingress
is
turned
on
so
that
you
can
see
it.
So
we
can.
We
can
look
at
the
data
coming
back
from
our
service.
C
C
And
then
the
UI
and
it's
a
very
simple
UI,
but
returning
those
same
items
that
are
going
through
the
DFS.
We
can
we've
validated
each
level
what's
happening
and
then
we're
also
showing
in
the
topology.
We
can
look
at
those
components
now.
This
is
a
openshift
feature
right,
that's
not
currently
available
and
it's
better
for
developers
a
nice
view
of
what's
been
installed.
What
are
the
relationships
between
the
components?
In
this
case
you
can
see.
We
have
our
UI.
We
have
our
our
BFF.
C
C
C
So
BFF
back
in
for
front-end,
so
it's
a
architectural
pattern.
In
this
case,
we've
used
it
more
as
an
example
of
building
a
three-tier
application
and
how
the
components
will
work
together.
But
so
the
idea
is
for
more
complex
applications.
It's
a
little
bit
overkill
in
this
case,
since
it's
one
service,
one
UI.
C
C
So
how
is
this
toolkit
different
from
Jenkins
Exide?
So
we
use
jenkins,
but
we're
tying
together
some
of
the
tools,
some
other
tools
that
that
are
used
like
security
scans
and
some
of
the
others.
So
we're
incorporating
twistlock
and
aqua
to
do
some
security
scans.
But
you
know
leveraging
those
platforms
been
providing
some
some
basic
out-of-the-box
pipelines
that
provide
some
of
the
more
advanced
features
that
most
of
the
time
you
get
kind
of
a
hello
world.
If
anything
out
of
the
box.
C
The
other
part
of
it
is
how
all
these
tools
got
here:
the
automation
of
provisioning
of
those
environments
and
to
get
all
of
the
pieces
together.
So
that's
we're
we're
leveraging
Jenkins
in
the
container,
where
that's
being
used,
because
we
have
a
lot
of
customers
that
are
still
using
Jenkins
and
they're
familiar
with
it
and
comfortable
with
it.
B
You
know
what
I
have
a
standard
I'm
using
Nexus
instead
of
artifactory
for
a
repository
and
I'm,
using
these
test
tools
and
I'm
using
all
these
different
tools,
and
so
the
problem
is
broader
than
just
who
orchestrates
the
build
or
who
work
is
straight
to
build
and
the
tests.
It's
it's
kind
of
a
broader
issue.
When
we
go
out
and
work
in
the
field
that
that
makes
sense.
C
And
there
are
multiple
deployment
models
that
will
use.
Jenkins
is
on
premise,
and
so
so
the
questions
benefit
to
the
high
click
on
that.
So
there's
a
another,
some
debate
with
even
just
the
toolkit
itself
right.
The
goal
is
to
help
facilitate
projects
I
find.
If
you
try
to
hide
details
too
much
from
people
you
eventually
you
get
yourself
in
a
bad
way.
So
you
know
by
using
the
toolkit
we're
not
absolving
any
of
the
developers
from
understanding
containerized
applications
or
even
the
devops
environment.
Somebody
needs
to
understand
it.
C
Maybe
that's
your
Sree
on
the
project
and
developers.
Don't
need
to
focus
on
that
as
much,
but
but
there
still
needs
to
be
a
fundamental
understanding
of
of
how
everything
works.
The
the
goal
is
to
borrow
phrase,
it's
popular
now
so
kind
of
flatten
the
curve
for
learning
the
environment
to
get
up
and
running
and
learn
as
you
go
so
I
think.
They're
still,
you
know
we.
C
We
still
give
you
enough
to
get
started.
You
know,
like
I,
said
in
our
projects.
We
don't
want
to
spend
four
weeks
just
piecing
the
parts
together
and
and
be
able
to
then
be
productive
we'd
like
to
figure,
you
know,
make
those
tool
selections.
Upfront,
we
in
our
process
have
a
have
a
discovery
where
we
lay
out.
These
are
the
tools
that
you,
you
know
as
a
customer
that's
already
using
and
we
want
to
continue
to
use.
C
These
are
the
tools
that
are
new
that
will
incorporate
and
and
get
all
of
that
set
up
so
that
and
we
we
call
it.
We
call
the
that
part.
The
provisioning
part
iteration
zero,
because
iteration
one
is
when
you
start
the
project
and
do
work,
so
we
like
in
iteration,
zero
to
get
all
of
that
installed
and
in
an
iteration
one
day.
One
development
team
is
already
writing
business
logic
and
not
infrastructure
plumbing.
But
at
some
point
that
you
know
you
can't
hide
all
of
the
details,
so
somebody
somewhere
has
to
know
that
you
can.
C
C
But
that's
the
nice
thing
with
Tecton
in
particular,
is
the
modular
nature
of
the
tasks.
Sometimes,
you've
got
a
good
understanding
what
they
do
that
you
can
plug
and
play
so
the
so.
The
things
are
two
questions
so
open
source.
So
everything
here
is
open
source
that
there
are
no
licenses
required
apart
from
getting
yourself
a
cluster.
So
that's
where
you
can
use
your
CD
or
you
can
use.
You
know,
get
a
coaster
from
somewhere,
but
from
that
from
after
that,
all
of
these
tools
are
open.
Source
versions
of
everything.
C
Now
there
are
paid
versions
of
you
know
licenses
that
you
can
get
for
most
everything
that
we're
using.
That
gives
you
either
additional
functionality.
So
sonar
cube
out
of
the
box
for
open
source
version.
You
get
most
every
scan
language
that
at
least
that
we
have
needed
Swift.
You
have
to
pay
for,
and
some
of
the
others
artifactory
there's
some
paid
features,
but
everything
everything
I
just
showed
his
open-source
free
versions
of
everything.
As.
B
C
So
there's
there's
a
tool
selection
up
front
in
the,
and
we
go
through
that
and
the
administrator
guide,
how
to
get
the
environment
up
and
going
how
to
make
the
tool
selection,
so
part
of
that
would
be
picking
say.
Nexus
over
artifactory
would
be
the
matter
of
the
tool
choice
we've
if
there
is
a
module
that
exists
already
in
some
cases.
In
many
cases
we
have
the
alternatives
already
there
in
the
the
provisioning.
You
would
just
pick
one
over
the
other
and
then
in
the
when
it
gets
provisioned.
C
C
C
We
went
with
that
because
it
it
has
been
at
the
time
it
was
fairly
new,
but
it
was
the
one
that
had
a
lot
of
buzz
around
a
lot
of
interest
and
proven
to
be
a
great
tool
for
using
in
this
manner.
So
so
there's
those
tools
can
be
plugged
in
and
there's
some
configuration
that
that
would
incorporate
it
and
then
there's
a
model
for
you
know
how
to
build
your
own
and
contribute
that
addresses
the
question
role.
Yeah.
B
C
C
But
the
goal
is
for
that:
could
be
production
ready
and
to
go
into
production,
so
build
to
manage
is
part
of
what
we
what
we
do
so
logging
monitoring,
which
you
know
we
would
get
installed
as
part
of
platform
day
one
and
within
the
the
you
know,
starter
kits
and
the
code.
That's
built
thinking
about
those
things
from
the
beginning
and
and
not
leave
that
to
the
last
minute
and
I.
Think
that's
why
incorporating
things
like
jmeter
and
making
performance
testing
part
of
that
early
as
well?
C
B
And
the
last
question
is
pretty
loaded
one
any
like
lessons
from
devops
world
I.
Guess,
there's
a
lot
of
lessons
right
to
cover
in
one
session,
I
think
that
you
know
there's
a
lot
of
different
scenarios
that
clients
work
with
some
people
want
their
DevOps
outside
of
the
cluster
because
they're
doing
it
across
multiple
clusters.
Some
people
want
to
leverage
managed
versions
of
services
that
exist.
So
you
know
we
kind
of
detect
and
use.
What's
there,
you
know
the
the
last
piece
where
you
know
giving
you.
B
C
I'd
say
in
this
space
the
development
space
in
the
UI
there's
a
lot
of
opinion.
There's
there's
less
not
as
many
demos
but
there's
still
quite
a
few,
so
the
tool
selection,
that's
where
we
try
to
be
somewhat
open,
but
there's
still
some
principles
there
that
have
kind
of
formed,
especially
in
a
containerized
environment.
Where
you
know
your
CI
pipeline
is
separate
and
distinct
from
your
continuous
delivery
pipeline,
whether
you're
using
something
like
Argo
or
not.
You
still
make
them
separate
because
in
this
model
your
CI
pipeline
is
building
a
version.
C
De
mutable
image
is
packaging
up
some.
You
know
kubernetes
resources
in
this
case
we're
using
home.
You
can
use
other
technologies,
but
but
keeping
that
separate,
you
know
there's
it
gets
problematic
when
all
of
that
is
part
of
the
part
of
the
same
bill.
Doing
the
you
know
the
the
image
scanning
up
front
at
the
time
of
bill,
but
also
periodically
or
continue
that
deployment
time
and
in
the
cluster
is
important,
because
even
through
doing
building
out
this
toolkit
things
aged
fairly
quickly
just
sitting
on
the
shelf
right.
C
B
A
We're
at
the
top
of
the
hour,
maybe
a
minute
passed
lots
of
great
information
thanks
so
much
to
Roland
and
Sean
for
their
presentation,
lots
of
questions
got
answered
as
well,
so
that
was
great
and
of
course,
given
we're
out
of
time.
That's
all
we
have
time
for
thanks
for
joining
us.
I
know
some
folks
should
have
played
and
we're
hoping
there'd
be
a
recording
that
will
be
online
later
today,
and
we
look
forward
to
seeing
all
of
you
to
future
CN
CF
webinar
have
a
great
day
thanks.