►
From YouTube: Reusability and its impact on DevOps
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
very
warm
welcome
to
all
of
you
to
this
webinar,
it's
all
about
how
you
have
reusability
in
terms
of
pipelines,
specifically
in
the
modern
context
in
a
cloud
native
world,
but
before
we
head
into
it
a
little
bit
of
context
in
terms
of
what
is
happening
in
the
current
market
right
now,
specifically
in
large
organizations
which
are
involved
in
banking,
telecom,
finance,
petroleum
industries
etc.
A
Just
from
our
experience,
so
in
the
past
it
was
more
like
kubernetes
or
container
technology
was
adopted
by
organizations
which
are
new
age.
More
so,
like
you
know,
startups,
think
facebook
think
instagram
or
thing
something
on
the
lines
of
an
e-commerce
website
that
is
within
your
region,
but
with
the
passage
of
time,
kubernetes
has
become
the
de
facto
standard.
A
What
typically
happens
in
such
organizations
is
that
there
are
multiple
sources
of
where
they
source
their
applications.
From
with
that
being,
some
of
it
might
be
developed
internally.
Some
of
it
might
be,
like
you
know,
quartz
applications
which
are
supplied
by
external
vendors,
for
example.
Take
the
example
of
finickle
right
clinical
is
developed
by
a
company
called
infosys,
which
is
a
part
of
the
core
banking
systems
of
like
many
financial
institutions.
A
With
that
said,
and
done,
there
is
a
need
for,
like
you
know,
distributing
your
applications
across
pretty
much
any
cloud,
one
being
business
expansion,
the
other
being,
like
you
know,
technical
limitations
with
certain
clouds
lack
of
availability
of
infrastructure
in
a
particular
region,
for
example
in
the
middle
east.
It's
only
now
that
aws
is
entering
this
scenario
and
like,
for
example,
providing
all
of
its
infrastructure
tying
up
with
like
local
providers,
in
terms
of
where
the
data
centers
are
hosted
and
eventually
giving
you
a
kubernetes
cluster
right.
A
So,
although,
like
you
know,
business
demands
that
you
expand
to
as
many
reasons
as
possible,
typically
in
mature
organizations,
it's
quite
the
challenge
when
it
comes
to,
like
you
know,
getting
your
applications.
There
now
think
about
it.
If
you've
got
a
kubernetes
cluster,
the
eventual
end
goal
of
an
organization
is
to
run
applications
over
there.
So
before
we
get
into
that,
we
would
like
to
like
just
introduce
modish
who's,
a
technical
lead
as
well.
A
What
are
what
are
the
like?
You
know
typical
problems
that
you
see
when
it
comes
to
a
junior
developer,
who's
who's,
working
on
applications
and
needs
to
get
his
deliverables
to
any
kubernetes
cluster.
B
Okay,
thanks
prashant
for
the
question
so
I'd
like
to
in
general
tell
about
what
are
the
problems:
individual
devops
or
developers,
even
new
ones,
even
the
old
or
experienced
ones
face
every
day.
So
may
the
main
problem
I
see
is
at
the
time
that
is
spent
on
the
development
versus
configuration
or
deployments
onto
multiple
ecosystems
and
multiple
infrastructures.
B
Basically,
whenever
a
developer
comes
into
developing
mode
and
he'll
have
to
set
up
some
some
of
the
things
that
is
required
for
his
day-to-day
work,
so
for
testing
his
day-to-day
changes
and
delivering
a
solid
proof
solid
product,
so
he
has
to
set
up
some
of
the
stuff
all
the
micro
services.
As
of
now,
we
have
multiple
micro
services
in
our
day-to-day
work
that
are
involved
after
setting
up
for
testing
the
things.
B
So
the
most
of
the
time
is
spent
on
configuring,
all
the
different
infrastructure
con
components,
and
then
he
can
test
out
test
out
what
his
features
are.
So
this
this
place.
We
are
spending
too
much
time.
That
is
one
of
the
problems
I
see
in
our
day-to-day
devops
workflows,
and
this
happens
not
just
a
single
day.
B
It
happens
every
single
day
and
it
happens
with
every
developer
and
every
devops
engineer,
and
that
consumes
a
lot
of
time
and
it
requires
a
lot
of
training
when
it
comes
to
so,
if
a
new
developer,
if
you
are
on
boarding
a
new
developer
onto
your
team,
so
you'll
have
to
train
them
regarding
your
infrastructure,
how
how
the
different
components
fit
together
and
for
him
to
get
up
and
running
with
the
setup
of
everyday
development.
B
B
We
can't
do
it
right
all
the
time,
basically
so
even
for
experienced
developers
it.
It
happens
that
they'll
get
into
some
configuration
issues
and
they
will
try
to
debug
those
issues
and
it
consumes
a
lot
of
time
in
the
process
of
development
delivering
the
product
from
development
stage
to
the
deployment
stage.
B
So-
and
this
is
not
repeatable,
if
you
are
doing
it
manually-
and
there
is
a
so
if
what
if
some
some
of
the
infrastructure
goes
down
and
you
have
to
communicate
with
different
teams
and
this
you'll
have
to
raise
tickets
and
communicate
with
the
team
get
it
resolved
and
all
these
things
are
as
of
now
it's
manual
which
takes
a
lot
of
time,
and
you
can't
give
typical
companies
will
have
multiple
infrastructures,
multi-cloud
infrastructure,
where
we'll
have
different
setups
for
and
for
development,
one
type
of
setup
and
for
production
there
is
another
type
of
setup
and
how
do
you
control
the
access
between
development
and
production
workflows?
B
That
is
another
area
where
we
have
to
improve
a
lot.
A
And
yeah
interesting
thoughts,
but
just
we
want
to
tell
a
little
more
into
the
teams
like
so
now.
What
the
current
scenario
that
we
have
in
our
product
team
is
such
that,
like
you
know,
you
have
independent
teams
like
which
are
managing
microservices
and
considering
that
it's
heading
towards
the
microservice
level
architecture,
and
what
are
the
challenges
that
you
foresee?
Like
do
p?
Do
development
teams
have
their
own
preferred
frameworks
for,
like,
let's
say,
quality
analysis
or
security
scans
etc,
like
what
is
the
scenario
right
now,.
B
Yeah,
the
typical
development
process
from
development
to
production,
how
it
goes
basically,
when
a
developer
submits
their
code,
they
will
the
reviewer
has
to
go
through
the
code
and
has
to
approve
the
pull
request
and
it
it
can't
be
guaranteed
that
a
reviewer
can
identify
all
all
the
security
issues
that
are
happening
that
might
arise
in
the
future
and
it
it
goes
beyond
the
developer's
control,
where
it
will
have
to
go
into
some
some
staging
setup
or
an
alpha
setup
where
your
quality
engineers
quality
assurance
engineers
will
test
it
out
and
figure
out.
B
On
top
of
that,
there
is
some
companies
will
have
security
teams
who
actually
try
to
test
the
security
issues
in
the
product,
and
this
cycle
will
take
a
lot
of
time
to
proceed
further,
like
from
development
to
the
deployment.
It
takes
a
lot
of
time
to
validate
each
and
every
step
and
go
through
the
process
of
delivering
a
solid
proof
and
secure
product.
A
What
are
the
typical
challenges
when
it
comes
down
to,
like,
let's
say,
a
developer,
consuming
like
let's
say,
security
standards
or
quality
standards?
And
again,
let's
rewind
back
to
like
someone
who's
setting
standards
at
a
framework
level
like
you
might
have
node.js
that
one
team
prefers
and
you
might
have
another
team
programming
on
go
so
is?
A
Is
this
a
major
point
that,
like
you
know,
an
organization
follows
that,
like
you
know
that
you
have
a
standard
repeatable
process
like
and
if
so
like
you
know,
what
are
the
typical
gaps
from
you
as
a
technically.
B
So
whenever
I
observe
people
whenever
there
are
like
multitude
of
tools
that
are
available
today
and
each
individual
developer
has
their
own
preference
towards
using
those
tools,
even
though
they
are
out
outdated,
they
might
not
want
to
use
the
latest
technologies
and
they
might
not
want
to
learn
new
technologies.
B
Some
of
some
people
are
passionate
enough
to
learn
new
technologies
and
try
to
experiment
with
the
new
ones.
So
most
of
the
people
I
find
are
hesitant
to
move
from
what
they
know
and
do
what
new
features,
new
tools
that
are
available,
even
though
they
are
more
secure
and
more
powerful
than
what
they
are
using
because
they
learn.
B
They
have
spent
too
much
time
on
on
those
tools
and
they
stick
to
that
because
of
their
inertia
to
move
from
one
technology
to
another,
and
there
are
well-known
vulnerabilities
in
the
old
versions
of
the
tools
and
and
some
some
tools
are
no
longer
valid
for
the
latest
use
cases.
So
this
area
so
from.
B
So
there
are
some
standards
that
we
can.
Each
each
individual
organization
can
have
its
own
standards
and
there
is
no
universal
standard
as
as
of
now
that
can
guarantee
a
product's
security.
A
And
stuff,
that's
very
well
put
modish!
Thank
you
for
that.
So
the
point
that
we
are
trying
to
bring
out
over
here
is
that
you've
got
so
many
teams
that
are
following
so
many
frameworks.
Some
security
scan
scanning
tools
do
not
support,
like,
let's
say
older
frameworks
like
let's
say
spring
boot,
but
they're
really
good
at
like
identifying
or
meeting
the
needs
of
a
specific
team.
A
Now,
when
you've
got
a
micro
service
level
architecture,
the
one
aspect
that
you've
got
is
like
self-sufficient
teams
that
is
driving
the
whole
software
development
life
cycle
into
pretty.
Much
like
you
know,
product
and
platform,
engineering
teams,
where
product
teams
or
product
engineers
are
holy
and
essentially
responsible
for
all
of
the
quality
and
all
of
the
security.
But
yes,
you
have
platform
and
security
coming
in
and
setting
those
standards.
A
That
is
where,
like
the
whole
cultural
shift
is
happening,
and
this
is
typically
defined
as
a
shift
left
movement
where
it's
not
that,
like
you
know,
you
develop
an
application
and
leave
it
to
somebody
else
to
verify
the
quality
or
security
compliance
aspects.
A
You
pretty
much
tackle
it
well
much
much
more
earlier
within
the
software
development
life
cycle,
preferably
like
you
know,
even
like
before
the
development
environment
stage.
That
again
is
subject
to
the
organization
that
you're
in
and
the
scale
of
your
like.
You
know,
application
delivery
and
the
scale
of
like
you
know
the
possible
risks
that
are
involved
that
virus
over.
Here
I
mean
business
loss,
downtime
or,
like
you
know,
compliance
issues,
regulatory
issues.
A
So
if
you
make
a
mistake,
it's
going
to
be
really
really
costly,
especially
in
the
in
the
sectors
that
we
typically
like
you
know,
deal
with
so
again,
there's
one
very
important
point.
I
think
that
we
need
to
cover
before
we
head
into
the
full
technicalities
of
what
reusability
means
in
the
modern
cloud
native
scenario,
and
that
is
like
you
know,
the
skill
sets
so
modish.
How
difficult
is
it?
There
are
two
questions
that
I
have
here.
A
B
Okay,
so
today,
kubernetes
has
is
the
de
facto
standard
for
everything
that
that's
happening
in
the
world.
When
it
comes
to
kubernetes,
it
is
rapidly
changing
and
there
is
a
huge
ecosystem
that
is
growing
beyond
our
control.
B
That
happens
every
day
like
every
day
we
see
every
month,
so
many
projects
are
getting
added
to
cncf,
and
so
all
these
tools
have
their
own
purposes
and
they
have
their
own
ways
of
adding
functionality
to
what
kubernetes
offers
as
a
base
for
us
to
learn
these
things
and
okay,
we
would
be
used
to
some
of
the
technologies
and
some
of
the
workflows
that
we
use
every
day
for
kubernetes.
B
So
if
we
had
developed
and
deployed
our
infrastructure
in
a
certain
way-
and
there
might
be
a
new
tool
that
is
coming
up
in
the
next
next
days-
and
we
may
not
be
ready
to
actually
accept
that
into
our
infrastructure
because
because
of
there
will
be
a
lot
of
moving
parts
and
if
we
put
that
new
tool
into
the
infrastructure
that
might
break
some
of
the
stuff-
and
it's
also
not
easy
to
expect-
it's
not
easy
to
learn
the
new
things
that
are
the
rapid
rate
at
which
the
new
technology
is
coming
up
in
cncf.
B
So
it's
not
really
is
really
it's
not
easy
to
learn
all
the
new
things
that
are
happening.
So
we
need
a
unified
way
of
saying.
Each
developer
doesn't
need
to
know
all
the
tools.
So
if
there
is
a
system
that
can
provide
all
the
things
that
are
required
and
if
some
some
set
of
engineers,
if
somebody
is
taking
the
time
and
effort
to
put
together
all
the
stuff
cncf
projects
and
giving
it
as
an
abstract
functionality
to
an
infrastructure
team
that
would
help
us
in
a
big
time.
B
A
Very
well
put
thank
you,
modish
with
that,
I
will
hand
it
over
to
modish,
to
take
you
through
the
technicalities
of
what
is
reusability
and
how
is
it
changing
in
terms
of
a
cloud
native
world
where
kubernetes
is
the
de
facto
standard?
So,
thanks
over
to
your
modish.
B
And
thank
you
prashanth,
so
extending
the
problems
that
I
defined
earlier,
so
what
it
takes
to
achieve
a
consistent
and
an
efficient
deployment
mechanisms
onto
multiple
infrastructure,
multiple
ecosystems
of
multi-cloud
infrastructure.
B
B
Basically,
even
when
you
have
within
the
same
organization
when
you
have
different
set
of
environments
where
development
teams
will
work
on
some
environments
and
the
production
environment,
staging
environment,
these
different
types
of
environments-
and
if
you
have
especially
when
you
have
multi-cloud
infrastructure,
so
you
should
have
a
way
of
deploying
your
own
infrastructure,
deploying
your
own
microservices
onto
different
platforms,
repeatable
in
a
repeatable
fashion.
B
So
you
can't
just
manually:
do
it
every
time
it
takes
up
too
much
time,
so
automatic
validation
and
absolutely
it
takes
too
much
time
to
actually
certify
a
build
and
then
deploy
to
staging
and
then
to
production.
If
we
do
it
manually,
it
takes
too
much
time
so
in
the
fast
moving
world
today.
So
we
can't
afford
to
have
that
much
of
time
lag
between
releases,
so
a
lot
of
developers,
time
and
even
devops
engineers,
time
and
sre's
time
is
getting
wasted
in
this
area.
B
So
if
you
are
not
repeating,
if
you,
if
your
infrastructure
deployment
is
not
repeatable,
so
it's
not
the
efficient
way
of
working.
So
we
should
have
a
simple
and
easy
to
have
deployments
and
it
should
be
error
free.
So
what
happens
when
you
do
manual
deployments?
Is
it
causes
human
errors?
So,
if
we
are
deploying
if
it
works,
the
common
notion
is
like
it
works
in
my
laptop.
It
works
in
my
environment,
so
this
typical
developers
usually
have
heard
of
this
phrase.
Basically,
it
works
in
my
setup.
So
that's
why
it
came.
B
B
Alright,
alright,
because
of
that,
so
we'll
have
complex
communication
mechanisms
between
different
microservices
and
service
measures
is
a
different
concept
that
comes
into
picture
here
and
configuring,
those
service
measures
and
it's
a
different
ballgame
and
it's
very
difficult,
and
it's
not
easy
to
get
that
done
without
errors,
and
we
need
a
notification
mechanism
that
can
detect
areas
in
the
infrastructure
and
notify
us
about
the
issues
and
if
you
are
doing
it
manually
once
again,
we
it's
not
an
efficient
way
to
do
it.
B
So,
in
this
regard,
how
we
can
of
standardization
and
an
effective
interface
that
can
reach
the
gap
between
the
development
and
deployment
I'd
like
to
present
some
of
the
ideas.
So
what?
If
the
first
idea
is
what,
if
we
can
visualize
our
infrastructure
on
the
screen
on
the
computer
screen
and
what,
if
you,
can
drag
and
drop
your
applications
onto
your
infrastructure,
just
like
just
like
in
a
computer
game?
B
So
what?
If
the
ui
shows
deployment
dependencies
on
all
your
configurations?
If
you
do
something
wrong
in
the
configuration
before
you
even
deploy
it
onto
your
deployed
onto
your
infrastructure,
if
the
system
is
able
to
show
you,
this
is
what
you
have
done
wrong.
If
you
deploy
this
particular
application,
you
will
get
into
errors.
B
What
if
the
system
is
intelligent
enough
to
suggest
you
that
kind
of
errors
and
what,
if
we
have
a
whole
new
set
of
libraries,
pre-built
libraries
for
deploying
into
multiple
architectures
and
multiple
models,
modes
of
deployments
like
blue
green
deployments
canary
and
if
we
have
pre-built
guitars,
workflows,
setup
and
what?
If
we
can
achieve
deployments
without
writing
any
code?
It's
a
complete
hundred
percent
deployment,
automation.
What
if
we
can
do
it
and
if
we
could
manage
all
the
cloud
accounts
nowadays,
organizations
will
have
multiple
cloud
accounts
and
they
have
different
environments,
different
clouds.
B
So
what
if
we
can
manage
all
those
cloud
accounts
within
one
platform?
This
is
an
area
where
a
unified
platform
can
help,
and
so
in
that
regard,
so
there
is
a
an
open
source
tool
called
tecton,
which
is
a
very
useful
tool,
language
which
is
lightweight
and
generic
and
it's
very
flexible
as
well.
So
with
tektron,
you
can
actually
automate
all
this
all
the
stuff
that
I
have
discussed
earlier.
B
I'd
like
to
share
some
of
the
problems
that
I
see
in
tecton,
so,
basically
it
it
is
a
bit.
It
takes
a
bit
of
time
to
learn
now,
but
not
everybody
knows
how
to
create
checked
on
task
and
how
to
run
a
tech
on
run.
Click
on
task
run.
B
So
it
actually
integrates
with
all
these
some
of
the
solutions
that
we
have
today
are
jenkins
x.
Ozone
scaffold.
B
Can
you
do
an
open
shift
pipelines,
so
some
other
things
I
have
multi-cloud
ecosystems
and
openshift,
especially
doesn't
have-
doesn't
provide
you
with
a
functionality
to
manage
your
own
cloud,
so
you'll
have
to
go
with
openshift
ozone,
on
the
contrary,
can
provide
you
with
a
lot
of
multi-cloud
ecosystem
management
utilities,
and
you
can
connect
all
your
ecosystem
of
multiple
cloud
accounts
and
multiple
repositories,
and
you
can
automate
most
of
the
stuff
in
your
deployment
process,
and
these
tools
have
a
very
good
user
interface
and
ozone
especially
has
a
drag
and
drop
functionality
where
you
can
build
your
own
pipelines
with
just
a
few
clicks,
and
you
can
automate
most
of
the
stuff
that
I
discussed
earlier
so
yeah.
B
These
tools
have
some
predefined
templates
and
ozone
has
a
huge
set
of
predefined
deployment,
templates
that
you
can
reuse,
tecton
templates
and
even
extending
the
tectonic
templates
like
for
achieving
guitars
kind
of
deployments.
Blue
green
canary.
There
are
predefined
templates
for
that,
and
you
can
manage
all
your
cloud
accounts
within
one
one
screen.
B
So,
and
it
absolutely
has
no
learning
code,
so
it's
easy
to
use
so
with
that
said,
we
are
here
up
to
up
to
some
level.
We
have
achieved
a
pretty
good
value
stream
delivery
mechanism
for
on
top
of
tecton,
and
we
are
still
in
the
process
of
improving
that
and
we
are
trying
to
make
the
deployment
procedures
easy
to
do
and
repeatable.
B
So
this
is
where
this
is
how
what
I
want
to
say
about
the
repeatable
deployments
and
yeah
reuse
of
pipelines.
Yeah.
Thank
you
guys
over
to
you,
prashanth.
A
Thank
you,
modish,
very
well.
Put
so
again.
The
callback
is
towards
a
multi-cloud
scenario,
which
is
being
driven
by
largely
from
a
compliance
perspective
from
business
and
lack
of
availability
of
certain
technologies.
Like
you
know,
cloud
technologies
within
certain
regions,
which
again
pretty
much
boils
down
to
the
reason
that
you
host
your
data.
The
second
point
over
here
is
that
a
shift
towards,
like
you
know
the
traditional
architecture
of
like
you
know
how
you
split
your
teams,
which
is
your
developers.
A
Your
quality
analysts,
you've
got
security
security
analysts
who
define
policies
and
you've
got
like
site
reliability
engineers
who
help
out
with
the
operations.
Now
all.
A
Like
you
know,
from
a
business
angle
that
is
like
you
might
have
a
devops
process
that
is,
like
you
know
in
the
that
is
well
defined,
or
so
you
may
think,
but
the
question
that
we
definitely
should
ask
ourselves
as
a
whole
organization
is
that
is
it
really
delivering
value?
And
by
that
I
mean,
is
the
automation
actually
helping
you
out
by
that
we
mean?
Is
it
repeatable?
Is
it
reusable?
Is
it
scalable?
Is
it
secure
or
and
more
so
after?
A
A
So
again,
the
ways
that
you
might
measure
like
you
know
how
your
deploy
automation
processes
are,
like
you
know,
efficient.
There
are
certain
gaps
like
you
know,
in
terms
of
visibility
like,
for
example,
if
if
an
engineering
manager
would
like
to
identify,
is
it
something
on
the
approval
that's
taking
time
or
is
it
a
build
process
that
needs
to
be
optimized?
A
That
is
where
the
complexity
comes
in,
although
kubernetes
solves
like
one
layer
of
like
orchestration
problems,
but
as
is
always
the
case,
if
you
consider
entropy
of
the
world
or
if
you
consider
physical
concepts,
introducing
a
lack
of
concept,
complexity
in
one
angle
is
always
going
to
generate
complexity
on
the
other
side.
Now
this
complexity
is
being
transferred
to
developers
and
developers
are
not
in
a
position.
A
Not
all
I
mean
there
are
some
really
high
class
developers
who
deal
with
it,
but
the
j.
What
I'm
talking
about
is
a
generic
like
you
know,
organization
or
somewhere,
where
it's
widely
distributed.
Not
everyone
has
visibility
over
all
of
it.
So
visibility
is
a
challenge
like,
for
example.
How
do
you
debug,
like
you
know,
issues
like
you
might
have
logs
from
the
framework
level,
but
what?
If
something
is
going
on
at
the
infra
level?
Do
you
really
want
to
give
like
cube
admin
access
to
those
guys?
Of
course
not?
A
So
you
need
to
be
able
to
like
pretty
much
visualize
all
of
it
in
one
single
platform.
That
is
where
vsdps
come
in
and
help
you
optimize
your
devops
tool
chain.
Like
you
know,
in
terms
of
continuous
delivery,
it
helps
platform
engineers
define
standards
so
that
they
can
pretty
much
optimize
their
time
in
and
efforts
into
developing
something
which
is
automatable
and,
more
importantly,
repeatable
and
scalable.
A
In
the
organizational
context,
and
by
that
I
mean,
like
you
know
from
like
you
know,
scaling
the
organization
like,
let's
say
your
40
developers
now
tomorrow
you
might
be
500
developers.
Who
knows
so.
You
need
to
have
all
of
these
like
moving
parts
in
place
right
before
you
scale.
Otherwise,
once
you
scale
you're
not
going
to
really
see
the
benefits
of,
like
you,
know
your
automation
processes,
and
it
should
not
be
a
single
point
of
contact
who
knows
all
of
it,
it
should
be
standardized
within
a
framework.
A
That
is
why
that
is
where
value
stream
delivery
platforms
come
in
and
really
help
you
scale
your
or
devops
transformation
processes.
With
that,
I
would
like
to
take
a
pause
and
hand
it
over
to
abilish
and
ablaze.
Please
go
ahead
with
your
inputs
and
conclusions,
if
whatever
may
be
in
your
mind
as
well.
C
Yeah
sure,
thanks
thanks
prasanth
and
motives
for
this
webinar,
because
we've
seen
the
term
of
value
stream,
delivery
platform
or
vsdp
come
up
multiple
times
across,
maybe
as
being
created
as
a
separate
category
by
gartner
or
blocks
popping
up
on
the
net,
and
we
just
thought
you
know
through
this
webinar.
C
If
we
can
help
consolidate
all
those
informations
through
this
webinar
and
you
know,
put
forth
also
the
point
that
how
techton
as
a
framework
enables
you
to
you,
know,
reuse
your
pipeline
and
standardize
your
deployments
across
cloud
and
how
a
vsdp
basically
extends
that
capabilities
in
the
form
of
giving
you
an
ui,
giving
you
a
user
interface
that
moti
has
expanded
all
the
capabilities.
That
can
you
know.
You
know
that
you
have
those
capabilities,
we
are
making
it
much
more,
reachable
across
to
the
audience
much
more
accessible.
C
So
you
can
leverage
the
benefits
through
a
vsdp
and,
as
a
name
itself
says,
the
platform
helps
you
map
your
value
stream
across
your
devops
phases.
And
you
know
the
end-to-end
value.
C
Delivery
from
code
to
customers
is
actually
pretty
streamlined
through
vsdtp,
which
the
likes
of
which,
like
ozone
or
jenkins,
x
or
who
or
whatever
platforms,
are
there
or
they
help.
You
deliver
this
value
to
your
end,
customers
so
how
they
do.
It
is
what
we
have
seen
through
this
webinar
and
you
can
have
more
information
on
the
respective
tools
websites
or
there
are
many.
We
hope
that
the
category
of
vsdp
comes
up
soon
on
gartner
and
the
vendors
who
are
listed
on
the
magic
quadrant.
C
A
Thank
you,
everyone
for
joining
us
on
this
webinar
and
if.