►
From YouTube: The Impact of Continuous Delivery on Digital Transformations-T Jachja; J Jones; L Yeadon & E Chapman
Description
The Impact of Continuous Delivery on Digital Transformations - Tiffany Jachja, Harness; James Jones, Digital Turbine; Lindsey Yeadon, Red Hat & Eric Chapman, Liatrio
Speakers: Eric Chapman, Tiffany Jachja, James Jones, Lindsey Yeadon
For many digital transformations, challenges lie within change. There are cultural, procedural, and technical impacts on how we choose to transform our teams and organizations. Continuous Delivery is the part of CI/CD that enables software changes of all kinds to reach users safely and quickly, in a repeatable manner. But what are the impacts of focusing on Continuous Delivery, and how is the CD ecosystem serving as a foundation for digital transformations? Join this session as CD practitioners and providers share their insights into these questions. Attendees will hear about Continuous Delivery in the context of digital transformations.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
These
three
amazing
panelists
drive
change,
success
and
culture
across
teams,
industries
and
organizations,
and
so
I
would
love
for
them
to
be
able
to
share
all
of
their
insights
on
how
they
are
using
the
continuous
delivery
ecosystem
and
how
it's
helping
them
drive
digital
transformations
anyway,
I'd
love
for
everyone
to
get
the
chance
to
introduce
themselves
alphabetically,
but
before
that
I
do
want
to
mention
that
this
is
an
interactive
session.
So
please
ask
us
your
questions.
A
A
I
am
also
the
continuous
delivery
foundation
outreach
committee
chair
this
year,
so
I'm
so
excited
to
be
having
these
three
amazing
people
join
us.
If
bob
would
like
to
kick
us
off,
please
tell
us
more
about
what
you
do
at
digital
turbine
and
how
are
you
shaping
devops
culture
and
values
across
organizations
and
within
your
team.
B
B
B
It's
it's
pretty
interesting
and
I'm
not
sure
if
it's
specific
to
the
way
that
we,
the
the
software
that
we
do,
but
it
would
really
be
interesting
to
see
to
hear
from
you
guys
as
well
some
of
your
experiences
with
this
specific
way
of
operating,
but
in
terms
of
influence.
It's
really
just
like
right
now
we're
going
through
this
big
transformation
like
we
don't
know
what
tools
to
use.
B
One
of
the
biggest
challenges
that
we
have
right
now
is
that
some
of
the
software
that
we
write
is
is
firmware,
and
it's
very
interesting
because
our
release
cycle
is
once
basically,
we
have
to
do
once
a
quarter
because
of
the
devices
that
we
we
pair
with.
So
how
exactly
do
we,
you
know,
do
a
digital
transformation.
How
do
we
do?
How
do
we
do
continuous
delivery
with
something
like
that?
And
it's
it's
a
pretty
huge
challenge,
but
that's
that's
me.
A
Yeah,
I
love
that
and
thank
you
for
sharing
more
context
into
how
continuous
delivery
is
also
bleeding
into
not
just
the
software
industry,
but
also
firmware
or
hardware,
and
I
think
that's
really
interesting
and
something
that
we've
been
seeing
in
the
devops
space
as
well.
I'd
love
to
turn
over
to
eric
and
let
us
know
what
you
do
at
leatrio.
C
C
The
talk
today
is
super
exciting
for
us
how
we
help.
Specifically,
we
cover
the
gambit
from
advisory
strategy,
helping
form
where
teams
are
going
and,
more
importantly,
hands-on.
Keyboard
engineering
help
as
well.
So
well,
we
used
to
say
where
the
boots
on
the
ground
that's
sort
of
in
a
different
turn
when
starting
2020
but
boots
on
the
ground,
both
physically
and
and
virtually.
C
However,
the
environment
may
be,
I
would
say,
our
superpower
and
where
I
think
would
really
is
important
and
delivery
is
enablement
and
really
understanding.
So
the
the
technology
always
says
the
fun
and
easy
part,
but
really
it
doesn't
matter
what
technologies
you
use.
If
you
can't,
you
know,
actually
deliver
your
software,
deliver
your
your
value,
your
ideas
out
faster.
So
that's
that's
sort
of
where
we,
where
we
shine
but
yeah
great
to
be
here.
D
All
right,
hi
everyone
I'm
lindsay
yaden.
I
am
an
agile
transformation,
lead
with
open
innovation,
labs
at
red
hat.
I've
been
here
for
almost
two
years
and
I
really
do
enjoy
what
I
do
at
red
hat.
I
was
brought
in
about
two
years
ago
to
help
build
out
our
transformation
product.
We
really
weren't
sure
as
a
part
of
open
innovation
labs.
We
had
a
residency
model,
we
weren't
really
sure
kind
of.
D
What's
next,
we
knew
there
was
a
step
and
that's
one
reason
that
myself
and
some
other
transformation
leads
were
brought
on.
Is
that
okay?
What
now
I
had
done
transformations
as
most
of
them?
I
will
be
honest,
failed
and
one
of
the
biggest
reasons
is
because
I
am
more
on
the
process
side.
So
when
I
say
I'm
an
agile
transformation
lead,
I
know
technology.
D
What
I
say
is,
I
know
enough
to
be
dangerous,
not
to
be
helpful.
I
am
pretty
much
on
the
ways
of
working
and
the
organizational
change
and
the
process
side
of
it.
So
that's
where
I
have.
I
worked
previously
with
different
organizations
to
help
them
transform
and
I'll
be
honest.
Like
I
said,
most
of
them
were
not
successes
and
that's
one
of
the
reasons
why
I
really
liked
red
hat
is:
is
that
it
marries
process
with
technology
where
process
can
ebb
and
flow
technology.
D
You
need
to
have
it
anchored
there
and
that's
really
where,
when
we
talk
about
digital
transformation
and
just
transformation
in
general,
you
have
to
have
both
the
process
side
and
the
technology
side.
So
to
me
you
know
continuous
delivery
goes
hand
in
hand
with
a
long-lived
and
successful
transformation.
I've
been
in
this
space.
I
was
just
looking
at
my
resume
and
calculating
the
number
of
years.
I
was
like.
D
Oh
it's
been
about
10
years
now
it's
been
about
15
or
so
working
in
technology
and
project
management
and
then
within
the
last
10
years,
really
specializing
in
that
agile
space.
Well,
now
yeah
10
to
12
years
and
then
really
in
the
last
about
seven
years,
focusing
on
transformations
that
it
was
great
to
kind
of
get
the
agile
word
out
there.
Okay.
Now?
What
do
you
do
with
this?
D
Now
that
people
had
an
understanding
of
agile
and
scrum
and
some
of
those
and
even
some
of
the
scaled
frameworks,
it's
now
really
about
okay,
how
do
we
change
all
of
our
ways
of
working?
How
do
we
kind
of
take
some
of
these
principles
and
go
to
the
next
level?
And
that's
really
where
I've
been
focused
the
last
five
to
seven
years
and
and
love
it
and
love
so
much?
You
know
that
we
are
pairing
it
with
process.
So
it's
not
just
process.
A
I
love
that
I
love
where
you
brought
in
this
concept
of
long
live
long,
long,
living
or
everlasting
digital
transformation,
because
things
do
change
right,
that's
the
nature
of
technology,
and
I
would
love
to
get
into
that
some
more.
I
do
want
to
jump
into
the
heart
of
this
conversation
and
the
first
question
that
I
have
for
you
all
today,
and
this
touches
on
the
really
outcomes
that
organizations
are
trying
to
achieve
today.
A
So
we
know
that
many
organizations
today
are
trying
to
achieve
better
software
delivery
faster,
and
this
is
why
we
see
things
like
get
ops
and
all
these
practices
really
emerging
today
and
why
we
even
have
cd
foundation
hosting
this
annual
event
around
cdcon
right,
and
so
my
question
goes
around
process
as
well.
So
how
do
you
prepare
organizations
for
change?
And
how
do
you?
How
do
you
get
them
so
that
they
are
in
this
right
head
space
of
being
able
to
tackle
some
of
the
challenges
that
are
associated
with
improving
their
processes?
A
B
I
mean
this
is
the
hardest
thing
right
when
I
think
of
digital
transformation.
It's
it's
not
necessarily
technology,
it's
changing
people's
minds,
so
you've
really
gone
through
a
transformation
when
people
start
thinking
a
completely
different
way
and
at
least
in
the
experience
that
I've
had
the
hardest
part
with.
That
is
gaining
trust.
It's
establishing
trust,
establishing
those
relationships
and
and
honestly
that
can
make
or
break
the
whole
initiative.
B
I've
seen
in
a
different
example
at
a
startup
that
I
work
at,
they
were
able
to
to
come
in
and
actually
say,
hey
like
look
look
at
all
this
measurable
pieces
of
data
that
we
can
actually
go,
and
I
started
these
small
like
increments
of
of
change,
and
then
people
started
to
actually
think.
Oh,
I
can.
I
can
make
this
change
and
deliver
it
to
my
customers
really
fast
and
slowly.
We
built
trust
to
the
point
where
we
could
actually
really
start
changing
the
way
people
thought
about
delivering
software.
D
And
yeah,
when
you
talk
about
culture,
I
mean
that's
everything
and
kind
of
how,
when
I,
when
I
first
earned,
you
know
engaging
with
a
company
and
typically
the
very
first
time
that
you're
engaging
it's
with
executives,
it's
with
people
that
are
like,
okay,
that
we
you
know,
we
see
a
need
for
a
change,
and
so
I've
gone
in
and
and
I've
and
I've
told
him
it's
like
listen.
You
know
we
can
do
this.
This
is
gonna,
be
a
long
journey.
It
is
not
something.
That's
just
gonna
happen
overnight.
D
It's
not
going
to
you
know
we're
not
going
to
be
able
to
affect
change
and
the
in
the
way
that
you
want
it
to
be,
and
they
can
come
down
on
high
and
say
all
right.
This
is
what
we're
doing
now
and
just
kind
of
spell
it
out,
but
then
that's
just
going
to
create
churn,
create
turmoil
and
that's
going
to
fracture.
D
So
if
you
look
at
something
like
a
startup
that
you're
talking
about
and
I've
been
lucky
to
work
with
some
great
startups
and
they're
hungry
they're
ready
for
change
and
they're
ready
for
knowledge,
and
it's
just
like
all
right-
let's
you
know,
let's
kind
of
do
all
these
things.
One
of
the
bad
things
is
that
let's
do
all
these
things
at
once.
Well,
you
can't,
in
order
to
be
able
to
turn
in
the
correct
direction,
you
need
to
have
small
changes.
D
You
know
that
kind
of
gets
you
in
the
way
to
go
otherwise,
you'll
just
be
kind
of
going
in
circles
chasing
yourself.
You
know
with
that
rudder
with
every
little
change,
and
then
you
look
at
some
of
these
other
larger
organizations
like
one
I'm
working
with
now
and
bob
you
had
the
luxury
of
working
with
them
as
well,
they're
a
huge
corporation.
D
It
is
going
to
take
time,
but
don't
give
up.
You
know,
let's
put
in
that
effort.
Let's
start
those.
You
know
start
those
discussions
start
those
things
and
then
once
we
start
going,
you
know
down
one
direction.
We
may
see
that
we
need
to
change
a
different
direction
too.
So
it's
you
know.
That's
one
thing
is
that
I
always
ask
like
we
have
to
be
ready
to
embrace
change,
but
then
to
make
sure
that
we're
not
changing
too
much
either,
because
then
that's
when
you
can
have
the
circle
effect.
C
C
First
of
all,
it's
important
to
gain
the
visibility
of
what's
going
on
so
using
value
stream,
mapping
and
value
stream
management
to
visualize
the
flow
across
the
continuum,
and
you
can
you
can
you
can
narrow
that
in
as
as
small
or
as
large
as
you
want
to
go,
but
letting
that
drive
the
direction?
You
know
you
sort
of
alluded
to
kind
of
having
some
north
stars
and
some
things
you
want
to
focus
on
lindsay.
So
like
the
value
stream,
let
the
ground
reality
of
where
the
pain
points
are
drive.
C
D
C
Transformation
and
agile
transformation,
this
point
of
devops
transformation.
All
of
those
words
are
undergoing
semantic
diffusion.
I
think
marcus
martin
fowler
rather
coined
the
terms
where
you
know
the
longer
they're
around
the
the
the
less
you
know
they
get
watered
down
right.
So,
as
lindsey
alluded
to
like
following
some
difficult
or
transformation,
they
haven't
delivered
the
promises,
you're
sort
of
either
coming
behind
the
things
or,
if
you're
lucky
enough
to
bet
at
the
beginning,
you
sort
of
get
this
honeymoon
hall
pass
of.
C
These
are
what
we're
going
to
do,
but
without
measurable
metrics
and
outcomes.
To
say
like
this
is:
what's
going
to
be
accomplished,
I
think-
and
that's
that's
a
difficult
thing
to
to
cover,
but
I
think
setting
those
up
is
key
and
the
last
part,
probably
even
before
the
metrics
is
just
setting
expectations.
Just
like
lindsey
was
saying
this
is
a
marathon.
You
know
this
is
this
is
not
going
to
happen
overnight,
but
yeah
just
being
up
for
the
long
haul,
and
you
know
how
do
you
build
the
community
around?
C
A
Awesome,
I
love
that
insight
and
about
having
a
north
star
right
being
able
to
focus
on
those
outcomes
because
it
may
take
you.
You
know
it's
not
the
snap
of
the
fingers.
It
may
take
you
several
months,
if
not
years,
to
get
to
where
you
want
to
be,
and
I
think
that
really
does
speak
to
the
evolution
and
just
sort
of
the
nature
of
devops
as
well.
Is
that
we're
incrementally
improving
and
every
day
we
can
introduce
new
ways
of
working
or
improve
our
processes
over
time,
and
I
really
really
love
that
takeaway.
A
I
am
curious,
like
how
do
you
balance
these
organizations
that
really
want
to
innovate,
and
maybe
you
know
throw
in
new
technologies.
Try
service
mesh
go
into
these
new
emerging
bleeding
edge
technologies
almost,
and
how
do
you
balance
that,
with
the
stability
and
the
repeatability
of
software
delivery.
D
So
I
I'm
just
gonna
I'll
start
off
that
and
and
before
you
even
said
the
word-
innovation,
I'm
like
oh
innovation-
time
like
you
have
to,
but
then
how
do
you
kind
of
do
the
business
as
usual
keep
the
lights
on,
while
still
being
able
to
balance
out
with
innovation
time?
I
have
been
lucky
enough
to
work
at
two
of
the
companies
one.
I
was
working
on
in
agile
transformation
and
it
was
a
smaller
company,
so
it
was
only
about
six
seven
hundred
employees
total
and
about
well.
D
D
I
mean
not
cobalt,
not
that
far
back,
but
it
was
you
know
if
you
can
just
imagine
this
kind
of
clunky
type
thing
and
then,
as
we
fixed
it,
it
was
just
kind
of
putting
you
know
more
more
band-aids
putting
more
pieces
on
it.
But
it
was
this
huge.
You
know
monolithic.
You
know
legacy
type
code
and
it
was
literally
putting
you
know,
lipstick
on
a
pig
or
band-aids
on
it.
D
You
know
gushing
wound
that
type
of
thing
and
it
was
like
we
were
always
struggling
to
like
how
do
we,
even
how
can
we
even
think
about
doing
something,
more
cutting
edge,
more
innovative,
innovative,
innovative
with
this,
while
we're
still
having
to
do
all
these
other
you
know,
improvements
just
to
you
know
has
business
as
usual,
so
this
is
where
we
ran
two
week
sprints
and
we
ran
them
wednesday
to
thursday.
So
so
thursdays
were
kind
of
our
sprint
ceremonies.
Our
you
know
all
of
our
scrum
ceremonies,
all
that
kind
of
stuff.
D
We
would
do
that
and
we
would
release
you
know
that
evening.
That
was
the
way
that
we
could
do
it.
That
was
the
downtime
that
we
had
to
have
and
that
we
have
the
agreement
upon
so
okay,
so
we
ran
it
that
way.
So
the
idea
was
is
that
friday,
after
we
had
our
release,
that
was
innovation
time
you
could
do
whatever
you
wanted
to
that
way.
It
was
completely
self-organized.
D
The
only
thing
that
we're
going
to
ask
is
that,
as
a
part
of
our
normally
scheduled
sprint,
demos
or
sprint
reviews
is
that
once
a
month,
so
every
other
one
you
share
what
you
have
been
doing,
and
then
we
had
a
regular
cadence.
So
it
was
like
you
can
have
this
time
to
do
whatever,
and
this
was
the
way
that
they
could
look
at
new
technologies.
All
of
a
sudden,
somebody
came
up
with
an
idea
using,
I
think,
docker
and
rancher,
and
to
where
they
actually
took
some
of
that.
D
A
piece
of
that
monolith
monolithic.
You
know
legacy
system
and
actually
broke
it
down
into
some
microservices,
and
then
you
know
using
containers
and
all
that
kind
of
stuff
and
they
presented
it
was
like,
oh,
my
goodness,
and
it
was
like
okay.
We
can
do
this.
Well
guess
what
now
we
can
start
even
planning
that
we
could
do
something
else.
D
Maybe
we
need
to
look
at
two
days,
so
that
really
is
something
that
kind
of
got
people's
juices
flowing,
and
there
were
so
many
fantastic
things
that
were
able
to
come
out
of
that
and
that
it
just
inspired
the
people
there
too
and
to
wanting
to
do
better,
and
then
it
grew
out
of
the
it
organization
that
then
we've
asked
them
to
partner
with
people
in
the
business
like
go
on,
go
out
and
actually
talk
to
your
potential
customers
find
out
what
they
need.
So
then
we
had
people
that
were
on.
D
You
know
the
the
calls
we
had
a
call
center
and
everything
else,
but
they
were
using
our
legacy
system.
They
would
actually
come
in
and
they
would
start
presenting
during
our
demos
and
they
would
be
like
yep.
We
did
this
and
it
was
awesome
and
then
at
another
company
we
ran
safe.
So
there
is
technically
there
are
supposed
to
be
built
in
time
for
innovation
and
planning.
If
anybody's
ever
done
it.
You
know,
that's
the
last
thing
that
gets
pushed
off
and
we
were
seeing
that
again
and
so
our
you
know
our
ceo.
D
He
was
like
we,
you
know
we
want
to
do
eight.
Was
it
four
four
sprints,
so
eight
eight
weeks
pis,
that's
what
he
wanted.
I'm
like.
Okay,
I'm
like
well
what
about
this
innovation
and
planning
he
was
like.
Well,
we
just
have
you
know.
We
have
all
these
deadlines.
We
need
to
get
something
like,
but
this
is
huge
and
he's
like
all
right.
You
give
me,
you
know
you
give
me
two,
you
give
me
two
back-to-back
pis
I'll,
give
you
a
pi
and
it's
like.
D
What
do
you
mean
you'll,
give
me
a
pi
and
he
goes
I'll.
Give
you
an
entire
pi
to
go
eight
weeks
and
he
was
like
yes
and
I
go
for
what
he
goes
innovation
to
do
whatever
you
know
the
dev
teams
want
to
do
and
I'm
like
are
you
sure,
and
I
was
like-
I
need
this
in
writing.
He
goes
hold
on
no,
so
he's
like
I'll
do
four
weeks,
we'll
do
four
we'll
do
a
half
an
iteration,
so
two
and
then
you
know
four
weeks
for
them
to
do
so.
D
That's
an
entire
month
in
that
month
of
time
we
saw
an
absolute
reduction
in
the
number
of
bugs
like
it
was
in,
but
then
they
were
able
to
put
things
into
place,
the
the
ownership
that
the
devs
then
felt
on
the
code
that
they
were
delivering.
Even
if
they
hadn't
been
the
initial
people
to
touch
it
was
insurmountable
and
they
all
of
a
sudden
we
went
from
you
know
it
was.
It
was
a
company
that
did
nursing
simulations.
D
We
went
to
just
being
able
to
interact
with
one
patient
to
where
we
could
interact
with
multiple
patients.
This
was
all
new
technology
that
came
out
of
this
innovative.
You
know
time
that
was
dedicated
just
for
that
and
allowing
them
to
work,
and
then
it
was
oh,
my
goodness
so
then
we
were
able
to
spit
it
right
back
into
the
next
products
that
we
were
doing
for
the
next
bi
and
just
seeing
people
grow,
and
that
was
that
was
fantastic.
And
then
it's
it's
that
balance.
D
So
you
have
to
find
that
balance,
but
if
you
can
show
get
just
get
that
one
thing
that
will
allow
you
to
kind
of
see,
you
know
the
new
technology
and
being
able
to
do
that
will
show
the
need
for
time
to
be
able
to
do
that
that,
yes,
we'll
still
do
the
business
as
usual
and
we'll
keep
the
lights
on.
But
we
have
to
you
know,
allow
for
some
of
that
innovation
too.
B
Yeah,
there's
there's
so
many
different
things
I
want
to
like
touch
on,
but
but
the
one
of
the
failures
that
I
was
a
part
of
at
the
big
financial
institution,
the
the
way
that
innovation
sort
of
happened
so
there's
there's
business
as
usual.
Innovation
and
this
company
had
you
know
multi-billion
dollar,
almost
a
trillion
dollar
company.
They
have
successes
right,
there's
a
lot
of
innovation,
they
do
it
business
as
usual
and
then,
when
we
add
something
you
know
when
they
want
to
bring
things
out,
you
know
faster.
B
What
they
would
typically
do
is
they
would
hire
a
bunch
of
a
bunch
of
consultants,
they
would
say
hey.
I
can.
I
can
throw
100
200
people
at
this
problem
and
we'll
get
it
out
faster,
and
you
know
they.
They
had
this
really
interesting
idea
of
like
moving
things
to
the
cloud
and
they
wanted
to
come
up
with
this
new
set
of
products
and
offer
it
they
wanted
to
capture
a
whole
different
market
segment
or
business
segment.
I
guess
you
could
say
like
small
to
medium
businesses.
B
I
can't
get
too
much
into
the
details,
but
they
ended
up
hiring.
I
don't
know
two
to
three
hundred
people
maybe
total
to
to
do
it
and
it
was.
It
was
a
big
failure
and
I
think
a
lot
of
it
had
to
do
with
with
the
mindset
right.
People
didn't
have
experience
with
doing
devops
people
didn't
have
experience
and
not
only
that
they
engaged
like
40
different
teams.
So
we
had
the
existing
organizational
structure
of
this
company
that
sort
of
played
into
it
and
what
was
really
interesting
with
what
what?
B
What
lindsay
was
saying
was
that
it
didn't
seem
like
you've
had
those
organizational
structures
to
sort
of
you
know
like
you
kind
of
broke
down
those
walls
of
the
silo
in
some
ways
in
order
to
make
those
changes
into
in
order
to
move
forward.
But
but
I
consider
that
a
failure,
because
the
promise
was,
is
that
we
were
going
to
be
able
to
deliver
this
prototype
to
the
market
faster
than
the
au.
But
it
was
never.
It
was
actually
slower
and
way
more
expensive
and
it
all
had
to
do
with
the
personnel
yep.
C
Also,
just
two
quick
points
for
me
to
add
a
lot
of
rich
insight.
There
really
two
two
things.
I
think
one
really
just
sum
up
what
both
lindsey
and
bob
said
is
really
the
need
for
creation
of
margin
and
space
for
engineers
to
innovate
safely
and,
and
that
take
that
literal
as
much
as
you
can
say,
on
margin
and
space.
A
C
Then
the
the
other
part
and
this
sort
of
touches
on
what
bob
was
saying
is
the
you
know
using
the
modular
design
patterns
and
things
like
that
that
that
you
officially
think
about,
like
marker
service
design,
pattern
file,
factor
app
use
those
on
your
platforms
as
well.
To
get
back
to
your
question,
tiffany
asked
about
how
you
can
ingest
new
technologies,
don't
have
to
reboot
everything.
C
If
you
build
even
your
pipelines
and
your
pipeline
components
like
you
know,
we
we've
seen
a
lot
of
success
like
purpose-built
containers
to
back
pipelines.
So
what
that
would
mean
would
be
you
know
for
something
like
static
code
analysis
you'd
have
a
container
that
just
does
that
and
that
way
when
you
want
to
switch
out
your
tool
for
sas
or
scanning
or
whatever
the
case
may
be
you're
just
changing
one
container,
not
impacting
the
whole
entire
flow
of
the
pipeline.
A
Yeah,
thank
you
so
much
eric
for
recapping,
some
of
the
really
big
core
concepts
in
there
that
lindsay
was
sharing
and
bob
was
sharing
through
their
experiences
right,
and
I
love
the
idea
that
we're
building
in
time
for
innovation,
because
that's
so
important,
like
we've
seen
amazing
technologies,
come
out
of
the
space
from
people
innovating
like,
for
example,
google.
They
have
their
fridays
off
right
and
from
that
people
have
started
really
amazing
technologies
and
kubernetes
was
one
of
those
too,
and
so
we
can.
A
That
really
goes
to
speak,
like
links
about
what
it's
like,
creating
a
safe
environment
for
people
to
be
able
to
innovate
and
try
these
new
things
right
and
in
a
way
where
it
doesn't
lead
to
failure
right.
This
thing
where
it's
like
wow,
we
invested
so
much
time
into
innovating
that
we
somehow
missed
the
mark
on
actually
delivering
what
it
is
that
we
had
set
out
to
deliver
right.
So
I
think
that's
really
important,
and
I
love
how
you
brought
in
ci
cd,
because
that's
actually
my
follow-up
question.
A
I
know
we're
wrapping
up
here,
but
my
final
question,
for
you
all
is:
where
do
you
see
organizations
shifting
towards
in
terms
of
your
digital
transformations?
Where
is
the
focus
today
and
where?
What
are
what
are
some
takeaways?
That
organizations
can
use
to
be
able
to
solve
some
of
those
challenges.
C
Yeah,
I
would
love
to
take
this
one
first
I'll
be
mindful
of
times
that
you're
really
really
carried
away
with
both
of
these,
because
there's
a
lot
a
lot
of
stuff
to
cover
here,
but
I
think
there's
two
two
things
that
I've
observed
being
being
in
and
around
devops,
you
know
pretty
heavily.
I
would
say
the
last
five
or
six
years
has
been
focused
on
how
like
infrastructure,
automation,
shifting
left.
C
You
know
your
functional
testing
and
non-functional
testing
all
those
things,
but
but
to
truly
achieve
continuous
delivery,
and
you
know
a
large
complex
organization,
highly
regulated
organization,
think
about
a
financial
institution,
state
local
governments,
us
governments,
things
like
that.
You
really
have
to
you
know
think
about
the
release
management,
the
risk,
the
audit,
the
permit
to
release
permit
to
operate
authority
to
there's
there's
a
whole
lot
of
nomenclature
around
all
those
things.
But
how
do
you
take
those
concepts
and-
and
things
that
are-
are
reviewed
in
the
cab?
C
And
how
do
you
build
that
into
the
pipeline?
How
do
you
start
taking
those
insights,
so
we've
we've
seen
it
had
a
lot
of
success.
We've
helped
the
top
five
banks
sort
of
start
building
those
we
got
a
policies
code,
but
how
do
you
start
to
to
take
those
take
those
checks
and
has
a
binary
is
being
promoted
from
dev
up
to
production?
C
Has
an
engineering
delivery
team.
I
can
see
at
any
state
real
time.
You
know
how
how
my
binary
is
going
to
measure
up
to
the
standards
that
has
to
go
to
production
instead
of
waiting
for
the
11th
hour
to
be
told
that
you
know,
there's
a
security
issue
or
whatever
the
case
may
be,
or
I'm
failing
a
risk.
C
I
can
address
it
then,
and
there
in
the
backlog
so
yeah
so
and-
and
I
would
say
it's
important-
that
you
you
build
your
your
automated
governance
in
such
a
way
that
it's
a
non-human
digital
handshake,
so
otherwise
you're
going
to
lose
the
credibility
from
your
from
your
friends
and
in
the
audit
organization.
But
you
know
audit
risk
is
important,
but
how
do
we
shift
that
left?
C
How
do
you
shift
the
cab
left
is
what
I'm
talking
about
here
specifically,
so
I
think
I
think
I
think
that
to
me
is
the
future
of
really
to
continue
to
achieve
continuous
delivery
in
a
large,
complex
organization.
You
have
to
think
about
that,
and
the
last
part,
I
think,
could
be
remissed
in
a
get
up
summit
and
I'll
talk
about
get
ops
so,
and
we
we've
seen
a
lot
of
success,
leveraging
get-offs
in
a
non-traditional
way.
I'll
give
you
two
examples.
C
I
think
get
offs
has
been
really
a
game
changer
because
it
brings
sort
of
the
all
the
process
and
things
outside
of
getting
outside
of
us
traditionally
a
separate
tool
into
where
the
action
is
at
and
that's
in
the
source
code
right.
So
I
think
that's
been
big
there.
So
two
two
examples:
where
we've
leveraged
a
get
ops
approach,
we'll
say
to
help
continuous
delivery
is
one
for
managing
a
k8
cluster.
C
So
if
you're,
a
new
team
that
wants
to
onboard
onto
you
know
the
the
kubernetes
platform,
you
would
essentially
open
a
full
request
to
say
this
is
the
team
name.
This
is
the
the
engineers
are
going
on
the
team,
there's
the
name
space
and
here's
the
environments.
I
would
need
you
know
if
there's
enough
automation
in
to
take
that
full
request
and
apply
that
good.
If
not,
that
pull
request
goes
to.
C
You
know,
whoever's
running
the
the
platform
and
they
can
approve
that,
and
you
know
the
pipeline
will
run
and
adventure
that
so
so
that's
one
and
the
other
is
sort
of
a
just-in-time
approvals
bringing
in
infosec
or
I.t
security
into
approval.
So
I
think
it's
unfair
to
expect
security
to
look
at
every
single
change,
that's
happening
and
weigh
in.
If
it's
a
change,
simple
change
to
ui,
then
security,
you
know
probably
doesn't
need
to
weigh
in.
C
But
if
you're,
if
you're
making
a
change
in
your
your
terraform
code,
that's
going
to
try
to
add
a
user
or
you
know
open
something
up.
Having
the
python
be
smart
enough
to
say:
hey!
This
is
a
risk.
This
is
a
potential
security
issue.
Let's
bring
security
in
so
adding
them
in
real
time
to
the
approvals,
so
you
bring
them
to
the
table
when
needed.
C
Instead
of
opening
up
a
ticket
on
a
totally
separate
system,
that's
so
far
disconnected
and
you're
asking
for
a
manager,
who's
disconnected
from
the
works
of
approval
just
again
bringing
bringing
the
bringing
the
approvers
to
where
the
action
is
happening
so
a
bit
of
a
long-winded
answer.
But
it's
really
excited
about
this
question.
D
And
that's
where
and
that's
one
of
the
things
that
I
do
is
that
I
don't
do
any
of
the
technology
stuff,
but
what
I
try
to
do
is
be
that
intermediary
between
the
people
that
are
actually
using
it
and
some
of
these
other
and
I'm
going
to
say
it
bloated
processes
that
we
have
for
audits.
I
get
the
need
for
them
totally
get
the
need
for
them.
But
if
we're
doing
you
know
ci
cd
it
that
it's
almost
counterintuitive
to
then
have
these
other.
D
You
know
bloated
processes
trying
to
do
something
that
we're
doing
you
know
very
fast-paced
and
getting
stuff
out
on
the
technology
side.
So
one
of
the
things
that
I
you
know
really
try
to
do
is
especially
when
we're
talking
about
transformations.
It's
not
just
it
or
transformations.
We
need
to
look
way
beyond
that
and
we
need
to
look
at
you
know
who
consumes
and
who
interacts
with
our
trans.
You
know
transformative
technology.
So
if
we
look
at
our
ci
cd
pipeline,
where
are
we
know,
where's
the
flow?
Where
are
those
bottlenecks?
D
Where
are
we
going
to
have
and
then
what
can
we
do
to
help
improve
their
process?
How
can
we
tie
them
in
exactly
what
you're
talking
about
eric
bring
them
closer
to
that
you
know,
decision
point
bringing
them
in
modifying,
maybe
their
flow,
maybe
what
their
process
is
and
then
how
can
we
leverage
the
work?
That's
already
been
done,
we
don't
need
to
have
repeated
repetitive
work.
We
you
know
we
can
tap
into
so
many
of
the
brilliant
minds
that
are
already
doing
some
of
the
work.
Let's
just
figure
out
how
to
improve
it.
D
B
We're
really
good
at
that,
and
typically
like
one
team
kind
of
owns
the
code
and
the
evolution
of
that
part
of
it.
But
when
you
look
at
the
right
side
of
it
right,
the
the
continuous
deployment
part
of
it
or
delivery
part
of
it,
how
many
different
teams
are
typically
involved
in
that?
How?
What
are
the
complicated
processes
that
are
involved
with
that?
So
that
right
hand,
side
of
that
movie
strip,
is
really
what
we're
trying
to
to
reduce
in
complexity.
B
So
the
big
thing
that
we're
looking
at
is
automated
automated
infrastructure
provisioning
on
branch.
You
know
we're
even
looking
at
like
just
being
able
to
have
put
push
button.
Whole
complete
environments
and
that
are
very,
very
specific
to
confidence
building.
So
at
one
point
in
time,
we'll
build
a
release.
Candidate
and
a
whole
bunch
of
different
environments
will
go
up
one
for
security
testing,
one
for
pin
testing
one
for
different
audit
auditing
one
for
for
whatever
and
in
parallel.
If
any
one
of
those
fail,
we
get
instant
feedback
right.
B
A
Yes,
I
love
that
I
love
all
of
your
insights
into
where
the
business
is
focused
on
nowadays,
because
it's
always
super
super
amazing
to
hear
that
all
the
things
that
we're
talking
about
in
this
conference
is
really
relevant
to
everyone.
Things
like
policy
as
code
infrastructure,
provisioning,
right
audit
and
governance.
How
do
we
manage
all
of
that
within
this
life
cycle
within
our
cicd
process
as
well?
A
And
I
want
to
thank
the
three
of
you
so
much
for
joining
us
on
this
panel
session
and
sharing
all
of
your
insights
on
continuous
delivery
and
digital
transformations,
because
this
has
been
very
insightful
for
me
as
well.
I
know
that
we're
running
out
of
time,
so
I
do
want
to
say
thank
you,
everyone
for
joining
us.
Please
ask
your
questions
on
the
side
and
we'll
get
to
them
without
further
ado.
Thank
you
all
so
much
and
I'm
going
to
close
out
here.