►
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
A
C
D
E
C
Yeah
avik
and
darwin,
we
can
both
test
out
your
slides
now,
just
to
make
sure
yeah.
B
Trying
to
activate
my
permission
on
the
systems
to
allow
zoom
to.
A
G
B
D
C
You
know
there
you
go
okay,
cool,
so
are
there
any
any
questions
before
we
get
started.
C
C
C
C
C
E
E
Well,
I
think
it
was.
It's
been
running
about
112
to
115,
but
today
it's
a
little
cooler,
it's
probably
about
108.
that
doesn't
sound
too
bad
at
all.
D
E
E
It's
just
amazing,
I'm
from
atlanta,
so
I'm
used
to
you,
know
95
degrees,
humidity,
95
degrees
and
95
humidity,
and
I
used
to
think
the
whole
dry
heat
thing
was
bogus,
but
I've
become
a
believer.
I've
been
out
here
for
about
three
years
now
and
and
I
it
does
have
merit
now
when
it
gets
to
115,
it's
still
115..
I
don't
care
what
anybody
says.
A
C
D
K
J
A
J
J
A
town
in
colorado,
I
think
it
was
yesterday
simultaneously
set
their
highest
temperature
record
for
that
day
of
the
year
and
their
lowest
within,
like
11
11
hours
of
each
other.
It
went
from
like
37
degrees
and
then
the
temperature
rose
55
degrees
over
the
course
between
4
a.m
and
like
3
in
the
afternoon
or
something
wow.
A
C
All
right
so
we're
gonna
we'll
get
started,
and
we
have
a
a
great
program
coming
up
great
peers,
great
executives,
joining
us
I'll,
introduce
myself
to
start.
My
name
is
dan
jennings.
I
oversee
the
cio
and
cso
portfolio
here
at
apex
assembly
so
again
on
behalf
of
apex
and
the
get
lab
team
would
like
to
thank
you
all
for
joining
us
today
and
taking
time
out
of
your
day
to
participate
from
apex.
C
Also,
we
have
my
colleague
alejandro
mortezini
that
oversees
all
the
content
and
direction
of
a
lot
of
our
programs
here
across
the
portfolio
as
well.
We
also
have
the
the
get
lab
team
and
we'll
have
everyone
introduce
themselves
as
well
as
we,
and
we
also
have
speaking
today
with
the
get
lag
team,
avik
ganguly
from
the
london
stock
exchange.
So
we
are
definitely
excited
about
today's
program.
This
again,
this
session
is
meant
to
be
as
interactive
as
possible,
so
it's
so
good
to
see
everyone's
faces
on
the
cameras.
C
I
know
john,
your
camera
isn't
working,
but
that's
all
good
definitely
participate,
use
the
chat,
feature
and
or
speak
up
whenever
you
like.
We
encourage
asking
questions
and
again
to
make
this
sort
of
program
as
interactive
as
possible,
just
because
virtual
doesn't
mean
that
we
can
all
collaborate
together.
So
definitely
looking
forward
to
to
that
program.
We're
just
gonna
start
here,
the
basically
the
the
details
for
today
and
today's
session.
C
The
agenda
will
be
some
introductions
here,
I'm
going
to
go
through
the
registration
list
so
that
everyone
knows
where
everyone's
from
all
your
peers
and
then
we
will
get
in
to
the
presentation
by
avik
and
then
a
another
presentation
by
git
lab.
Like
I
said
like
I
mentioned,
please
do
ask
questions
throughout
and
hopefully
we
can
make
this
as
an
interactive
decision
as
possible.
I
know
that
everyone's
excited,
both
speakers
are
excited,
and
I
hope
everyone
here
is.
You
know
looking
forward
to
learning
and
educating
yourself.
C
So
with
that
being
said,
bear
with
me.
We
have
about
20
peers
that
are
going
to
be
joining
in
total
looks
like
we
have
one
more
that
we're
admitting
here
so,
like
I
said
peers
from
across
all
industry
industry
verticals.
So
it's
always
an
interesting
conversation
to
see
you
know
what
what
peers
are
doing.
C
In
other
industries
to
to
learn
from
one
another
so,
like
I
mentioned
from
london
stock
exchange
bill
randall
from
marathon
petroleum,
brian
rhodes,
from
compassion
international
colin
mariner
from
homeadvisor.com
dave
petticolas
from
myriad
genetics,
dwayne
winkle
for
public
services,
jeremy
cunningham
from
corn,
ferry
john
lynn's,
caesar's
entertainment
cameron,
ejaz,
the
western
union
company
christie,
colossa
entertainment,
marlene,
voom,
front
door,
home
rob
hornbuckle
from
allegiant
air
vincent
stamenega
from
axeway
neil
morris
maxwerd
technologies.
C
C
Belpori
global
experience,
specialists,
reggie,
cole,
lockheed
martin
and
tristi
lee
from
citigroup.
So
that's
everyone
from
joining,
like
I
said
a
great
group
here
together
and
thank
you
all
again.
If
you've
just
joined
for
joining,
we
definitely
appreciate
it.
I'm
gonna
hand
it
over
now
to
rick
and
darwin
from
get
lab
to
introduce
themselves
and
and
then
avik
can
give
a
quick
introduction
before
we
get
started.
K
Awesome
thanks
dan,
so
I'm
rick
walker,
my
my
title
says
strategic
account
leader,
but
when
you
boil
it
down
all
I
really
do
is
coordinate
resources.
One
of
those
resources
is
darwin,
so
I
think
I'll
I'll
hand
it
right
over
to
him
real
quick.
F
Hey
my
name
is
darwin
sonoy,
I'm
a
senior
solutions
architect
at
gitlab,
which
means
I
help.
You
understand
how
gitlab
can
solve
your
problems.
I
describe
myself
as
a
devops
automation,
engineer
who
has
embraced
security
as
it
intersects
with
my
daily
work.
So
before
I
came
to
gitlab,
I
ran
a
small
team
that
did
gitlab
as
a
service
for
about
4
000
developers
with
about
100
sas
stacks
and
I've.
F
B
Great,
so
I
hope
everyone
can
hear
me
well,
I'm
based
off
of
new
york
city.
Actually,
although
I
work
for
london
stock
exchange
group
just
to
give
a
brief
introduction,
I
hate
the
devops
and
quality
engineering
for
our
isd
information
services,
division
within
the
group
and
particularly
focus
on
building
the
technology
products
for
fixed
income
analytics
and
index
derivatives
for
both
fixed
income
and
equity.
B
We
are
primarily
a
global
market
infrastructure
company
and
my
sort
of
area
of
expertise
sits
within
the
technology
product
groups.
We
are
not
a
technology
service
organization,
so
our
product
is
pretty
much
what
our
bread
and
butter
is
prior
to
lseg
I've
been
with
the
company
for
three
years.
I
have
mostly
been
with
the
silicon
valley,
companies
and
companies
in
the
northeast,
mostly
focusing
on
technology
products
and
technology.
This
is
my
first
fintech
venture.
C
Awesome,
thank
you.
Avika
appreciate
all
the
introductions
and
before
we
actually
get
started
with
the
geek's
presentation,
I
kind
of
just
wanted
to
put
it
out
to
the
audience.
I
know
that
obviously
you've
seen
some
of
the
content.
That's
come
across
prior
to
the
program
and
we're
going
to
be
discussing
more
or
less
devops,
but
I
just
wanted
to
put
it
out
to
some
of
the
attendees
again.
Anyone
can
answer.
C
L
Hi,
this
is
marlene
van
and
one
of
the
things
that
we're
actively
working
on
is
ensuring
that
our
security
policies
are
facilitated
with
our
use
of
git
lab
and
mainly
in
my
team,
we're
standing
up,
customer
identity,
access
management,
services
for
our
serverless
front-ends
and
our
microservice
solutions,
and
basically
trying
to
keep
secrets
out
of
repos
and
looking
for
ways
to
accommodate
other
secure
coding
policies
through
our
automation
and
ci
cd
pipeline
process.
J
This
is
brian
from
compassion.
I
I
have
the
the
I
get
to
lead
our
engineering
and
architecture
groups,
and-
and
so
one
of
the
things
I'm
always
looking
for
out
of
our
out
of
our
devops
program,
is
predictability
and
repeatability.
As
we
look
across
I.t,
we
see
a
lot
of
things
over
time.
It's
just
a
steady
march
to
commoditization
and
what
I
see
devops,
as
is
the
commoditization
of
deployment
right
and
and
when
you
see
something
move
towards
a
commoditized
type
of
service.
A
C
Anyone
else
I
know,
I
know
it's
it's
hard
to
be
the
first
ones
to
speak,
so
I
I
appreciate
it
for
the
for
the
first
two
and
brian.
If
there's
anyone
else
I'd
like
to
chime
in,
if
not,
we
can,
we
can
move
to
week's
portion
of
the
program.
H
I'll
chime
in
real
quick,
my
name's
vince,
I'm
with
axway,
I
lead
the
journey
of
the
cloud
program.
It's
an
engineering
program
to
bring
our
heritage
products
into
a
cloud
native
stack,
one
of
the
things
I'd
like
to
understand
more
or
take
away
from
this.
Is
you
know?
How
do
we
improve
lead
time
to
change
deployment?
Frequency
mean
time
to
recovery?
I
think,
is
a
big
one
as
well
as
change
failure
rate.
H
So
those
those
are
some
of
the
ones
I'd
like
to
see.
Maybe
how
git
lab
has
a
have
a
measurement
around
it
or
if
others
have
measured
those
things
on
the
cultural
side.
I'd
also,
if
anybody's
done
any
type
of
survey
to
measure
culturally
how
to
how
to
assess
devops
or
your
devops
maturity.
I'd
be
interested
in
that
as
well.
A
C
And,
like
I
said,
if
anyone
would
like
to
use,
you
know,
reactions
or
raise
their
hand
if
they
have
questions
and
or
while
the
presentations
are
going
on,
use
the
public
chat
to
to
ask
questions.
Please
do
and
I'm
sure
that
everyone
will
be
more
than
happy
to
answer
them.
So
with
that
being
said,
I'm
gonna
give
the
the
reigns
over
to
avik
to
begin
so
there
you
go
vic.
Thank
you.
B
Excellent,
all
right,
so
a
lot
of
these
things
that
I'm
going
to
talk
to
you
about
today,
I
think,
is
going
to
be
music
to
your
ears.
Now,
naturally,
we
are
very
complex
market
infrastructure
business.
Our
products
are
pretty
complex.
B
It
takes
a
lot
of
mathematicians
and
you
know,
academics
to
sort
of
predict,
fixed
income
trends,
considering
everything
that's
going
on
in
the
volatile
market
today
and
therefore
we
do
have
the
pain
of
you
know,
going
through
a
very
legacy
platform
and
actually
shifting
and
lifting
that
into
a
modernized
infrastructure,
and
it
impacts
not
just
development
devops,
also
the
overall
culture,
skill
set
and
mindset
of
people,
so
I'm
going
to
quickly
run
through
those,
because
I
understand
that
the
primary
motivation
of
this
attendance
is
to
really
understand
the
strength
that
gitlab
has
a
tool
and
ecosystem
offers.
B
So
bear
with
me
a
second
and
I'll
just
try
to
go
through
as
fast
as
possible
and
in
the
mentoring.
If
you
have
any
questions,
please
feel
free
to
raise
your
hand.
I
can
also
answer
them
offline
if
needed
cool.
So
enough
about
my
team
and
my
group,
we
are
very
lean,
as
you
can
see,
quality
engineering
and
devops
has
looked
as
one
business
strategic
unit
within
our
horizontal
function
of
the
business
and
just
have
a
team
of
six
people.
B
We
tend
to
be
the
champion
and
sort
of
the
evangelist
to
encourage
automation,
to
drive
efficiency
and
comes
to
and
drive
our
products
and
efficacy
in
rs
dlc,
ajan
scrum.
That
goes
without
saying
so
really
devops
essentials.
If
you
think
about
it,
it
does
cover
all
these
different
aspects.
I'm
sure
you
all
know
about
it.
You
know
it
starts
from
all
the
way
to
the
left
of
your
life
cycle
of
design
and
development.
B
Moving
on
to
the
next
one
thing
that
we
have
to
evaluate
is
our
organization
is
like
I
said
we
have
a
diverse
group
of
people
with
different
skill
sets
and
70
of
our
folks
actually
finished
their
grad
school
in
1990s
from
some
of
the
top
new
schools
in
the
in
the
country,
a
lot
of
them
from
non-linear
physics
and
mathematics,
background
and
you're
trying
to
sort
of
raise
the
bar
in
that
their
day-to-day
job
and
actually
bringing
change.
B
So
there's
there's
a
lot
going
on
as
a
business
for
us
in
in
sort
of
making
devops
a
journey,
and
with
that
comes
a
lot
of
resilience
at
individual
and
group
level.
B
So
we
have
to
make
sure,
as
an
organization
from
leadership
that
we
have
a
culture
of
collaboration,
automation
does
become
our
top
priority.
You
have
to
have
automation,
as
your
you
know,
first-class
citizen
to
achieve
devops,
there's
a
commitment,
because
there's
initial
cost
associated
with
all
of
this
and
learning
curve,
and
so
you
know,
if
you
as
an
organization,
you
have
to
sort
of
make
that
commitment
and
then
you're
not
going
to
get
it
right
first
time.
B
So
it's
an
iterative
journey
so
having
that
empathy,
the
engineering
and
practicing
as
sort
of
something
that
we
identified
as
critical
moving
on
to
the
next
slide,
so
we
also
had
360
feedback
within
our
you
know,
managing
directors
and
directors,
and
it
turns
out
that
we
needed
to
change
as
well
to
adapt
to
these
changes.
B
You
know,
suddenly
you
become
a
number
from
a
manager,
you
lead
and
you
lead
through
changes.
You're
part
of
it.
Financial
organizations
typically
have
a
lot
of
organizational
silos
and
vertical
structure.
B
So
we
had
to
sort
of
look
at
it
differently
and
it
was.
It
was
challenging
to
sort
of
look
into
silos
and
moving
them
into
a
collaborative
org
structure,
because
you
know
people
have
a
certain
way
of
doing
things
they
are
made
at
the
end
of
the
year,
the
growth
all
of
that
sort
of
gets
incubated.
When
you
have
a
sort
of
guilt
sort
of
structure,
it's
very
easy
to
implement
those
things
in
a
green
field
startup
or
in
a
technology
service
business.
But
for
us
there
was
a
lot
of
rigidity.
B
Training
is
very
important.
We
noticed
elsegh
is
a
diversified
group
that
organically
grown
through
equating
many
businesses.
For
example,
we
are
a
very
lean
structure.
We
operate
kind
of
like
the
hedge
fund
model,
but
not
all
organizations
within
lsec
had
the
same
operating
model.
There
was
a
lot
of
organization
that
had
monolithic
qa
as
a
function,
and
we
realized
that
you
know
in
order
to
really
achieve
devops.
You
can't
really
have
that
whole
uat
cycle
as
a
silo,
focusing
really
on
quality
and
not
compromising
and
disrupting
your
day-to-day
activity.
B
So
the
interns
need
to
sort
of
get
people
on
board
it,
and
every
every
organization
need
a
different
level
of
training.
So
for
my
group,
a
lot
of
people
had
to
sort
of
modernize
their
monolith
api.
For
another
group,
you
had
a
massive
uat
function
that
you
had
to
sort
of
shift
and
lift
into
getting
into
automation,
developing
them
developing
at
a
people
level,
and
also
focusing
on
sort
of
where
the
true
strength
lies
in
human
beings.
B
You
know
we
had
to
take
some
of
our
domain
experts
and
move
them
into
more
productive
and
functional
role.
Some
of
our
technical
qa
team
members
went
on
to
you
know
the
s-depth
upgrades
on
their
on
their
role
framing,
so
there
was
a
lot
of
investment
that
needed
we're.
Also,
you
know.
A
lot
of
the
groups
have
a
very
long
history
of
managing
things
on
prem
and
managing
things
on
prem.
While
it
can
be
efficient,
if
you
do
it
right,
it's
not
very
scalable
in
today's
needs.
B
So
you
know,
a
hybrid
cloud
is
always
something
that
we
have
considered
and
we
are
sort
of
going
through
that
journey
and
that
that
was
not
a
single
year
or
six
months
quarter
journey.
It
was
a
multi-year
vision,
so
we
are
still
anticipating
end
of
2022
all
of
our
compute
grid
and
all
of
our
apps
would
be
in
cloud
so
that
required
us
some
of
us
to
get
sort
of
you
know
certified
in
aws
solution,
architecture
and
development,
training
and
stuff
like
that.
B
That
was
completely
new
to
the
world,
at
least
given
our
ecosystem
and
along
this
journey,
you
have
to
sort
of
measure
metrics
and
reinvest
your
resources
efficiently,
because
you
know
we
all
are
pretty
stretched.
We
do
not
have
enough
time
during
the
day
or
enough
resources
to
deliver
our
objectives.
Being
a
company
of
4
500
people
running
around
eight
businesses,
we
had
to
sort
of
focus
on
our
strategies
on
reinvesting
our
resources
efficiently.
B
This
is
one
thing,
lcg
does
very
well
and
they
have
his
track
record,
especially
being
in
the
heart
of
new
york
city,
downtown
wall
street
area.
Hiring
retaining
and
rewarding
top
talent
is
as
a
top
priority.
You
can't
achieve
motivation
without
without
really
without
really
investing
in
this.
B
B
B
It
fundamentally
challenges
your
development
approach,
especially
for
an
organization
like
ours,
so
having
that
failed
fast
and
fail
early
approach,
incrementally
showing
the
value
of
doing
a
build
with
some
form
of
sanities
and
feedback,
and
using
monitoring
and
alerting
was
critical
to
achieve
sort
of
continuous
integration.
We
use
jenkins
pretty
much.
Some
parts
of
the
business
uses
stem
city
as
I'm
familiar
with.
We
have
to
benchmark
our
ci.
You
know
build
times
total
number
of
failures,
build
failures,
defectors
kept
right
from
the
unit
tests.
B
All
of
that
comes
into
this
ecosystem
right,
focusing
a
lot
on
having
developers
own
quality.
Now
that
we
don't,
we
didn't,
have
a
keyway
department,
helped
this
a
little
bit
actually
accelerated
this
process.
B
We
always
say
that
in
our
organization
which
I'm
gonna
talk
about
in
my
next
slide
continuous
testing,
so
we
have
a
term
that
we
use
in
our
company
called
full
stack
quality
engineers,
so
my
four
qet
people
actually
have
historic
background
of
building
and
shipping
products.
So
therefore
it
actually
shifts
the
burden
of
quality
to
every
everyone
who
is
writing
code,
including
research.
B
B
We
had
to
sort
of
create
that
culture
and
the
way
we
sort
of
did
it
is.
You
know
you
use
book
club,
we
used
brownback
sessions
and
you
know
you
know
some
of
our
dashboards
are
actually
built
by
a
core
research
person
using
python
body
and
dash
so
again,
innovation
to
sort
of
deliver
quality,
building
tools
and
using
the
tools
to
sort
of
automate.
B
Your
qa
process
run
your
fastest
tests,
early,
innovate
to
parallelize
them
use
emerging
technologies
such
as
ai
and
ml,
to
come
up
with
risk-based
models
on
regressions
new
software
to
test
software,
not
people
again.
I
understand
that
for
some
critical
ux
based
applications
is
a
little
bit
more
challenging
because
you
do
have
a
sort
of
value
proposition
coming
towards
the
end
of
the
life
cycle,
and
you
can't
really
identify
those
changes
till
you
actually
make
it
we're
somewhat
lucky,
because
not
all
are
not
most
of
our
products
are
not
built
on
uis
they're,
basically,
data.
B
The
data
is
our
intrinsic
value
that
we
provide
to
the
businesses,
and
you
know
the
accuracy
of
the
data
from
the
mathematical
models,
actually
quantify
and
qualify
our
product
and
client
retention,
but
something
to
note
there
is
always
a
way
to
automate
things
and
trying
to
invest
and
focusing
on
that.
There
is
a
qa
approach.
I
think
it's
becoming
a
lot
of
traction.
One
of
the
conferences
I
was
there
last
week
talked
about
neurodiversity
and
using
neurodiversity
to
sort
of
build.
B
Your
kiwi
stack
has
been
turned
out
to
be
very
effective
in
certain
organizations,
but
I
wouldn't
go
too
much
into
it.
There
is
this
revolution
going
in.
You
know
automating
qa,
using
qe,
so.
B
Very
familiar,
I'm
sure
all
of
you
are
the
it's
much
cheaper
to
find
a
problem
in
in
in
the
unit
level
than
at
end
to
end
level.
We
all
know
that
from
every
aspect
of
your
sdlc,
no
matter
what
sort
of
methodology
you
use,
these
are
some
of
the
tools
that
can
help
you
get
there,
but
again
for
the
most
part
for
a
business
like
ours,
we
had
to
sort
of
innovate,
build
our
own
tools
because
of
the
custom
complex
needs
of
our
business.
B
We
couldn't
just
use
one
tool
that
fits
all
criteria
and
one
has
to
be
prepared
to
do
that.
One
thing
I
noticed
that
having
developers
write
test
is,
is
a
cultural
upliftment.
It
takes
time
because
you
know
people
who
are
constantly
trying
to
innovate
do
not
wake
up
every
morning,
thinking
that
they
will
be
writing
the
world's
best
test.
B
But
if
you
sort
of
make
it
the
mandate
that
you
know
you
don't
become
a
good
engineer,
if
your
doesn't
work,
so
I
think
forcing
that
down
the
on
the
food
chain
really
helps
from
an
organizational
standpoint.
It
actually
makes
you
a
better
engineer.
We
have
seen
that
our
folks
have
actually
taken
roles
in
companies
that
people
aspire
for
for
full
stack
development
and
application,
development
and
solution
architecture.
The
mobility
has
increased
by
actually
investing
in
this
domain,
so
something
to
think
about
security.
I'm
not
the
security
expert
in
the
business.
B
There
is
a
cso
unit,
but
one
thing
we
realized
that
we
are
a
highly
regulated
environment
because
we
produce
indexes
it
produces
analytics
that
actually
portfolio
managers,
asset
managers
and
normal
people,
like
you
and
me,
use
like
the
russell
indexes
for
our
passive
investment.
So
it's
very,
very
critical
for
us
to
be
secure
our
platform,
our
products
and
our
process.
B
Some
of
these
tools
that
we
use
for
identity
access
management,
doctor
vera
code
for
our
security
scan
sooner
two
for
our
code
coverage
and
static
code
analysis.
We
are
trying
to
embed
them
in
our
regular
development
lifecycle.
Looking
for
problems
before
you
know,
they
would
be
going
out
in
the
real
world.
B
It's
critical
just
trying
to
get
a
motivation
since
do
any
of
you
have
any
questions
so
far,
so
good.
B
B
We
have
a
very
complex
three
decade
old
release
process,
pretty
much
written
on
power
modules,
custom
power
modules
to
sort
of
drive,
changes
with
all
rcs
and
monolithic,
large
directory
structure,
file
changes
and,
on
the
other
hand,
we
have
this
modernized,
api,
microservices
and
the
modern
need
to
deploy
products
and
artifacts
into
the
cloud.
So
parallel
efforts,
similar
people
migrating
into
the
both
worlds.
We
use
terraform,
ansible,
playbook,
docker
and
kubernetes.
I
I
did
give
this
as
a
demo.
We
don't
use
docker
and
kubernetes.
B
We
pretty
much
use
that
backup
from
ansible
stack
the
hashtag
abstract
some
of
the
stuffs.
Given
the
team
is
very
lean.
It's
sometimes-
and
I
want
to
emphasize
on
that-
it's
sometimes
cheaper
or
easier
for
us
to
buy
products
over
builds
from
scratch.
B
A
lot
of
kubernetes
implementation,
especially
I
was
head
of
engineering
at
a
company
called
wework.
All
of
you
must
have
heard
about
in
in
in
the
2016's
when
it
was
the
rocket
ship
and
we
we
tried
to
implement
a
custom,
kubernetes
cluster
and,
and
it
was
painstaking
challenging,
and
we
figured
that
the
resources
we
had
in
hand
wasn't
enough.
So
else
as
a
group
was
pretty
smart
about
it
used
tools
that
can
help
their
life
easy,
but
only
to
devops
engineer
to
deliver.
B
You
know
cicd
for
a
150
million
dollar
business
just
within
analytics.
It's
a
fair
assumption
to
make.
B
This
is
this
is
where
it
gets
tricky.
Actually,
you
know
we
try
to
try
to
initially
monitor
a
lot
of
server
metrics
performance
and
a
lot
of
these
things
didn't
really
help,
because
our
clients
still
call
and
say
you
know
your
compute
numbers
were
not
right
or
your
performance
is
not
right.
So
monitoring
the
right
thing
and
using
these
tools
to
advantage
is
very
critical.
B
We
we
sort
of,
went
through
some
training
on
code,
profiling
and
centralized
logging
and
alerting
creating
our
own
sort
of
dashboard
for
getting
the
right
error,
tracking
and
monitoring
the
right
people,
but
this
is
a
critical,
critical
aspect
of
devops.
For
for
most
of
us,
the
cycle
is
not
complete
with
just
deployment
and
delivery.
B
B
Simplified
devops
workflow,
that's
very
similar
to
us.
You
know
you
test
at
every
phase
of
your
development,
build
march
code
branch
plan,
that's
sort
of
to
show
and
emphasize
and
reinforce
on
continuous
testing
in
an
iterative
feedback
process.
B
I
think
it's
pretty
self-explanatory
for
everyone
elastic
infrastructure,
yeah.
This
is
where
it
gets
a
little
difficult,
because
if
you
have,
if
you
have
long
legacy
monoliths
and
you
are
so
used
to
managing
your
own
infrastructure
and
prem
the
cloud
utilization
and
cost
and
very
nature
of
your
application,
especially
not
having
right
load
balancers
or
having
you
know,
wrong,
choice
of
tools
can
really
affect.
B
Even
if
you
move
into
cloud
cloud,
cost
could
be
enormous,
managing
that
upfront
and
knowing
that
upfront
and
sort
of
predicting
that
is
very
useful
and
is
needed
for
you
know
how
you,
what
what's
your
scaling
strategy,
whether
your
horizon
horizontally
scaling
group
of
apis
or
vertically
scaling
or
hybrid
your
micro
services
design
patterns?
Do
you
use
the
api
management
layer
in,
in
addition
to
the
strengths
that
you've
built?
B
If
you
have
monoliths
like
ours,
we
have
a
very
huge
xml
api
built
into
our
core
compute
grid
that
really
modernization
means
opening
that
gateway
into
the
other
data
pipelines
other
other
consumers.
But
you
know
bringing
that
to
a
pub
subs
ecosystem
with
kafka
and
stuff
like
that
becomes
pretty
challenging
because
at
the
core
you
are
still
sort
of
monolith.
It's
almost
like
adopting
agile
but
you're
following
an
autoformal
life
cycle,
so
yeah.
B
This
is
this-
is
where
your
your
immutability,
your
micro
services,
design,
pattern,
your
architecture,
your
tenancy
or
your
capacity
to
sort
of
scale
on
needs.
Fortunately,
our
products
do
not
go
out
to
the
world
wide
web.
B
It's
limited
to
portfolio
managers
and
asset
managers
and
clients
that
pay
us
money
for
our
data,
but
still
we
are
not
immune
to
the
vulnerability
on
the
infrastructure
and
a
good
great
deal
of
attention
to
be
paid,
and
it
brings
the
whole
village
right
you,
you
basically
are
not
just
devops
at
this
point,
your
entire
ecosystem,
starting
from
modelers,
the
quarants,
the
developers,
product
engineering
system,
engineering
and
leadership,
gets
bought
into
this.
B
It's
very
important
that
you
want
to
stay
as
elastic
as
possible
cool.
So
what's
the
value
proposition
again,
I
did
mention
about
the
upfront
cost
and
the
synergy
that
you
get
out
of
it
with
with
time.
So
again
again,
you
know
the
tech
companies
such
as
google.
They
don't
call
the
devops
group
anything
but
productivity
engineering,
so
it
is
really
productivity.
You
really
buying
back
time
for
your
people,
for
them
to
innovate
and
especially
in
industries
like
ours.
We
compete
with
companies
like
msci
blackrock
bloomberg
for
building
indexes.
B
Smp
is
very
important
that
we
can
roll
out
indexes
faster
than
them
right.
There's
a
lot
of
fintech
propositions
around
fixed
incoming
analytics
as
well.
Although
we
sort
of
the
pioneer
in
it
but
again
productivity
again
all
falls
back
to
your
value
streams.
You
have
to
innovate
here
constantly.
B
You
can't
spend
time
without
innovating,
because
you
pretty
much
fall
out
of
place
operational
risk
again
with
shift
and
left
comes
down
times
and
risk
of
vulnerabilities
in
all
aspects,
you
have
to
sort
of
reduce
your
operational
risks.
I
did
mention
this
earlier,
so
I'm
not
going
to
go
much
into
it
reinvestment.
So
if
you
have
upgraded
your
skill
set
on
print
on
cloud,
you
had
a
system
engineering
group
and
that
system
engineering
group
now
can
be
invested
into
devops
stuff.
B
Like
that,
we
try
to
reuse
our
assets
as
much
as
possible
shift
more
focus
on
end
users.
You
know
client
obsession
customer
of
central
city,
whatever
you
call,
it
comes
the
developer
position
of
devops,
which
one
of
the
conference
I
went
to.
There
was
a
talk
about
charles
schwab.
B
Over
the
five
years
period,
almost
five
billion
dollars
of
synergy
on
cost
was
realized
from
all
of
their
devops
investments.
So
again,
that's
a
hallmark
of
how
much
it
can
actually
give
you
back.
If
you
make
that
upfront,
strategic
investment.
B
Metrics,
you
know
goes
without
saying:
moving
fast
doesn't
mean
breaking
things
you
have
to
have
measurable,
actionable
and
traceable
metrics,
some
of
them
just
velocity
defects,
scape
rates,
application,
performance,
reliability,
good
complexity,
error
rates
and
many
more.
There
are
also
things
like
mean
time
to
detect
mean
time
to
deliver,
mean
time
to
fix
stuff.
Like
that,
you
know
there
are
ways
to
measure
your
success
and
you
have
to
measure
them
as
you
go
through
this
journey.
B
I
think
it
goes
without
saying
at
every
aspect
of
the
levels,
the
collaborative
tools
you
know
we
try
to
use
as
much
as
possible
to
sort
of
give
us
this
metrics
offhand
through
using
automation
as
well,
because,
again
you
don't
have
a
team
to
sort
of
invest
and
their
time
to
identify
the
metrics.
You
know
really
you
want
your
systems
to
give
you
enough.
B
C
Okay,
well,
we
can.
Thank
you.
Avik
definitely
insightful,
definitely
appreciate
it.
We
will
move
on
to
to
darwin.
So
darwin.
The
floor
is
yours.
F
Here
so
let's
try
to
consider
some
of
the
things
that
we
might
talk
about
today
in
terms
of
ci,
cd
automation
and
one
of
the
things
that
I've
noticed
over
time
is
that
the
transformation
that
happens
in
software
as
it
turns
into
a
more
mature
software
manufacturing
operation
is
quite
similar
to
some
of
the
early
manufacturing
transformations
that
happened
in
physical
goods.
And
of
course,
we
all
know
that
henry
ford
was
lauded
as
the
individual
who
really
brought
this
kind
of
concept
to
the
fore.
F
F
So
digging
into
this
a
little
bit
the
parallel
worlds
of
the
evolution
of
automated
production
in
physical
goods,
which
I
was
just
talking
about,
we'll
also
talk
a
little
bit
about
the
inherent
devops
transformation.
Throughput
limits,
so
the
actual
process
of
accomplishing
a
transformation
into
software
manufacturing
has
some
places
where
you,
you
can't
really
go,
buy
more
iops
like
you
can
on
the
amazon
cloud,
and
you
have
to
kind
of
plan
for
that
ahead
of
time
and
also
be
patient
with
it
as
you're
going
through
it.
F
I
also
want
to
talk
about
something
I
call
the
russian
nesting
doll
effect,
which
is
where
you
go
to
handle
a
concern.
You
say:
hey,
let's
reduce
this
down
into
engineering
and
automation,
and
then
once
you
get
done,
you
discover
that
lo
and
behold
inside
that
is
another
activity
very
similar
to
that
first
activity
to
have
to
reduce
down
to
engineering
and
automation,
and
so
we'll
take
a
little
bit
of
a
look
at
that
and
kind
of
analog.
F
The
the
how
it
happened
in
manufacturing
to
software
manufacturing
we'll
also
talk
about
avoiding
the
devsecops
russian
nesting
doll.
So
here's
another
area
where
we
seem
to
be
repeating
this
nesting
doll
effect
which
it's
at
this
point
it
seems
like
it's
quite
unnecessary.
So
I
want
to
take
a
little
bit
of
a
look
at
that
and
then
finally,
one
of
my
screen
up
here
a
bit
but
how
to
have
a
tortured
software
manufacturing
transformation.
F
So
we'll
give
you
a
little
bit
of
advice,
that's
in
the
form
of
an
anti-pattern
kind
of
how
how
to
be
tortured.
If
you
want
that,
so
henry
ford
really
created
the
manufacturing
transformation
and
one
of
the
key
insights
among
all
the
many
things
that
were
learned
was
that
craftsmanship
should
really
focus
on
innovations
that
delight
customers
and
everywhere
else.
We
should
do
as
much
engineered
automation
as
possible
so
rather
than
having
craftsman
assembling
cars
and
putting
tires
and
wheels
together
and
putting
them
on
the
car,
we
focus
those
crafting
skills
around.
F
So
if
we,
if
we're
able
to
pull
this
off
some
of
the
benefits
that
were
afforded
to
henry
ford,
that
would
also
be
afforded
to
us,
we
will
have
a
better
speed
of
innovations
to
market.
It
could
be
an
entire
product,
it
could
be
new
innovations
or
features
in
an
existing
product.
We
can
get
those
out
the
door
if
we
can
reduce
it
far
enough
and
fast
enough.
F
We
can
make
the
bet
by
actually
playing
it
on
the
market
and
seeing
if
customers
like
it,
if
they
don't,
we
can
remove
it
and
there's
not
a
lot
of
cost
to
doing
that
as
opposed
to
the
old
model,
where
there's
a
lot
of
cost
in
trying
an
experiment
like
that
on
the
real
market,
we
also
have
improved
predictability
and
quality.
So
whenever
things
are
automated
they're
more
predictable,
the
quality,
the
results
is
more
predictable.
F
We
have
to
talk
a
little
bit
about
the
surge
investment
that's
necessary
to
get
there,
though,
sometimes
folks
feel
that
hey
you
know,
automation
is
going
to
be
a
net
reduction
in
costs.
Therefore,
I
can
keep
my
costs
low,
as
I
also
get
there,
and
this
can
be
a
mistake
that
derails
a
lot
of
automation,
efforts,
also
the
encoding
of
tacit
human
knowledge
into
intellectual
property.
F
Because
everything
that's
necessary
to
make
things
happen
for
customers
is
known
in
a
way
that
can
be
shared
and,
finally,
the
removal
of
drudgery.
In
most
cases
when
automation
is
displacing
human
work,
that
human
work
is
not
something
that's
the
most
enjoyable
part
of
someone's
work,
and
if
it's
done
in
an
empathetic
way
and
and
we
seek
to
re-skill-
then
of
course
it
can
be
a
net
positive
for
everyone
in
it.
We
don't
really
have
a
lot
of
challenges
with
people
having
enough
work
and
enough
jobs
on
the
market.
F
So
it's
less
of
a
challenge
for
us
and
it
would
have
been
in
henry
ford's
time
or
in
other
physical
manufacturing
businesses
today,
but
moving
people's
skills.
So
they
can.
They
can
also
focus
on
work
that
is
interesting
to
them.
F
F
So
we
kind
of
glanced
back
at
what
happened
with
car
manufacturing.
You
had
sort
of
a
craftsman
culture
before
mass
automation
and
crafts.
People
would
assemble
vehicles.
They
knew
all
the
technical
details
of
how
to
do
this
and
they
also
performed
the
physical
labor
of
doing
the
actual
assembly.
Some
of
the
challenges
this
presents
is
that
keeping
workers
skilled
is
challenging.
We
have
an
apprenticeship
model
and
a
worker
has
to
be
around
for
a
long
time
before
they
are
able
to
really
be
productive
in
every
aspect
of
the
manufacture
of
goods.
F
Scaling
production
can
be
challenging
in
this
regard,
and
if
you
want
to
think
about
what
does
that
look
like
in
software,
a
software
craftsman
would
be
kind
of
the
days
when
you
had
that
compiler
on
their
workstation.
They
built
the
software
on
their
workstation,
and
then
you
did
stuff
with
those
bits.
After
they
were
done,
they
had
to
get
that
workstation
running,
keep
it
running.
F
They
had
to
know
all
the
details
of
all
the
different
things
we
want
to
do
with
the
software
in
order
to
get
it
built
and
completed,
and
so
it
wasn't
really
an
assembly
line.
It
was
more
like
I'm
sitting
in
my
little
craft
area.
Building
my
one
copy
of
the
software
or
my
one
part
of
the
software
consistent
quality
is
a
challenge
when
we
have
a
lot
of
variability
that
craft
brings
to
things
serviceability
of
the
final
product.
F
So
the
final
product
can
be
much
more
a
function
of
individual
skill
or
individual
perspectives
on
how
to
do
something
and
so
serviceability
that
product
is
potentially
produced
and
then
that
know-how
is
a
corporate
asset.
So
having
that
know-how
encoded
in
a
way
that
we
can
continue
to
perform
that
activity.
So
so,
really
when
we
have
the
know-how
integrated
with
the
manufacturing
labor,
that's
one
of
the
essences.
That
is
creating
the
challenges
here
for
us.
F
A
F
Product
in
mass
quantity,
so
this
is
kind
of
the
initial
dream
of
automation,
of
the
result
when
we
make
this
transformation
there's
some
key
things
that
happen
crafting
to
engineering
and
automation
causes
us
to
move
that
tacit
knowledge
to
be
explicit,
individual
knowledge
to
be
more
shared,
so
it
can
be
collaborated
around
and
improved
by
group
processes,
implicit
processes
to
become
explicit,
so
things
that
go
on
inside
of
a
craftsperson
that
they
all
they
only.
F
They
know
how
to
do,
and
you
know,
they're
the
they're,
the
person
who's
five
times
as
productive
as
anyone
else.
Those
kind
of
things
can
start
to
become
more
explicit
and
leveraged
by
others.
Another
interesting
factor
is
product
that
is
designed
for
craft
assembly
versus
product.
That's
designed
for
automated
assembly.
I've
experienced
this
in
software,
where
I've
seen
situations
where
the
actual
code
and
configuration
are
mixed
together
to
a
degree,
that's
very
difficult
to
unwind,
and
this
is
not
something
that
we
you
know.
We
advocate
modern
software
development.
F
The
12-factor
app
is
a
specific
principle.
The
12-factor
app
methodology
is
that
you
separate
configuration
and
code.
In
this
case,
there
was
not
a
lot
of
will
to
pull
that
apart,
because
a
lot
of
risk
could
be
created
by
it
and
at
a
certain
point
we
came
under
pressure
that
hey
you
know:
why
isn't
the
build
automated
yet
and
a
lot
of
it
had
to
do
with
the
product?
Was.
F
Automated
assembly
also
integrated
manufacturing
labor
with
externalized
and
automated
labor,
so
another
aspect
of
this
is
some
of
the
speed
limits
that
will
hit
and
these
speed
limits
can
be
inherent
in
a
way
that
you
can't
simply
overcome
them
by
adding
more
bodies
or
by
issuing
more
management
directives
that
we
need
to
get
this
done.
And
so,
let's
take
a
look
at
some
of
these,
you
could
kind
of
think
of
these
as
terminal
velocities
things
that
will
will
not
go
any
faster.
F
I've
experienced
this
in
trying
to
build
automated,
for
instance,
build
agents,
and
you
ask
the
existing
folks
who
work
with
the
development
workstation
say:
what
do
you
do
to
install
this
dependency?
We
need
on
the
build
workstation
and
the
answering
invariably
get
back.
Is
you
just
take
all
the
defaults
and
it's
good
and
of
course,
after
automating
that
piece
and
it's
not
good.
F
Another
one
is
the
maximum
bandwidth
of
re-skilling,
so
getting
people
to
transition,
their
skill
sets
and
their
perspectives
into
more
of
an
engineering
mindset
and
being
able
to
take
that
time
to
really
dig
deep
and
reskill
and
then
also
that
product
refactoring
for
assembly
line
production.
So
if
the
product
is
far
enough
away
from
being
assembly
line
ready,
it
can
take
a
lot
of
effort
and
iterations
to
get
through
to
that
and.
F
Here
to
try
to
you
know,
get
this
working
and
make
it
work.
Sometimes
I'm
asked
you
know
hey
what
do
you
think
about
rehiring,
instead
of
trying
to
reskill
a
lot
of
times?
This
perspective
overlooks
the
many
levels
of
knowledge
that
practitioners
have
people
who
work
on
your
software.
Don't
just
know
the
languages
it's
coded
in.
F
They
actually
know
your
industry,
so
they've
spent
enough
time
analyzing
the
business
problems
in
that
industry
that
they
have
some
pretty
deep,
bespoke
knowledge
about
the
industry,
which
a
new
hire
very
likely
does
not
have
unless
you
hire
within
industry.
They
also
have
not
only
familiarity
with
the
languages.
Your
code
is
coded
in,
but
with
your
actual
code.
F
So
it's
like
kind
of
knowing
the
encyclopedia
britannica
and
it
can
take
an
entire
team
to
know
all
the
aspects
in
depth
and
so
that's
very
high
value
knowledge
and
then,
of
course,
your
work
culture
of
how
to
get
things
done.
One
thing
that
can
be
done
to
accelerate
this
process
is
to
see
the
field
with
people
who
are
practitioners.
So
if
you
see
people
who
are
early
adopters
and
some
of
the
practices
you're
looking
for
really
accelerate
them,
give
them
permission
to
experiment,
give
them
permission
to
learn
and
give
them
permission
to
share.
E
F
So,
let's
drop
into
the
russian
nesting
doll
effect
and
as
we
start
into
it,
you'll
be
like
yeah.
I've
been
there
been
there
done
that,
but
hopefully
we
get
into
a
deeper
level
where
you're
like
okay.
Maybe
this
will
keep
happening
and
I
wasn't
aware
that
it
will
keep
happening
and
then
we're
gonna
talk
as
we
wrap
up
about
some
of
the
ways
to
skip
some
of
the
russian
nesting
doll
levels.
F
So
when
we
have
product
as
craft,
we
have
all
those
concerns
that
we
were
talking
about
encapsulated
within
it,
so
tacit
knowledge
linking
of
labor
with
know-how,
and
when
we
crack
this
open,
we
really
want
to
move
that
to
an
engineered
approach.
So
we
engineer
the
product
explicitly
document
it,
so
it
can
be
automated.
But
when
we
make
this
move,
we
soon
find
out
that
within
the
factory
we
don't
have
strictly
machines,
so
ford's
first
factory.
If
you
envisioned
it,
it's
not
got
like
zero
people
in
it.
F
There's
lots
of
people
in
it,
and
so
there's
generally
people
making
parts
with
a
lot
of
automation
but
final
assembly
or
the
actual
processes
to
get
that
all
done
are
not
completely
automated
and
so
there's
the
reduction,
then
of
the
actual
process
of
building
sub-componentry
also
needs
to
be
automated,
and
once
you
reduce
that
to
a
more
fully
automated
format
where
there's
not
people
involved.
In
doing
that
part,
we
find
that
there's
another
level
and
that
level
ends
up
being
factory
craft.
Or
how
do
we
link
all
of
this
together?
F
So
that's
one
aspect
of
the
original
crafts
person
that
was
inside
of
their
head,
how
to
link
all
this
stuff
together
and
make
a
final
product
that
now
that
you've
externalized
it
it
also
has
to
be
dealt
with,
and
we
also
want
to
reduce
it
to
engineering
and
automation,
and
so
this
kind
of
repeating
effect
can
get
frustrating.
If
you
feel
like
you
know,
hey,
we.
F
To
go
all
all
in
in
one
big
shot
and
finally,
level.
Three
of
maturity
would
be
more
of
an
automation,
assembly
line
engineer
who
can
actually
deal
with
sub
componentry
or
fully
assembled
assembly
lines
pre-made
that
they
can
use
off-the-shelf
component
tree
to
actually
build
the
factory
itself,
so
a
factory
that
builds
factories
or
a
toolbox
that
lets
you
quickly
build
factories
themselves
for
manufacturing
and
a
lot.
There
is
some
modern
equivalents
today,
even
in
physical
manufacturing
there's
buildings,
you
can
stand
up
very
quickly
assembly
lines.
F
You
can
stand
up
very
quickly
to
put
together
an
actual
physical
factory
in
a
fraction
of
the
time
that
it
took
henry
ford
to
put
his
together.
Another
place
where
we
can
hit
another
level
is
the
whole
infrastructure's
code
area
or
and
or
cd.
So
people
realize
oh,
you
know
we
got
our
software's
completely
ready
to
go,
but
now
we
have
individuals
who
are
you.
A
F
Handcrafting
amazon
cloud
environments
to
deploy
the
software
into
so
you
want
to
iterate
here
as
well.
One
place
where
you
should
be
able
to
skip
this
effect
is
the
devsecops
appsec
area.
Many
companies
find
that
they're
in
a
craftsman
stage.
There's
some
devsec
office
engineers
are
used
to
running
reports
and
chasing
after
people
and
getting
to
address
their
their
vulnerabilities.
F
Devsecops
engineers,
who
are
more
automation,
oriented,
are
used
to
writing
automation
code
themselves.
To
do
some
of
these
activities,
we
then
get
into
having
multiple
tools,
knitted
together.
So
once
we
start
to
find
some
tooling
that
works
for
us,
we
still
have
to
knit
it
together
with
complex
processes,
maybe
some
automation,
maybe
some
manual
processes,
and
then
one
thing
that
I've
noticed
that's
getting
challenging
for
some
companies
is
late
discoveries
because
they
didn't
plan
this
journey
to
their
devsecops
maturity.
So
I've
had
one
customer
come
in
and
say:
hey.
F
Last
year
we
paid
so
security
company
30k
this
year,
we're
going
to
fully
ramp
all
of
our
scanning,
so
we
do
scanning
as
early
as
possible.
We
do
it
to
every
branch,
every
language
and
they
quoted
us
over
a
million
dollars,
and
so
these
consumption-based
models
can
really
hit
hard,
also
tool,
implementation
and
training
costs
and
the
cost
of
not
integrating
this
into
ci.
In
gitlab.
J
F
So
the
question
is:
why
play
with
dolls?
At
all,
I
encourage
my
customers
to
do
three
year:
devsecops
integrated
maturity
and
total
cost
of
ownership
plan
so
that
we
have
some
customers
who
come
in
and
compare
hey.
F
So
in
feature
branches,
not
just
when
it
merges
with
main
or
default
branches,
and
then
let's
see
what
it's
going
to
cost
you
in
that
three
year
plan
to
keep
going
on
the
diy
path,
do-it-yourself
path
and
then
compare
that
to
gitlab
with
gitlab.
Really
we
have
a
factory
making
kit
and
inside
of
there
are
some
prefabricated
assembly
lines.
So
auto
devops
is
an
example.
If
you
have
a
project
say
a
node.js
project
that
is
expressed
in
a
well
recognized
way.
F
Basically,
if
heroku
build
packs,
can
build
and
test
run
your
build
and
run
your
test,
then
you
can
simply
turn
on
auto
devops
and
it
will
build
test.
Run.
Security
scans,
stand
up
a
environment
for
dynamic
security
testing.
That's
very
unique
about
git
labs
being
able
to
do
that
dashed
on
every
branch
all
the
time
and
then
push
it
out
to
an
environment
that
you
can
do
performance
testing
on.
You
can
do
human
ua
testing.
F
If
you
still
have
that
kind
of
testing
and
then,
when
you
merge
that
branch
all
of
that
is
torn
down,
so
this
pre-assembled
assembly
lines,
we
also
have
subsections
of
devsecops
assembly
lines.
We
also
have
prefabricated
sub-assemblies,
so
if
you
just
want
our
sas
scanning,
you
can
use
it.
F
We
have
partners
who
are
more
increasingly
providing
these
sub-assemblies
so
that
you
can
simply
hook
them
into
your
pipelines
or
into
the
auto
devops
pipeline,
and
then
one
thing
that
a
lot
of
people
miss
about
the
product
is
we,
you
can
make
your
own
pre-fabricated
sub-assemblies
and
your
own
assembly
lines
that
are
prefabricated,
so
many
of
you
in
large
organizations
have
a
developer
enablement
team
that
actually
looks
at
tooling
provides
tooling
stands
up
tooling.
This
is
the
kind
of
team
that
I
was
on
before
coming
to
gitlab.
F
Full
instance,
level
or
even
a
group
level,
so
that
individual
teams
can
have
this
kind
of
expression
of
their
own
prefabrication.
Another
question
I
get
a
lot
of
is:
hey.
Can
gitlab
do
this
low
level
activity
because
everybody
sees
some
of
these
prefab
parts
and
they're
like
okay
great?
But
what?
If
I
need
a
you
know,
whatchamacallit
that
we
only
have
here
at
our
company
and
the
answer
is
always:
can
you
do
it
at
the
command
line?
If
so,
then
yeah
we
can
do
that.
F
F
You
can
skip
russian
dolls
by
starting
as
high
in
this
stack
as
possible
and
making
your
way
down
to
the
low
level
only
if
necessary,
real,
quick,
a
few
ways
to
get
involved
with
gitlab.
If
you're
not
already,
we
provide
sas
and
self-managed.
F
F
So
we
have
some
customers
very
open
source
opinionated
and
don't
even
want
that
code
in
the
solution,
even
if
they're
not
licensed
or
using
it
so
production
grade,
cic
automation
should
be
prefabricated
should
be
scalable
highly
available.
It
should
also
be
modular
and
it
should
be
pipeline
as
code.
We
didn't
really
dig
deep
into
that.
F
Your
application
code
and
your
infrastructure
code,
not
skipping
the
devsecops
russian
doll
going
ahead
and
doing
that
same
old
crafts
craftsman
to
engineered
automation,
transformation,
not
allocating
sufficient
surge
time
and
resources
to
make
these
transformations
can
make
it
a
very
torture
experience,
not
allocating
time
or
architecture
effort
to
refactor
the
product
so
that
it's
assembly
line
friendly,
not
automating.
All
the
russian
dolls
so
is
qa
still
manual
is
app
sac
still
with
semi-manual
bottleneck,
I'm
not
using
iteration.
F
Of
how
to
facilitate
that
transformation
and
not
driving
these
transformations
to
done
done
all
the
way
done
so
go
ahead
and
leave
a
few
of
them.
Undone.
You
know
just
so
that
everybody
still
has
to
have
some
manual
processes
in
the
mix,
not
using
off-the-shelf
tooling,
to
kind
of
skip
this
cycle.
We
don't
need
to
actually
do
agile.
Learning
of
the
fact
that
you
know
craft
to
engineering
cycles
are
necessary
and
they'll
be
necessary
in
every
area.
F
Possible
and
then
then
another
thing
too
is
sometimes
people
get
a
little
overzealous
and
they're
like
I
want
to
eliminate
all
craft.
The
craft
is
actually
the
part
of
people's
jobs
where
the
innovation
happens,
where
real
value
is
generated,
and
so
the
goal
is
not
to
eliminate
all
craft.
You
know
having
ai
build
all
software,
but
to
make
sure
that
the
the
human
craft
component
is
really
being
leveraged
for
what
it's
the
most
valuable
for,
which
is
customer
delighting
innovations.
F
So
that's
what
I
have
for
content.
I
just
wanted
to
make
note
that
gitlab
wanted
to
send
everyone
a
thanks,
so
you
will
be
receiving
a
60
dollar
grubhub
gift
card.
It
will
be
coming
from
a
thanks.com
email
address,
which
is
thanks
without
the
a
so
if
you
don't
find
it
initially
take
a
look
in
your
spam
folder
and
if
you
don't
find
it
then
contact
us
and
let
us
know-
and
we
will
help
you
out
with
that.
F
So
that's
all.
I
have
to
present
any
questions
or
comments.
F
Thank
you.
Observations
resonance
with
with
some
of
the
challenges.
I
F
Yeah
so
when
you
first
reduce
product,
so
your
actual
software
product,
you
want
to
make
it
more
of
an
engineered
effort
than
you
know,
a
bunch
of
a
bunch
of
software
developers
sitting
around
tooling
away
and
you're,
not
quite
sure.
What's
going
on,
so
you
you
make
it
more
of
an
engineered
effort,
and
in
that
first
level,
then,
once
you
separate
that
knowledge
from
the
developers,
you
start
to
understand,
for
instance,
adopting
scm
when
you
adopt
scm
now
the
code
is
going
somewhere
shared.
F
Now
you
can
collaborate
around
it
around
merge
requests,
some
of
the
skills
and
some
of
the
knowledge
of
the
individuals
is
now
publicly
visible
and
able
to
be
shared.
But
then
once
you've
done
that
you
think
oh
wow,
you
know
we're
making
some
progress
here,
but
then
it
turns
out.
Well,
you
know
you
haven't
done
ci
yet,
and
so
ci
is
a
whole
other
aspect
of
having
to
reduce
that
again,
because,
as
you
try
to
automate
that
you
discover
things
like
I
mentioned,
you
know
the
build
machines
that
actually
can
do.
F
The
software
builds
whether
they're
developer
workstations
or
your
first
shot
at
ci.
Someone
manually
snowflaked
out
a
nice
ci
build
machine,
and
now
that
is
not
really
production
grade.
If
that
machine
goes
down,
it
takes
you
two
weeks
to
figure
out
what
you
know
what
was
on
it
and
how
it
worked,
and
so
it
ends
up
being
the
same
problem
reoccurring
again
and
again
because,
as
you
as
you
perfect
one
area,
you
actually
either
create
the
new
area.
F
So
when
you,
when
you
start
to
automate
you're,
actually
creating
automation
that
wasn't
there
before
and
so
that
automation
itself
needs
to
keep
being
driven
down
to
code.
Basically,
when
you
get
to
everything
as
code,
one
of
the
cool
things
about
code,
is
it's
not
just
the
intellectual
property
of
how
to
do
it,
but
it
can
actually
perform
the
the
actual
assembly
so
something
in
physical
manufacturing.
We
don't
have,
but
people
aren't
watching
up
for
this,
so
I
see
it
happening
in
devsecops
again.
You
know
we
have
people
stumbling
around
with.
F
F
K
So
darwin,
I
guess
for
for
somebody
less
technical
would
would
that
be,
and
this
is
for
my
own
understanding.
Would
that
be
you
know,
an
organization
doesn't
have
any
automation
at
all
and
all
of
a
sudden
they
decide.
I'm
gonna
automate
my
deployment
process
right
and
then
they
have
all
kinds
of
manual
stuff
that
happen
before
that,
so
their
throughput
is
increased
when
the
code
is
actually
done.
But
yet
every
step
before
that
is
super
manual
and
takes
forever.
F
Yeah
well
so
a
good
example
is
infrastructure
as
code
in
that
space
that
you're
talking
about
so
a
lot
of
times,
companies
will
be
like.
Oh,
we
got
cd
automated
so
now
the
software
can
be
pushed
out
automatically
every
day,
and
then
someone
says
we
want
a
new
test:
qa
environment
like
okay,
it's
gonna
take
us
four
weeks
to
build
that.
Well.
Why?
Because
the
environments
aren't
built
in
code,
so
humans
are
gonna,
have
to
sit
around
and
spec
it
and
go
back
to
the
old
craft
of
how
we
used
to
build
physical
systems.
F
And
so
then
you
find
out.
Oh
there's,
this
whole
area
of
infrastructure,
automation
that
should
also
be
reduced
to
automation,
and
so
that
would
be
an
example
where,
once
you
got
cd
done,
you
think
you're
done
and
then
all
of
a
sudden
you're
like
wait,
but
whenever
we
need
a
new
environment,
we're
back
to
handcrafting
or
if
we
have
a
disaster
recovery
scenario,
we
need
to
set
a
production
in
a
different
region,
we're
back
to
handcrafting
and
we've
inherited
all
the
challenges
that
the
pre-automation
world
had
because
we're
we're
still
in
the
craftsman
phase.
F
L
Hi
great
presentation:
what
recommendations
might
you
have
for
assessing
the
transformation
in
limits?
You
had
a
slide
that
covered
deep
know-how
extraction
and
I
would
see
like
maybe
even
being
able
to
unpack
those
russian
doll
examples
and
be
able
to
maybe
have
some
better
practices
for
extracting
deep
knowledge
into
automation,
and
sometimes
we
reward
the
craftsmanship
of
the
developer
teams
instead
of
taking
those
opportunities
to
really
take
the
time,
yeah
refactor
and
so
do
you
have
any
recommendations
for
like
how
to
assess
that
or
candidates
for.
F
Yeah,
there's
something
yeah
there's
something
called
the
do
nothing
script.
Let
me
just
see
here:
yeah,
there's
a
blog
article
by
dan's
clemenson
called
the
do
nothing
script,
the
key
to
gradual
automation.
I'll
just
put
it
here
in
the
chat.
What
this
does
is
you
write
a
script
and
the
script
initially
just
outputs
human
go.
Do
this
human
go?
Do
this
human
go?
Do
this
human
go?
Do
this?
So
just
it's
like
outputting
a
checklist
and
then,
as
the
person
who
has
to
do
this,
gets
really
irritating
with
being
told
about
the
computer.
F
F
I
used
to
encourage
people
what
I
called
the
the
19
minute
rule
if
you're
learning
some
new
skill
and
someone
asked
you
to
do
something,
even
if
it's
a
fire
drill,
if
you
take
19
minutes
and
try
to
do
it
the
same
way
or
the
new
way,
no
one
will
notice.
If
you
fail
at
the
end
of
it,
you
just
throw
it
away
and
you
do
it
the
old
way.
F
But
if
you
succeed,
you
actually
in
the
pressure
of
real
world,
get
the
practice,
and
so
it's
another
similar
concept
as
far
as
humans
learning
skills,
but
as
far
as
actually
automating
do
nothing
script
or
something
similar.
The
other
thing
is
checklists.
So
when
I
worked
with
our
gitlab
instance,
we
had
we
had.
We
had
our
own
thing
like
terraform,
we
built
internally
and
we
automated
the
gitlab
stand
up.
We
could
stand
up,
git
lab
and
then
get
lab
dev
one
dev2,
dev,
3,
dev4
and
then
prod
all
the
same
automation.
F
So
you
can,
and
in
get
lab,
though
we
we
count,
how
many
check
boxes
are
in
an
issue
or
merge
request
to
tell
you
how
many
out
of
how
many
are
completed.
So
you
can
start
using
this
as
a
getting
people
to
reduce
their
human
practices,
which
are
not
automated.
Two
checklists,
which
I
make
the
case
in
the
article
series,
are
just
human
code.
A
checklist
is
something
a
human
must
do
in
this
order
in
and
do
one
after
the
other.
So
it's
just
it's
just
code
for
humans
to
follow.
F
So
if
you
make
them
do
checklists
where
they
don't
have
code,
then
they
also
get
sick
of
it,
but
they're
also
prepped
for
it,
because
that
checklist
is
guess
what
turn
that
into
a
routine
turn
that
into
a
routine
and
you
can
go
down
as
far
as
a
pre-assessment.
I
don't
know
it
it's
hard.
I
guess
I
would
encourage
you
to
start
doing
it
and
get
metrics,
because
who
knows
how
deep
it
is
at
any
given
organization?
A
lot
of
it
will
depend
on
the
coding
culture
hiring
practices.
F
F
L
L
What
is
git
lab
doing
to
also
get
vendors
to
incorporate
some
of
their
tooling
into
the
platform.
F
Okay,
so,
first
of
all,
if
you
go
to
our
sas
scanning
page
right
today,
you
can
see
that
here's,
the
format
we
used
to
upload
vulnerability
findings.
You
can
take
your
favorite
tool
and
use
something
like
xslt
translation
to
take
its
output
and
put
into
that
format.
F
And
then
you
just
say:
hey
collect
this
as
a
artifacts
reports
fast,
and
you
write
today
in
about
in
a
short
amount
of
time,
can
take
your
favorite
scanning
tool
and
upload
it
into
gitlab,
and
we
tell
you
also
there's
a
special
document
how
to
plug
in
your
own
scanner
so
that
extensibility
from
a
developer
sitting
down
is
there
already
this
last
year.
Git
lab
is
investing
in
the
channel
big
time
we're
getting
channel
essays.
F
We
are
really
pushing
forward
on
this,
so
one
of
those
points
is
even
security,
competing
security
scanners
having
plug-ins
that
can
plug
in
because
you
might
prefer
a
certain
one
or
need
a
certain
one
because
of
regulatory
or
whatever
gitlab,
although
it
provides
some
opinionated
approaches
and
some
default
tools,
it's
also
a
solution,
that's
sort
of
platformish
and
that
you
can
plug
things
in
but
we're
pursuing
the
channel
directly.
You
can
do
the
integrations
yourself
today,
even
if
your
channel
partner
doesn't
do
them
if
it's
happening
on
a
container.
F
Today
I
did
a
live
coding
event.
Another
solutions,
architect
and
I
do
us
a
live
coding
event
every
other
friday
and
we
converted
github's
super
linter
to
run
under
git
lab
in
about
an
hour
and
a
half,
and
that's
because
we
were
stumbling
around
trying
to
figure
out
how
to
do
it.
That's
what
live
coding's
supposed
to
be.
I
guess.
L
Is
that
how
do
you
get
up
on
get
involved
in
those
the.
F
No
it's
right!
Now,
it's
just
off
my
personal
blog
mission,
impossible
code,
dot
io!
You
can
go
there
and
there's
a
blog
post.
Some
of
us
just
do
this
kind
of
stuff
on
the
on
the
side,
but
right
now
we're
talking
only
about
give
up
ci.
So.
G
The
question:
how
does
this
automation
that
we
went
over
here,
differentiate
from
bitbucket
or
github,
that
other
providers
offer.
F
Yes,
so
with
bitbucket
bitbucket
is
just
doing
source
code
management.
One
of
the
things
is
because
gitlab
has
embraced
git
ops,
which
means
you
now
do
your
ops
through
git
right.
F
We
have
had
to
extend
the
normal
merge
request
approval
process
so
that
it's
much
richer,
so
you'll
find
that
we're
we're
pushing
the
envelope
on
the
ability
to
merge
code
and
what
kind
of
controls
you
can
have
around
that
there
is
a
video
out
there
on
git
lab,
unfiltered,
called
rich
change
controls
to
build
workflows.
You
can
trust,
so
you
can
see
on
the
scm
side
how
we're
building
a
very
strong
idea
of
many
ways.
You
can
approve
code
all
this
stuff
that
we
talked
about
today.
F
F
Github
is
just
starting
to
get
ci
with
something
called
github
actions,
which
is
handy
some
of
the
challenges
with
it.
Github
actions
are
kind
of
there's
an
open
source
aspect
to
them,
where
anybody
can
throw
a
plugin
up
there
and
your
developers
can
pick
it,
and
so
that
gets
you
back
to
a
similar
stage
with
jenkins
plug-ins,
where
developers
just
arbitrarily
pick
some
plug-in,
they
don't
care
who's,
making
it
that
person
gets
bored
of
making
it
or
maybe
there's
malicious
code
in
it.
F
They
haven't
taken
time
to
look
through
it,
so
we
don't
like
to
be
quite
as
enabling
right
now
of
you
just
picking
like
random
community
stuff
into
your
production
ci.
We
prefer
that
you
would
you
would
you
would
actually
take
and
curate
code
that
you're
gonna
start
using
in
ci
and
then
github
is
we're
very
similar
to
github
in
terms
of
some
of
the
capabilities
that
it
has.
As
far
as
we
both
get
collaborative
portals
is
the
heritage
of
it.
F
When
you
get
into
aws
code
commit
it
gets
a
lot
more
challenging,
there's
a
lot
less
graphical
features
and
a
lot
more
just
a
bunch
of
primitives
that
you
have
to
kind
of
assemble
together.
Was
there
other
aspects
of
it
that
you
were
interested
in
understanding,
better.
G
Yeah
yeah,
just
you
know,
from
a
security
standpoint
you're
looking
at
a
pipeline
where
you
can,
you
know
we
can
automate
it
run
your
test
scripts
and
run
securities
tools
like
better
code
or
any
other
tools
we
can
plug
in
and
it
spits
out.
You
know
report.
F
Yeah
so
gitlab
comes
with
something
called
autodevops,
which
I
don't
personally
like
the
name,
because
it
implies
something,
that's
simplistic
and
that
might
not
apply
if
you
have
very
specific
things,
but
underneath
autodevops
is
that
componentry.
I
was
talking
about
all
of
our
scanning
componentry,
and
so
you
can
get
in
there
and
plug
in
sas
scanning
secret
scanning.
You
can
plug
in
all
of
it
very
fairly
quickly
and
get
it
operating
when
you
start
adding
third-party
bits,
like
other
tooling,
that
submits
to
say
a
tenant
to
do
some
scanning,
then.
K
If
you
were
to
go
back
to
the
first
time,
you
did
this
type
of
transformative
journey,
you
know
what
would
you
do
differently,
knowing
what
you
know
now,
based
on
where
technology
has
gone,
you
know
the
importance
of
things
like
docker
and
kubernetes,
and
you
know
if
you
had
a
crystal
ball
five
ten
years
ago.
What
would
you
have
done
differently?
You
know
with
that
information.
B
Great
question,
so
I
mean
just
to
correct:
we
are
still
going
through
this
journey,
so
one
of
the
things
that
I
keep
talking
about
and
it's
a
little
bit
of
a
philosophical
thing.
It's
the
idea
of
making
a
last
mile
impact
we
in
this
process
of
our
devops
journey,
which
we
are
currently
going
through.
We
were
fairly
straightforward
in
terms
of
automating
qa
made
total
sense
because
we
didn't
have
a
qa
department.
B
It
made
total
sense
to
sort
of
start.
You
know
incubating
and
holding
development
accountable
for
quality
sort
of
the
shift
left
approach
right,
injecting
quality
in
every
stage,
not
just
a
test
life
cycle
or
automating.
That
one
thing
that
we
did
not
do
very
well
is
benchmark
our
ci
or
benchmark
our
return
on
ci
at
the
early
stages,
where
it
took
quite
a
few
iterations
to
get
it
right.
B
Quite
a
few
iterations
to
sort
of
understand
where
we
want
to
go
and
to
darwin's
point.
One
thing
that
is
really
challenging
is
you
know,
getting
a
researcher
to
sort
of
really
think
distributed
source
control
if
he
or
she
is
designed
for
over
25
years
doing
file
based
commits
in
you
know
in
really
low
latency
cc,
plus
plus
code.
For
the
good
reason
I
mean
we,
we
can't
beat
the
speed
of
the
compute
grid
with
any
other
high-level
programming
language.
B
We
need
that
in
a
sense,
but
that
transformation
if
there
was
a
way
to
sort
of
advertise
in
a
better
manner,
especially
with
tools
that
sort
of
came
into
picture
later
into
the
phase,
and
I'm
still
you
know,
I'm
personally
a
big
fan
of
gitlab.
By
the
way
I
have
read
about
it.
I've
seen
your
I've
seen
your
work
in
certain
other
conferences
that
have
been
especially
the
qa
financial
forum.
A
lot
of
leaders
actually
in
this
domain
talked
about
your
tooling.
B
So
some
of
those
things
you
know
mitigating
risk
and
actually
measuring
our
benchmark
from
our
ci
process
could
have
made
a
little
bit
of
a
difference.
You
know,
but
again
we
are
also
a
very
close
neat
tight,
regulated
environment,
adopting
a
tool
set,
getting
an
nda
and
all
those
within
a
group
level
is
much
more
difficult
for
positioning
opposed
to
doing
a
greenfield
startup.
F
Just
wanted
to
clarify
questions
or
some
comments
in
the
chat
about
plugins
there's
a
little
bit
of
confusion
here
at
gitlab.
We,
we
don't
have
an
advocated
plug-in
architecture
and
some
of
the
problems
with
plug-ins
are
seen
in
jenkins.
However,
by
using
gitlab
ci
includes
and
a
container
with
proper
contents,
we
have
the
same
construct
and
that's
actually
how
we
build
up
auto
devops
and
you
can
build
the
same
thing
yourself
and
our
partners
can
build
the
same
thing.
That's
what
I
was
calling
pre
prefabricated
sub-assemblies.
F
So
you
should
be
aware
that
while
we
don't,
we
want
to
avoid
the
negative
connotations
of
jenkins
plug-ins.
We
have
a
concept
of
extensibility.
I
put
a
link
in
there
to
something
called:
guided
explorations
and
guided.
Explorations
is
an
area
of
our
website
with
tons
of
working
examples.
So
I'm
a
huge
advocate
of
people
learn
best
by
seeing
there's
the
code,
there's
what
it
built
and
it
works
right
now
and
I
can
grab
a
copy
and
play
with
it
myself,
and
so
that
one
subsection
of
that.
F
I
call
it
cic
plug-in
extension,
so
you
will
find
it
when
you're
searching
the
web
for
get
loud
extent
plug-ins,
because
we
have
something
very
similar.
When
we
say
we
don't
do
plug-ins
some
people
think
we
don't
have
an
extensible
architecture
that
lets
you
build
small
compact
components
that
can
be
reused
again
and
again
in
your
cs.
F
Anyone
have
any
experiences
that
mirror
the
things
that
were
talked
about
in
either
presentation,
horror
stories.
I
love
to
hear
horror
stories
because
you
always
hear
about
interesting
things.
You
never
thought
could
happen.
A
F
Yeah,
that's
a
that's!
A
culture
shift.
Isn't
it
it's
challenging
challenge
for
people
to
turn
the
corners
when
it's
time.
K
To
a
funny
story
of
vic,
I
think
you
mentioned
charles
schwab.
Eight
years
ago
I
actually
took
an
inbound
call
for
a
devops
software
company
that
I
was
working
for
from
us.
Someone
at
charles
schwab,
who
said
we
don't
even
know
how
to
spell
devops
they
they
started
this
journey
a
long
time
ago
and
it's
you
know,
they've
they're
still
going
through
it
they're
still
migrating
through
yeah.
B
With
the
financial
organization,
especially
the
fintechs,
you
do
get
into
the
bureaucracy
a
little
bit,
especially
if
you
read
the
news.
We
are
acquiring
a
business
which
is
six
times
bigger
than
us,
refinative,
which
is
coming
out
of
the
backstone
thompson,
riders
already
leaned,
but
not
lean
enough
for
us,
and
you
know
we
are
we.
We
need
some
adaptation
in
that
world.
You
know
people,
people
get
sort
of
protective
about
cost
synergies
and.
B
I
always
see
it
as
an
opportunity
for
for
for
lack
of
better
words
and
also
very
curious
to
see
how
the
whole
world
of
you
know,
especially
the
decentralization
of
banking
with
blockchain
and
the
whole
qubits
computing
would
bring
into
this
world.
I
think
it
would
drastically
change
and
the
roles
of
the
future
computing
and
in
the
software
industry
would
be
very
different
and
in
a
very
fast
rapid
manner
that
you
either
adopt
or
you
don't
get
to
grow.
F
Yep,
you
know
that
one
thing
we
didn't
talk
about
is
sometimes
the
culture
of
management
is
not.
It
is
the
the
breaks
on
the
situation.
If
there's
a
lot
of
approval
orientation
in
the
actual
management
culture,
then
you.
F
F
Anyone
struggle
with
adopting
devops
to
itil
type
situations
or
trying
to
look
at
itil4,
agile,
devops,
friendly.
F
F
Guess
not.
I
I'm
not
convinced
when
I
read
that
that
I
keep
get.
I
keep
digging
into
the
itil4
stuff
and
I'm
like
it
still
sounds
pretty
bureaucratic.
D
All
right
well
with
that,
I
want
to
thank
the
get
lab
team,
darwin
and
rick
for
today's
session.
Definitely
a
very
great
and
insightful
session
also
want
to
thank
avik
again
for
a
great
session
as
well.
I
think
everyone
here
had
a
had
a
great
time
and
definitely
discussed
their
challenges
and
issues
they're
currently
going
through.
D
So
thank
you
all
again
for
joining
us,
we'll
all
send
out
some
emails
and
some
surveys,
if
you
have
a
quick
moment
to
kind
of
fill
that
out,
that'd,
be
great
to
hear
your
feedback
from
the
event.
But
once
again,
thank
you
again
for
joining
us
to
look
forward
to
seeing
future
events.