►
From YouTube: CDF Meetup 11-10-20 Butter knifes to Samurai Sword, elevating Developers to Ninja software Warriors
Description
Learn how to educate, inspire and transform a large organization to become true Ninja software warriors where DevOps and Continuous Delivery becomes the kata of success. Presented by Gurushyam Mony https://www.linkedin.com/in/gurushyam-mony-4176123/
A
Thank
you,
everybody
for
attending
today's
cd
foundation
online
meetup.
We
have
a
very
interesting
presenter
today,
guru
mani.
He
is
the
director
of
devops
and
quality
engineering
at
markel
insurance
he's
going
to
have
some
very
strong
insights
in
terms
of
what's
needed
from
the
perspective
of
fintech
and
he's
really
going
to
talk
about
people
and
process.
Today,
we
I
think
we
oftentimes
forget
how
important
that
is
in
our
journey
in
devops
and
learning
more
about
devops
and
we
get
focused
on
the
tools.
A
So
I
tried
to
kind
of
coordinate
these
these
meetups
with
both
the
human
factor,
cultural
factors
as
well
as
tools
factors.
Now,
as
we
know
last
week
last
month
we
did
argo
cd,
so
this
this
month
we're
doing
butter.
Knives
practitioners
to
ninja
warriors
transforming
your
i2
workforce
towards
a
devops
mentality,
just
a
few
housekeeping
things
as
people
are
coming
on.
A
B
Thank
you
tracy.
Thank
you,
everyone
for
your
time
as
well.
I'm
hoping
for
this
conversation
to
be
a
very
philosophical
and
a
mind-opening
talk
for
us,
devops
engineers
and
developers
at
heart.
Before
I
move
forward,
I
wanted
to
actually
call
out
a
big
shout
out
to
tracy
and
folks
from
the
deploy
hub.
B
So
a
couple
of
months
back,
I
think
I
had
a
talk
and
you
know
wanted
to
actually
share
an
idea
of
this
butter
knife
practitioners
to
ninja
warriors.
It
literally
is
a
foundation
key
towards
transforming
some
of
your
I.t
workforce,
as
you
think
about
digital
transformation
into
a
devops
mentality
and
devops,
as
a
pattern
itself
has
taken
such
a
buzzword
in
the
last
couple
of
years,
and
every
industry
and
every
domain
and
every
organization
in
the
fortune
500
as
well
as
startups,
want
to
drink
that
kool-aid.
B
So
this
today
is
a
reflection
of
the
lessons
learned
and
the
continuous
lessons
we
are
learning
so
without
further
ado
I'll,
just
quickly
go
move
forward
opening
note
on
how
we
want
to
interact
I'm
open
to
having
an
interactive
session.
So
just
stop
me,
and
we
can,
you
know,
go
through
questions
if,
as
I
go
through
the
content,
I'll
go
into
a
quick
glimpse
about
me
and
my
dojos
is
what
I'm
gonna
actually
introduce
as
a
first
concept,
which
is
a
learning
area
from
the
martial
arts
terminology.
B
My
team
myself
improve
some
culture
and
and
the
turnkey
of
people
from
from
one
state
to
the
other
and
improving
the
devops
performance,
and
I'm
going
to
reflect
on
that
and
some
anti-patterns
and
and
lessons
learned
so
I'll
quickly
go
into
me
myself
and
career
initial
sort
of
a
conversation.
It's
very
simple.
I
am
a
very
simple
person
in
terms
of
not
having
too
much
on
my
personal
side.
You'll
see
that
I
have
been
practicing
martial
arts
for
about
13
years
now.
I
have
yet
not
become
a
sensei
yet
or
a
black
belt.
B
I'm
brown
bulb
working
towards
getting
my
black
person.
I
play
a
lot
of
tennis
and
I
have
been
playing
tennis
since
I
was
five.
I
play
really
good
and
I
also
host
a
large
league
here
in
richmond-
that's
that
has
over
350
participants
each
summer
and
spring.
So
I
really
love
the
game
and
I
also
run
a
spring
league
if
you
are
in
the
richmond
area
and
want
to
play
some
tennis
just
give
me
a
tax.
B
I
also
love
hiking
in
the
beach,
which
is
why
I
thought
I'll
put
a
small
picture.
That
is
not
my
family,
but
I
do
have
a
wife
and
two
children,
girls,
jill,
aryana
and
shyla
and
on
the
right
hand,
side.
I
started
to
actually
put
out
a
diagram
of
you
know
for
the
new
perspective,
martial
arts
with
the
hard
and
soft
styles
test
driven
development
has
really
carried
me
a
lot
in
the
last
decade.
B
So
I
thought
of
actually
reflecting
my
journey
in
terms
of
just
a
martial
arts
practitioner
going
from
a
white
belt
to
green
belt
brown
belt
and
then
finally,
to
black
belt,
and
I
I
started
categorizing
my
own
improvement
in
the
tech
industry
and
and
I
laid
out
what
I
was
able
to
accomplish
and
learn
from
from
my
career
itself
started
off.
As
a
software
engineer,
and
a
networking
engineer
at
a
farm
in
dc
did
a
lot
of
software
development
and
network
testing
network
automation.
B
On
top
of
all
of
the
features
that
come
out
lean
engineering
was
something
I
was
introduced
through
part
of
a
small
team
that
I
worked
with
for
the
nhtsa
national
highway
transportation
safety
authority
in
conjunction
with
department
of
motor
vehicle,
and
we
were
a
team
of
ten
learned,
a
ton
from
all
those
great
software
developers
and
engineers
and
then
15
to
20.
I
started
moving
out
from
hands-on
keyboard
to
be
more
of
an
enterprise
transformation.
B
Large
divisional
changes
from
older
practices
through
to
agile,
devops
mentality,
starting
getting
started
with
you
know
everything
as
code
and
infrastructure.
As
code
configuration
is
code
into
githubs
a
bit
and-
and
I
went
through
a
lot
of
data,
ops,
engineering
for
deployments
of
databases
and
large-scale
transactional
systems
that
were
that
are
heavily
manual
and
got
my
forte
into
that,
and
I
and
I
started
putting
the
slide
through.
I
realized
that
you
know
a
typical
brown
belt
at
that
point
before
they
get
a
mastery
towards
the
black
belt.
You
sort
of
get
this
epiphany.
B
Maybe
you
know
it
was
just
timing
that
my
epiphany
on
the
I.t
industry
and
the
martial
arts
sort
of
kind
of
blended
together.
So
today,
I'm
here
humbled
by
the
fact
that
I
am
actually
improving
in
my
I.t
career
and
my
journey
solely
through
learning
by
teaching
and
teaching
by
learning,
and
today
it's
a
reflection
of
the
aha
moments
that
I
have
gotten
through
the
work
I've
done
with
all
of
these
agencies
and
organizations.
B
So
my
dojo
is
at
a
glance.
My
learning
petri
dishes
is
what
I
call
it
several
years.
I
was
part
of
the
dmv
nhdsa
threads
project.
It
landed
itself
in
the
white
house
for
a
presidential
award
to
transform
a
largely
monolithic,
mainframe
based
systems
that
were
manual
processes
all
over
to
a
fully
automated
deployed.
Modern
stack
with
data
intelligence,
transactional
systems,
360
24,
7,
uptimes,
scalability,
the
full
caboodle
and
we
ended
up
taking
virginia
from
rank
48
to
2.
B
learned
a
lot
from
that
team,
and
then
I
briefly
had
an
opportunity
to
you
know:
consult
and
contract
with
capital
one.
I
was
involved
in
an
enablement
move
in
virginia
tax
for
a
transformation
into
digital
practices
in
devops
and
the
last
three
years
I
have
been
with
markelle,
I
joined
markle
in
august
2017
to
lead
the
configuration
management
practices
in
quality
engineering
and
within
two
years.
B
I
skipped
a
lot
of
what
happened
in
the
other
organizations
and
wanted
to
just
give
a
little
glimpse
of
this.
When
I
started
markell,
we
were
largely
built
to
deploy
all
segregated
out
mostly
manual
bills.
Were
automated
testing
and
deployments
were
not
monitoring
was
again
through
ticketing
systems
like
we
love
through
servicenow
and
to
get
you
know,
your
tight
reliability
matrices.
All
of
that
fun
goodies
were
all
part
of
the
initial
assessment
of
where
markle
started,
and
this
particular
slide
is
an
except
from
one
of
the
skinny
leadership.
B
The
bigger
callout
was
also
integrating
quality
engineering,
matrices
and
and
reliability
into
these
deployment
patterns,
and
we
managed
to
actually
year
around
here,
increase
the
overall
usage
of
your
test
pipelines
and
deployment
pipelines
within
your
bills
to
grow
up
skyrocketingly
a
higher
level,
and
we
did
not
achieve
this
as
just
a
small
team.
It
was.
It
was
an
entire
enterprise
effort
and
I'm
going
to
move
slowly
into
how
culturally
we
were
able
to
achieve
that
success.
B
My
team
today
manages
725
gig
repositories
that
are
scattered
around
100
or
so
active
projects
that
are
under
build
test,
deploy
many
or
if
not.
Most
of
them
are
sox,
controlled
applications
for
the
fintech
industry,
and
we
also
maintained
jira
and
confluence,
integrations
with
about
496
active
projects
that
are
aiding
in
the
agile
transformation.
B
So
this
is
a
little
view
of
the
growth
that
we
were
able
to
do.
Partnering
with
so
many
abduv
teams.
The
names
on
these
slides
through
the
journey
from
2019
18
through
to
20..
You
get
to
see
policy
upload.
You
know
there
are
so
many
terminologies
up
there
that
talk
about
how
many
build
increases
that
the
team
was
able
to
work
together
with
the
teams
increase.
We
have
forms
automation,
e2,
property,
ghostcraft.
All
these
names
are
internal
socks,
compliant
applications
and
and
platforms
that
support
our
insurance
industry.
B
Markle
ensures
a
lot
of
specialty
products.
We
are
not
your
mainstream
home
and
health
insurance.
We
ensure
resources,
hospitals,
general
liabilities,
cyber.
If
you
have
a
million
dollar,
you
know
shoe
that
you
want
to
ensure
you
know
we
do
that
race,
cars
and
mt
cars,
so
these
application
sets
that
I'm
talking
about
are
all
very
unique
in
terms
of
their
ability
to
rate
quote
and
bind
niche
products
for
our
business
users.
B
There
are
slight
nuances
in
in
in
how
these
app
dev
teams
improved
in
their
maturity
and
it's
again
a
true
reflection
of
a
bottom-up
or
organic
growth,
where
your
your
bills
start
to
increase
chiropractically
high,
you
start
to
get
a
funnel
where
your
tests
and
deployments
and
reliability
on
your
deployment
starts
to
decrease,
and
you
carefully
then
start
to
move
the
needle
upon
your
tests
and
deployment
practices.
We
are
not
there
in
the
end.
B
B
So
that
just
gives
a
view
of
our
two
and
a
half
year
journey
into
a
fintech
company.
As
a
central
devops
team
on
the
bottom,
we
started
off
in
mid
2018,
asking
for
a
1.2
million
dollar
funding
to
create
a
central
team
that
would
then
enable
others
in
markel,
and
I
had
the
opportunity
to
work
with
four
solutions:
architects,
considering
the
best
and
also
another
devops
team.
B
That
today
is
all
one
team
together
of
14
people
organically
saw
our
central
teams,
growth
from
a
1.2
million
dollar
yearly
program
to
a
2.3
million
dollar
program.
Today,
mostly
income
encompassing
a
few
solutions,
architect
and
60
junior
engineers,
out
of
college,
that
we
hire
train
and
then
bring
them
into
a
devops
mentality.
To
then
help
the
app
dev
teams.
B
We
are
a
fintech
company
that
also
has
a
lot
of
vendor
management
in-house,
namely
few
we
have
accenture
ibm
infosys
tcs.
We
have
a
lot
of
these
vendor
partners
who
help
us
in
in
bringing
it
to
the
business.
I've
missed
a
lot
of
names,
but
now
we
have
a
ton
of
our
vendors
who
help
with
the
associates
in-house
as
well
in
in
transforming
rit
over.
B
Very
good
question
so
to
to
avoid
the
the
aspect
of
resistance.
Initially,
we
started
off
organically
from
a
bottom-up
approach
purely
for
68
months.
We
said
this
would
be
a
bottom-up
approach,
where
we
showcase
specific
features
and
tools
to
help
the
abducting.
We
brought
two
teams
in
the
mix
and
showed
them
how
dot-net
core
and
framework
would
be
built
and
deployed
that
caused
an
interest
in
them.
They
said
hey.
Could
we
work
together,
floated
out
that
feature
they
were
happy
soon.
They
were
starting
to.
B
B
We
we
went
for
a
year
creating
a
gigabyte
of
shared
library
repositories
and
there
were
teams
that
did
give
resistance,
but
largely
they
were
overcome
by
the
culture
of
wanting
to
help
and
providing
a
workable
solution
back
to
that
team
versus
actually
asking
the
team
to
do
it
as
a
practice,
so
the
first
eight
months,
barriers
to
penetrating
those
pushbacks
where
us
having
to
actually
show
them
the
practice.
Do
it
for
them
and
helping
them
out
which
created
a
sense
of
trust?
B
So
our
crux
of
the
discussion
today
I
mean
that
that
tooling
there
and
the
increases
in
the
practices
are
one
thing
as
an
outcome,
but
what
they
don't
shed
behind.
The
curtains
is
what
actually
fostered
that
culture
and
what
actually
fostered
that
growth,
and
I
wanted
to
draw
some
parallels
between
the
martial
arts
that
I
am
practicing
every
day
to
the
it
industry
and
actually
thanks
to
tracy
for
putting
the
the
ninja
warrior
image
here.
B
I
wanted
to
actually
talk
about.
How
do
you
take
a
white
belt
person
who
wants
to
learn
martial
arts
as
an
art,
purely
with
the
analogy
given
to
software
development,
and
how
do
you
ensure
that
that
martial
artist
succeeds
in
transforming
themselves
and
learning
to
become
a
ninja
warrior
or
a
sensei
who
can
actually
use
instruments
or
tools
and
be
very
proficient
in
that
and
continue
their
journey
of
learning?
And
it's
not
easy
said
or
done,
and
it's
not
that
we
have
mastered
it.
B
We
are
here
with
still
so
much
to
learn
and
I
can't
say
we
have
conquered
the
problem
for
sure,
but
key
three
recipes
that
I
wanted
to
call
out
was
something
that
has
stayed
in
my
mind
through
my
sensei,
who
has
taught
me
for
a
while,
and
that
is
the
first
one
so
I'll
go
into
this,
and
I'm
going
to
assume
that
the
audience
largely
has
fairly
minimal
knowledge
of
terminologies
from
the
martial
arts.
So
there
is
a
terminology
called
taikiyoku
or
taiji.
I
mean
I
think
it's
the.
B
The
crux
of
the
whole
thing
is:
it
is
an
abstracted
principle
or
a
simplified
principles
of
the
prince,
complex
principles
and
patterns
that
you
want
to
imbibe
in
your
daily
work
and
your
daily
efforts
in
the
martial
arts
world.
They
call
this
particular
event
as
the
first
cause,
and
this
is
something
that
you
get
trained
on
on
every
class
and
is
also
tested.
B
B
These
are,
they
are
specific
practice
routines
that
have
been
orchestrated
in
a
way
that
would
allow
for
you
to
repeat-
and
as
you
repeat
them,
these
routines
become
your
some
things
that
your
app
dev
teams
would
do
on
their
sleep
or
would
become
a
mastery
over
time,
and
it
becomes
part
of
your
day-to-day
work
and
daily
job.
But
just
practicing
those
routines
saying,
hey,
everybody
has
to
be
doing
at
least
one
check-in
or
a
one
build
a
day
doesn't
mean
that
you're
going
to
get
there.
B
You
want
to
also
have
a
a
recipe
of
performing
and
evaluating
and
assessing
where
you
stand
and
where
your
team
stands
and
where
your
division
stands
on
a
weekly
basis
daily
basis,
because
that's
important
as
well,
so
that
particular
evaluation
on
the
martial
arts
calls
for
have.
You
performed
cutter
one
cutter
two
and
it
goes
on
and
builds
on
to
a
point
where
you
go
into
advanced
patterns
and
practices
such
as
phenons
and
stuff.
B
If
I
were
to
take
that
onto
the
devops
world
before
a
person
starts
to
go
gun
hoe
into
how
do
I
do
modern
microservices
deployment?
There
is
some
level
of
maturity
and
and
growth
and
respect
to
the
knowledge
of
fundamental
foundations
such
as
configuration
management,
fundamental
practices
such
as
functions
and
infrastructure,
as
code
and
and
these
patterns
have
to
be
at
a
stable
level
and
and
maturity
before
you
can
start
to
see
your
measured
growth
and
and
measured
stage
improvement
in
your
devops
journey.
B
Everyday
cycles
are
important,
so
as
leaders
as
well
as
as
team
members
of
each
team,
you
want
to
give
yourself
the
time
to
do
that
on
an
everyday
basis,
and
if
you
do
this
on
an
everyday
basis,
your
techniques
refines
and,
finally
your
art
refines.
I
reflect
back
on
2018
december,
where
the
devops
team,
that
I
you
know
I
I
I'm
part
of
and
leading
we
had
about-
maybe
10
or
12
bills
in
three
or
four
days,
new
team
lot
of
new
folks
coming
in.
B
They
were
looking
at
how
to
work
with
each
other
and
so
on
and
so
forth.
And
if
I
look
at
what
has
happened
today,
we
pump
out
at
least
three
or
four
code
bills
every
every
once
in
two
hours
at
least,
there
are
a
couple
of
change
requests
going
out
to
you
know
your
production
and
that
did
not
happen
magically
or
by
hiring.
Just
a
few
folks
and
saying
you
know,
thou
shall
do
it.
B
It
comes
with
everyday
cycles
of
having
time
to
practice
those
forms
and
and
giving
the
the
the
time
to
reflect
back
on
it
and
refine
it
recipe
number
three
now
this
is
something
that
is
more
on
the
philosophical
lines.
A
couple
of
martial
arts
disciplines
do
this.
They
say
that
before
you
get
to
a
mastery
in
an
art
level,
you
have
to
cross
the
bridge
of
a
senpai.
B
So
let's
take
an
example
of
this
and
I'll
go
into
what
the
definition
of
senpai
and
okay
in
this
context
is
so
yeah.
So
you
got
a
devops
team.
You
you
know,
you've
invested
you've
got
the
buy-in
from
the
top-down
or
your
leaders.
You
start
a
team
you're
ready
to
influence
you
all
of
that
is
going
through,
and
you
have
a
lot
of
engineers
in
maybe
a
central
devops
team
or
your
app
dev
team,
that
practices
pretty
well
and
they
they
they're
pretty
good
in
in
in
the
art
of
software
development.
B
B
B
We
said,
let's
start
doing,
coes
and
c4es
and
weekly
dojo
sessions
with
app
dev
teams,
partly
not
to
teach
them
how
davox
is
done,
partly
to
learn
how
they
do
active
cycles
and
to
learn
from
them
and
as
we
were
teaching
devops
practices
and
how
to
actually
bolt
on
automation
to
the
app
dev
community,
we
learned
a
ton
and
we
started
to
go
wow.
You
know
this
team
has
dot-net
core,
which
is
very
different
from
a
document
framework
team
b
now
is
different.
B
Without
this
cycle
being
demonstrated
with
success,
they
do
not
allow
certain
art
arts
do
not
allow
that
brown
belt
to
go
from
a
senpai
stage
to
a
sensei
which
is
a
black
belt,
and
I
think
I
would
agree
with
that.
You
know
getting
that
epiphany
from
from
that
artist,
that
art
to
the
I.t
industry,
so
I'll
stop
right
there
and
talk
about
the
crux
any
questions
so
far
on
the
three
recipes
that
I
have
gone
through.
A
A
B
B
If
there
is
a
demonstrable
example
in
one
team
whereby
you
can
show
hey
look
at
this,
we
have
about
80
repos
that
we
maintain
and
we
have
about
60
check-ins
that
have
gone
in
with
pull
requests
off.
This
only
10
are
actually
good.
The
others
have
all
failed,
which
is
okay,
but
what
we
want
to
do
is
to
see
those
failures
slowly
reduce
next
time
and
help
these
team
members
get
past.
That
hump
show
by
example,
has
been
a
technique
that
I
have
used.
B
I'm
not
saying
that's
the
only
recipe
of
success,
but
it
has
to
start
somewhere.
Someone
has
to
demonstrate
that
and
be
able
to
say
we
can
fall
down
and
we
will
help
you
when
you
fall
down
and
collectively
we
will
learn
as
well
as
someone
falls
down.
Both
the
person
who
is
actually
demonstrating
the
technique
also
has
something
there
to
learn.
Can
you
let
them
fall
soft?
B
B
These
three
aspects
of
open,
mind,
hearts
and
arms
resonate
to
me
a
lot,
and
I
try
to
show
that,
by
example,
to
my
upper
management
and
to
the
team
that
I
that
I
manage
and
quite
frankly
and
honestly,
that
attitude
has
actually
helped
me
learn
a
lot
today.
More
so
than
than
being
a
leader.
I
have
been
actually
quite
a
quite
frankly.
The
last
three
years
has
been
a
whiteboard
journey
for
me.
B
So
this
this
transformation
culturally,
has
to
happen
within
each
team
within
each
person,
and
this
is
not
something
that
visually
or
granted
somebody
from
top
down
can
pass
and
say
all
right
from
tomorrow.
We
are
all
going
to
have
open
minds
and
hearts
and
everybody
who's
from
solutions.
Architects
to
tech
leads,
are
going
to
go
and
and
teach
and
train
and
they're
going
to
actually
get
everybody
towards
one
level
of
maturity.
It
doesn't
happen
that
way,
demonstrating
a
culture
of
continuous
improvement
from
a
small
area
and
then
just
permeating.
B
That
is
the
only
way
of
true
success,
by
example,
some
anti
patterns.
So
now,
let's
talk
about
some
key
anti
patterns
that
at
least
are
followed
on
the
dojo
that
are
relevant
to
the
I.t
industry
as
well:
disregard
for
health
and
wellness
of
your
dojo,
as
well
as
people
limitojo.
What
that
means
is
you
don't
want
to
practice
something
until
a
point
where
your
bones
are
broken
and
you're
out
of
commission
for
like
a
year.
You
want
to
know
your
your
strengths.
B
Where
I
go
about
doing
this,
this
sort
of
a
statement
resonates
is
when
you
have
a
dojo
that
has
a
mix
of
four
black
belts:
seven
green
bells
and,
let's
say
20
white
bells,
and
you
can
compare
and
contrast
that
to
a
dojo
that
has
like
17
black
belts,
a
few
brown
bells
and
maybe
five
white
balls.
The
dynamics
is
going
to
be
very
different,
and
the
approach
that
you
take
is
also
going
to
be
very
different
at
the
end
of
the
day.
B
One
has
to
consider
that
when
they
make
a
top-down
push
on
certain
changes
in
in
the
devops
practices,
I'll
give
you
an
example
we,
as
in
in
markel,
we
we've
been
from
a
a
huge
face
where
we
made
changes
to
who
our
vendor
partners
were.
For
the
cloud
we
had
ibm,
we
had
microsoft
azure
that
cost
a
lot
of
dip.
B
So
it's
very
important
for
a
large
organization
or
a
medium
organization
to
think
about
everyone
in
the
dojo,
including
your
vendors,
your
associates
and
your
customers,
all
in
one
unison,
to
think
about
what
measures
or
changes
you
do
from
the
top.
That
could
actually
help
in
your
change
transformation
versus
the
other
way,
lack
of
a
discipline
and
humility
and
self-control.
This
is
not
just
from
the
sensei
senpai
or
uk
perspective
or
a
top-down
leader
perspective,
but
this
also
goes
from
a
bottom-up
perspective.
B
You
want
to
actually
foster
a
culture,
and
you
want
to
actually
look
at
hiring
and
look
at
new
associates
coming
in.
Who
would
actually
help
with
this
discipline
would
help
would
have
the
self-control
to
practice
it
and
if
they
don't,
there
is
some
level
of
teaching
and
some
level
of
mentoring.
That
needs
to
be
given
back
to
the
community
to
then
take
this
forward.
Otherwise,
what
happens?
B
Innovation
is
something
that
I
have
seen
so
many
people
start
to
use
and
say:
hey
yeah.
We
need
to
innovate,
we
will
time
box
innovation
or
we
will
give
some
time
period
in
each
of
the
iterations
in
agile,
to
say
the
team
shall
have
15
to
20
efforts
on
innovation
and
so
on
and
so
forth.
Here
is
my
personal
take
on
it,
and
this
is
the
philosophical
take
if
I
have
to
innovate
in
the
martial
arts
that
I
learned
for
the
last
11
years
and
I
want
to
innovate
on
a
technique.
B
That's
like
a
block
or
something
I
have
to
have
had
a
mastery
to
a
certain
extent.
I
have
to
have
practiced
it
so
much
that
my
mind
starts
to
go
how
about
if
I
change
this
pattern,
a
bit
how
about,
if
I
include
this
extra
movement
into
this
particular
practice
that
I've
been
doing
for
a
long
time.
That
is
the
only
key
to
innovation
and
experimentation.
B
Very
good
question:
so
far
we
have
been
90
consumers
of
the
open
source
world
and
we
have
changed
the
the
culture
from
largely
microsoft
products
through
to
open
source
culture.
Our
next
journey,
hopefully,
as
we
mature
out
through
to
that
blackwell
journey,
is
to
have
contributions
coming
back
from
the
team
so
to
foster
that
practice.
B
We
hope
that
in
the
near
future,
we
open
that
out
to
the
real
world
as
well,
where,
if
we
get
let's
say
a
stocks,
compliant
report
feature
going
out
for
test
pipelines,
something
that
can
be
given
to
other
sox
compliant
organizations
that
use
open
source
tool
to
actually
level
those
features.
We
are
not
there
yet.
B
From
a
fostering
the
open
source
mentality,
we
have
put
in
tools
to
let
our
security
folks
be
able
to
have
a
unique
pattern
of
bringing
it
in
cleansing
it.
Looking
at
what
is
needed
and
my
team
acts
as
a
conduit
for
bringing
those
in
for
app
dev
teams,
and
we
hope
that
in
the
future
we
turn
key
and
start
to
see.
Contributions
from
within
market
lab
drive
teams
to
the
outside
world.
B
All
right
so
life
lessons
that
at
least
I
have
started
to
get
an
epiphany
on
and
I
feel
is
applicable
to
the
I.t
industry.
Is
it
can
be
categorized
into
three
segments?
One?
Is
you
want
your
top
leadership
all
the
way
from
the
top
to
the
bottom,
east
and
west,
north
and
south
to
slowly
start
to
think
about
themselves
as
white
belts
or
okay,
which
internally
means
you're
there
to
learn
and
you're
there
to
have
a
learning
mentality
and
that
actually
fosters
a
better
culture
of
safety?
B
B
Every
person
in
every
team
has
to
be
slowly
transformed
to
that
culture
of
practice
and
giving
back
at
the
same
time,
one
major
retrospect
that
we
had
as
a
in
in
my
own
team
a
year
back,
was:
when
do
we
start
practicing,
and
when
do
we
start
teaching
right
there
is
this
fear
that
people
start
to
say
sure
you
know
I
practice
building
deployments
each
time.
I
make
a
slight
change
and
I
practice
test-driven
development
and
I
push
out
only
well-tested
code.
B
And
when
that
happens,
it
truly
drives
a
culture
or
truly
changes
your
mind
to
start
being
a
servant,
leadership
and,
and-
and
you
start
to
think
about
change
being
driven
at
all
levels,
all
the
way
from
top
down
all
the
way
from
even
junior
engineers
from
each
team
to
the
other.
Somebody
is
saying:
hey:
have
you
checked
out
this
azure
cli?
That
now
has
a
new
feature
where,
if
you
combine
that
with
terraform-
oh,
my
god,
you
can
do
so
much
goodies
or
vice
versa.
B
Hey
look
check
out
this
cool
way
that
I
have
wrapped
up.
Containers
and
I've
actually
had
versioning
semantic
versioning
applied
onto
the
docker
images,
and
you
want
those
sort
of
stuff
to
be
taught
between
teams
and
not
just
say
hey.
This
is
going
to
be
one
team
or
the
other
and
that
truly
changes
everyone
in
your
organization,
it
flattens
the
level
out
and
it
and
it
calls
for
a
culture
of
servant.
Servant
leadership
is
wrong.
B
Word
servant,
teacher
and
servant
mentor
and
servant
student,
which
gets
your
organization
at
a
at
a
very
high
satisfaction
rate
and
as
culture
improves.
I
believe
that
your
performance
improves.
I
also
feel
like
your
predictability
of
great
changes
and
features
out
will
improve
as
well
questions
here.
B
So
what
I
wanted
to
actually
do
before
I
take
more
questions
and
and
walk
through
some
of
the
other
deck
if
needed
is
a
big
shout
out,
and
thanks
to
all
my
dojos
that
have
given
me
a
learning
opportunity
to
to
come
in,
learn
and
also
teach
and
and
and
get
better
as
a
person
as
an
engineer
as
an
as
a
developer,
and
I
also
want
to
thank
my
team,
who
has
been
my
true
sensei
in
all
of
this.
So
with
that
I'll,
stop
and
take
some
questions.
A
B
So
I'll
go
back
to
this
slide
here
we
started
this
technique
of
everything
is
code,
so
we
figured
out
that
largely
up
until
uat
environment,
everything
things
were
automated,
but
then
uat
and
broad.
There
were
cycles
of
two
weeks
of
manual
testing
and
there
was
this
black
box
of
I
we
don't
know
quite
what
is
tested
and
and
and
we're
not
sure
and
the
business
unit
does
it.
So
what
we
did
was
we
took
a
chapter
out
of
the
everything
is
code
and
we
completely
consolidated
test
rail
quality
center.
B
We
had
hank
as
another
tool
all
the
paid
test
management
tools
out
and
we
want.
We
asked
all
of
the
manual
testing
teams
and
app
dev
teams
who
do
analysts,
who
do
manual,
testing
and
uat
users
who
do
manual
testing
to
start
storing
their
scenarios
in
git,
so
that
was
our
first
forte
into
understanding.
B
What
does
a
team
do
in
terms
of
manual
testing?
It
was
also
helpful
in
actually
getting
them
to
have
the
scenarios
documented
in
in
git,
which
then
we
were
able
to
then
go.
These
scenarios
could
easily
be
automated.
Let's
get
your
framework
to
start.
Turning
these
scenarios
into
an
automated
way,
so
we
have
pipelines
today
in
our
jenkins
form
that
allows
for
a
team
to
start
from
the
basic
foundation
of
manual
testing
and
we
don't
force
them
to
do
automated.
You
know
testing
right
from
day
one.
B
We
start
to
interface
with
them
and
say
this
is
a
pipeline.
But
if
you
start
checking
this
test
scenarios
along
with
your
code
repository
in
this
sort
of
a
fixture,
we
would
allow,
we
would
be
able
to
let
you
take
the
goodies
of
running
a
manual
pipeline
that
would
run
and
export
out
results
and
get
you
a
pdf.
That
says
here
is
all
the
test
results
and
pass
and
fail
what
it
gives
us
an
insight.
Is
traceability
and
also
encapsulating
all
your
test
engineering
efforts,
along
with
your
build
and
deployment
code
base.
B
So
that's
your
first
step,
so
we
started
doing
that
about
a
year
and
a
half
back
and
as
and
when
we
saw
more
and
more
scenarios
in
the
annual
repository
beings
added.
We
started
to
interface
and
start
start
to
give
them
frameworks
in
various
languages,
mostly
bdd
languages,
to
get
them
into
an
automated
way.
We
have
pester
spec
flow,
cucumber,
cucumber
node.js,
cucumber
java,
cucumber
ruby.
B
Terra
test,
all
these
bdd
frameworks
are
today
active
and
in
use
in
market
in
various
stages
of
their
maturity.
The
production
tests
were
highly
manual
as
the
next
stage
we
started
to
introduce
api
one
api
test
today
in
production,
will
keep
your
app
health
pretty
well
and
your
doctor
away
sort
of
a
principle.
So
we
went
through
with
that
schema
and
that
program
and
we
started
to
encourage
teams
to
have
at
least
one
test
of
their
api
in
fraud.
That
would
not
do
any
data
manipulation,
but
just
check
their
site.
B
Reliability
matrices
on
their
apis.
So,
as
the
team
start
started
to
actually
have
one
repeatable
test
in
their
production,
they
start
to
want
more
and
that
drove
an
explosion
of
their
tests
all
the
way
from
broad
through
the
lower
environments
as
well.
It
wasn't
a
simple
you
know
two
week
or
a
two
month
activity
we
had
to
slowly
nudge
them
along
their
way
from
a
manual
pattern
to
through
to
an
automated
approach.
We
use
tags
in
our
pipelines.
B
We
let
the
teams
tag
scenarios
for
layers,
so
a
typical
look
at
git
repository
in
markle
on
teams
that
follow.
It
will
see
scenarios
stacked
us
at
qa,
preprod
prod,
and
we
use
those
tags
checked
in
to
get
to
basically
say
these
test
scenarios
need
to
be
orchestrated
in
these
environments
and
that's
largely
the
same
process.
Even
in
the
manual
testing
side.
B
We
let
them
decorate
in
git
tags
and
let
them
control
the
pipelines,
thereby
they
get
used
to
a
continuous
integration
technique,
even
though
they
are
actually
going
in
and
and
saving
and
editing
scenarios
and
git.
It
also
gives
them
a
practice
and
of
repeating
git
and
slowly
getting
them
into
into
that
pattern.
As
well
good
question.
A
A
And
everybody
I
will
be-
this
will
be
recorded.
This
has
been
recorded.
I
will
be
putting
it
up
in
the
cd
foundation's
online
meetup,
so
you
can
use
it
and
share
it
with
your
your
teams
there
and
we
will
see
everybody.
I
I
don't
think
we
have
one
scheduled
for
december.
I
may
be
wrong,
but
we
do
have
wednesday
as
scheduled
for
january,
and
it
is
going
to
be
on
the
agile
mindset.
So
it's
a
good
follow-up
actually
to
this
presentation.