►
From YouTube: How Shifting Left is Helping CapitalOne in its CICD Pro... Gokul Prabagaren & Nagesh Kumar Vinnakota
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
How Shifting Left is Helping CapitalOne in its CICD Process - Gokul Prabagaren & Nagesh Kumar Vinnakota, CapitalOne
CapitalOne is first U.S Bank to exit out of legacy on-premise datacentres and go all in cloud. On this journey we have completely re-innovated our software delivery and automated all our software delivery process. There are various key milestones to our CICD journey. This talk will focus on how adopting shifting left is helping us in our Software Delivery Lifecycle and Security
A
Hi,
this
is
nagesh
kumar,
vindakota
software
engineering
manager
at
capitalgun,
and
we
have
google
traffic
as
a
co-speaker
of
this
session.
First
of
all,
hardy
welcome
to
cdcon
2022,
and
thank
you
so
much
for
having
us.
Today
we
are
going
to
discuss
about
how
shifting
left
is
helping
capital
one
in
its
cicd
process.
A
A
We
have
also
couple
of
programs.
One
of
them
is
coders,
so
this
is
this
is
where,
like
we,
our
associates
will
work
directly
with
the
students
we
envision
a
world
where
every
student
succeeds
in
the
digital
age
and
builds
a
better
future
with
technology,
and
we
have
a
quota
program
where
we
look
for
the
college
students
who
are
planning
to
pursue
their
career
in
tech
or
software
engineering,
but
lacks
computer
science.
Our
degree
our
campus
teams
identify
such
top
talent
and
give
them
training
that
will
put
them
on
the
path
to
become
software
engineers.
A
Then
we
talk
about
security
and
the
patterns
that
we
have
used
as
part
of
our
pipeline
and
automated
functional
testing
and
how
we
have
started
early
stage
of
doing
testing
and
benefits
of
using
shifting
left
and
with
that.
We
will
also
do
a
curtain
riser
for
season
three,
and
we
will
leave
for
question
and
answers.
A
A
Although
it
worked
quite
well,
we
have
experienced
coordination
issues
between
these
teams
and
knowledge
gaps
where
teams
and
engineers
lack
complete
control
over
software
artifact
and
time
delay
in
deriving
quality
software
and
operationally
high
cost
maintaining
these
teams.
During
that
time,
we
followed
one
of
the
leading
linear
sdlc
methodology
for
building
software.
A
We
came
up
with
four
pillars
that
can
address
above
concerns
and
we
strive
to
create
software
solutions
faster
with
greater
quality
and
lower
operating
costs
that
can
meet
the
needs
of
customers
and
we
became
of
it.
You
build
your
own
policy
and
adopting
as
high
standards
migrating
to
cloud
and
devops
tools,
ubq
own
giving
developers
operational
responsibilities
has
greatly
enhanced
the
quality
of
the
services
both
from
the
customers
and
the
technical
point
of
view
at
capital.
One.
A
This
enabled
our
developers
to
become
more
involved
with
the
day-to-day
operations
of
the
software
systems,
and
then
we
started
adopting
it
as
I,
because
when
we
are
thinking
about
you,
will
you
own?
It
is
impossible
without
a
platform
or
standards
that
is
highly
flexible
and
we
have
adapted
to
as
well
best
practices
by
creating
a
self-organized
teams
and
building
iterative
development
and
conducting
entirely
standards
and
regular
retros
for
the
continuous
improvement
and
software
demos
for
the
transparent
transparency
and
to
keep
track
of
the
software
artifacts,
then
we
have
decided
to
focus
on
migrating
to
cloud.
A
After
a
series
of
continuous
improvements,
we
were
able
to
build
a
pipeline
that
adapts
to
shifting
left
practices.
So
what
is
shifting
left
we
are
talking
about
here?
It's
a
practice
to
find
the
defects
prevents
the
defects
early
in
the
software
delivery
process.
It
allowed
us
to
build
and
release
cost
effective
software,
much
quicker
with
a
greater
deal
of
quality
security
and
by
following
high
standards.
B
I
think,
with
the
context
whatever
mages
said,
with
the
whatever
we
discussed
in
previous
cd
and
all
those
details
and
how
we
started
our
journey
of
devops
and
the
first
place
where
we
have
gone
is
shifting
left
right
before
we
dive
into
the
details
of
how
we
have
adopted
capital
on
shifting
level.
Let's
quickly
see
what
really
shifting
left
is
my
view.
B
B
So
the
turnaround
time
for
those
kind
of
fixes
when
we
figure
out
something,
is
not
going
as
per
our
expectation
when
we
are
doing
those
things
in
development
phase,
it
is
pretty
easy
to
immediately
fix
them,
and
then
the
cost
of
the
ground
is
less.
So
that's
what
the
shifting
graph
pretty
much
means.
So
with
that
context,
let's
see
how
we
have
adopted
in
capital
on
the
shifting
left.
B
By
now,
you
probably
would
have
stored
like
with
the
journey
we
have
gone
through,
be
the
adopting
the
cloud
going
all
in
cloud
or
our
devops
journey
to
agile.
Whatever
right
we,
we
have
undergone
a
massive
transformation
in
our
organization
and
we
have
now
pioneered
the
devops
culture
across
our
enterprise.
B
B
That's
a
massive
field.
We
have
achieved
from
the
days
in
which
we
were
having
different
teams
not
talking
to
each
other
having
a
wall
in
between
from
there.
We
have
gone
long
day
and
then
now
most
of
our
software
delivery
happens
in
an
automated
day.
All
this,
where
possible,
mainly
because
of
the
investment
we
have
made
in
our
foundational
pillars
like
be
adopting
the
going
all
in
cloud
or
standardizing
our
pipeline
are
adopting
you
building
a
new
warning.
B
Those
are
all
the
foundational
pinders
on
which
we
are
right
now,
building
our
shifting
level
right,
so
we
have
adopted
shifting
left
in
various
places
to
call
a
few
things
on
top
of
our
foundational
pillars,
two
areas
where
we
are
focusing
today,
one
is
in
terms
of
security
and
other
in
terms
of
automated
functional
testing.
Those
are
all
the
places
where
we
see
a
major
lift
happening
for
us
in
adopting
the
shifting
left.
We
will
get
into
the
details
of
those
two
areas
in
upcoming
slides.
B
B
B
They
address
most
of
those
things
and
then
check
in
their
code
from
the
fourth
before
it
really
reaches
out
the
main
repo.
The
similar
process
happens
actually
in
our
cloud
environment,
not
in
the
security
scan
or
their
local
mission.
So
in
the
cloud
the
same
step
follows
and
then
we
take
care
of
those
issues
before
it
really
reaches
the
main
repo,
and
that
is
what
really
makes
it
to
the
production
this
all
these
things
happens
in
few
hours.
B
B
So
these
two
areas
when
it
comes
to
security,
we
have
adopted
shifting
left
and
we
do
see
a
major
benefit
out
of
that,
because
before
it
really
reaches
the
production,
the
hardened
code
only
goes,
and
there
is
no
way
we
can
really
get
any
of
the
record
into
the
production
and
that's
the
one
when
it
comes
to
the
security
on
the
similar
lines,
we
have
adopted
the
same
shifting
left
in
automated
functional
testing
or
any
any
forms.
We
can
call
this.
It's
pretty
much
automated.
B
So
all
those
things
written
in
the
feature
for
their
new
functionality,
whatever
they're
bringing
in
those
things,
are
executed
in
their
local
mission
and
then
in
case,
if
they
figure
out,
there
is
either
the
feature
is
not
working
as
per
the
expectation
or
whatever
written
in
the
functional
testing
feature
file.
So
then
developer
fixes
them
mainly
in
their
local
mission,
and
then
they
again
go
through
this
iteration
to
get
this
right.
If
you
see
the
turnaround
time
in
this
case
is
pretty
much
instantaneous,
they
they
found
a
problem.
They
address
it
immediately
in
case.
B
If
you
just
compare
this
something
which
has
gone
to
the
production
and
you
see
how
to
turn
around
those
kind
of
fixes,
you
have
to
go
through
the
cycle
again
again
right.
That
is
the
major
power
of
shifting
left.
So,
as
I
was
discussing
the
first
checkpoint
when
it
comes
to
the
automated
functional
testing,
they
execute
this
those
things
in
their
local
mission
and
then
they
fix
all
those
things
and
then
checking
the
code.
B
It
goes
through
the
similar
iteration,
but
in
our
cloud
environment,
and
that
is
our
second
milestone
or
a
checkpoint,
where
the
same
functional
testing
is
executed
to
ensure
all
the
functionality.
What
we
are
delivering
is
intact
and
it's
meets
the
expectation.
Then
we
take
that
pair
into
the
main
trip
one
that
hardened
code
is
what
actually
makes
it
to
the
production.
B
B
If
you
have
seen
from
my
explanation
of
typical
developer
journey
in
delivering
any
of
the
functionality
or
feature
to
a
customer,
the
turnaround
time
this,
we
were
discussing
the
previous
cases.
It
is
too
high
and
if
we
are
figuring
out
any
issue
which
is
closer
to
production,
which
is
not
actually
failing
early
right,
you,
you
probably
found
out
that
issue
which
is
very
closer
to
the
customer
touch
point.
But
by
adopting
shifting
left,
we
have
opportunity
to
fail
early
and
also
since
it
is
very
close
to
development.
The
turnaround
time
is
less.
B
B
Any
code
which
goes
through
this
situation,
if
you
are
adopting
shifting
left
and
if
you
are
addressing
those
things
in
the
development
phase
itself,
we
can
be
assured
that
majority
of
all
the
vulnerabilities,
any
of
the
library
which
brings
in
those
could
be
addressed
and
shifting
left
is
actually
the
way
to
do
that.
And
by
adopting
that
we
have
hardened
the
code
and
whatever
we
deliver
to.
The
production
is
pretty
much
taken
care
and
the
code
which
customer
really
uses
those
are
actually
secure
code.
B
So
this
way
we
are
able
to
achieve
a
lot
of
benefits
out
of
shifting
live,
which
is
actually
contributing
to
our
customers.
Experience
you
see
this.
Whatever
we
have
delivered
to
customer
with
security
and
the
functionality
which
is
meeting
the
expectation,
we
can
definitely
raise
your
bars
in
terms
of
customer
experience,
so
we
see
majorly,
shooting
glyph
is
actually
helping
us
to
deliver
this.
B
It's
pretty
much
the
standardization
and
abstraction
and
that's
what
our
goal
is
and
that's
what
we
are
actually
aspiring
to
be.
Those
two
terms
are
in
turn:
they
pretty
much
abstracted
itself
for
the
reason,
so
the
standardization
here
snagit
was
alluding
previously
in
this
contextual
slide
the
standardization.
We
have
actually
started
the
journey
years
ago
and
we
are
still
on
that
journey
because
it's
a
it's
a,
not
star
we
are
aiming
for,
but
the
standardization,
the
benefits
it
is
going
to
provide
its
humongous.
B
What
is
standardization
instead
of
each
and
every
team
or
group,
going
through
a
lot
of
customization
in
their
pipeline
or
in
their
adoption
of
any
of
our
platforms?
We
want
to
establish
a
standard
which
abstracts
them
from
all
the
intricacies
of
how
things
really
operate,
underneath
because
those
things
really
consumes
time
and
developers.
Time
is
precious,
so
we
don't
want
to
really
spend
a
lot
of
time
in
those
kind
of
really
customized
things.
B
Instead,
we
want
to
establish
a
standard
which
makes
developers
life
easy
and
deliver
customer
features
and
ship
codes
faster
so
that
we
can
really
deliver
whatever
things
which
customers
are
looking
forward
from
us.
So
we
see,
we
think
that
standardization
and
abstraction
is
actually
the
way
we
want
to
go
and
we
hope
industry
will
also
follow
so
see.
I
think
if
we
have
an
opportunity
in
later,
we
probably
will
explore
more
on
what
are
the
things
we
have
really
gone
through
in
our
journey
of
standardization:
abstraction
in
probably
upcoming
sessions.
B
Some
details
about
me
and
gokul
prabhas
engineering
manager
at
one
and
I
have
been
pretty
much
focusing
on
big
data
related
fix.
I
have
written
multiple
blogs
and
I
have
given
a
lot
of
tech
talks
around
the
same
area
and
I
have
provided
my
linkedin
and
twitter
handles.
If
you
are
interested,
you
can
hit
me
up
there
or
two.