►
Description
Tom Suder, President and Founder of ATARC, Leo Garciga, Chief of JD-OI6 and Chief Technology Officer for the JIDO/DTRA, Rob Brown, Division Chief and Senior Solutions Architect with Infrastructure Enterprise (EID) at USCIS, and John Jeremiah, Subject Matter Expert at GitLab discuss what powerful impact DevOps is having on the Federal government and how DevOps can power your speed to mission.
Register for upcoming webcasts: https://bit.ly/2vUMzYb
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Hello
and
welcome
everyone
thanks
for
joining
us
today,
we're
excited
to
have
you
on.
During
today's
webcast.
We
will
be
hosting
a
panel
discussion
on
DevOps
within
the
public
sector.
My
name
is
Agnes
and
I
work
on
the
marketing
programs
team
here
at
gala,
I'm
joining
you
from
San
Jose
California
today
before
we
get
started,
I'm
going
to
cover
a
couple
of
housekeeping
items,
first
feel
free
to
ask
questions
throughout
the
presentation.
A
You
may
use
the
Q&A
function
at
the
bottom
of
your
screen,
for
that
we'll
have
a
dedicated
time
for
questions
at
the
end
of
the
panel
discussion,
but
you
may
go
ahead
and
send
in
your
questions
as
you
think
of
them
and
we'll
make
sure
to
get
to
them
at
the
M.
If
you
are
experiencing
any
technical
difficulties,
you
can
use
the
chat
function
to
get
in
touch
with
me.
The
moderator
for
help
now
I'm
going
to
turn
it
over
to
Tom
Sutter
with
the
president
and
founder
of
it
arc,
which
is
the
advanced
technology.
A
Academic
research
center
Tom
is
a
two-time
winner
of
a
federal
hundred
award,
which
is
a
prestigious
honor
that
recognizes
government
and
industry
leaders
who
played
pivotal
roles
in
federal
IT.
He
also
co-authored
27
white
papers
related
to
DevOps
and
IT
and
he's,
and
he
serves
on
a
variety
of
Technology
Advisory
boards
over
to
you,
Tom.
B
Thank
You
Agnes
again
I
run
the
advanced
technology
academic
research
center
and
we
have
a
lot
of
fun,
bringing
in
government
industry
and
academia
to
solve
the
big
problems
that
the
federal
government
runs
into
we're
talking
cloud
we
deal
with
mobile
would
deal
with
AI
and
of
course
we
deal
with
the
DevOps
aspect
and
we
run
a
conference
every
year
in
in
the
federal
debs
summit,
and
it's
been
the
fastest
growing
summit
that
we've
ever
had.
So
we've
got
a
lot
of
got.
You
know
over
200
government
people
there.
B
So
we
see
there's
a
lot
of
interest
in
there.
So
we're
really
excited
to
do
this.
Today.
We've
got
a
great
panel.
We
definitely
welcome
your
questions
and
we
were
talking
to
John
and
he's
out
of
Amsterdam
and
he's.
We
were
talking
about
challenging
questions,
so
we
really
want
to
challenge
him
and
the
rest
of
the
these
questions
feel
free
and
I'll.
Try
to
interject
you
in
there.
B
C
Are
things
town
started
at
USC
is
actually
working
with
Booz
Allen
Hamilton,
as
a
contractor.
Primary
focus
was
standing
up
essentially
Center
of
Excellence
training,
various
sort
of
activities
focused
on
DevOps
and
DevOps
adoption
from
technical,
tooling,
automation,
so
just
sort
of
even
to
understanding
what
get
going.
Yes
and
after
some
successes
and
actually
rolling
out.
C
Yes,
that
essentially
transcends
all
of
oh
I,
T
and
business
portfolios,
trying
to
do
a
lot
of
alignment
at
that
same
time,
trying
to
help
move
from
a
rogue
nature
of
multiple
orchestration
tools
and
platforms,
to
a
more
mature,
most
platforms
that
multiple
teams
or
multi
tenant
teams
can
actually
leverage
so
we're.
One
of
the
missions
that
we
have
is
essentially
processing
for
us
is
essentially
digitizing.
All
boomers
and
benefits
at
us
is
that's
sort
of
the
the
existing
director
mandate,
we're
working
towards
trying
to
have
that
completed
by
2020.
B
Great
and
if
I
can
ask
a
quick
question,
you
know
mark
Schwartz,
we
worked
with
him
and
he
was
one
of
the
DevOps
leaders.
What
are
some
of
the
challenges
of
being
a
leader?
You
guys
really
went
in
the
DevOps
trail
very
very
early.
What?
If,
what
are
some
of
those
challenges
that
you've
run
into
just
being?
First
in
so
many
ways?
First,.
C
Was
it
was
education
and
getting
everybody
understands
the
value
and
benefit?
A
lot
of
folks
were
stuck
in
non
agile,
waterfall,
like
on
program
management
practices
from
a
sort
of
operations,
perspective,
pretty
antiquated
monitoring,
still
a
lot
of
segregation
of
duties
and
even
even
even
say,
really
antiquated.
Leitzel
practices
were
enhancers,
trying
to
overcome
all
that.
One
of
the
successes
for
that
mr.
C
B
D
Hey
how's
everyone
doing
I'm,
Leo,
Garcia
I'm,
the
chief
technology
officer
at
the
joint
improviser
at
the
feet,
organization
aligned
under
this
production
agency
and
I'm
on
I,
would
say.
Probably
month.
18
of
my
DevOps
journey
we've
been
we've
been
up
and
running
a
pretty
mature
pipeline
now
for
about
a
year,
and
it's
been
an
interesting
journey
to
say
the
least
and
I
think
Li.
You
know
kind
of
where
I'm
pushing
now
and
my
big
focus
right.
D
Besides
just
expanding
and
of
our
ecosystem
out
to
to
a
broader
community
ie,
not
just
the
folks
who
sit
in
my
building
but
out
as
far
as
to
technical
edges.
I
can
is
to
really
look
at
how
we
can
democratize
some
of
the
capabilities.
We've
built
right
not
only
from
a
from
a
pipeline
to
be
able
to
push
software
analytics
out
faster,
but
push
that
all
the
way
out
to
the
edge.
D
So
we
can
have
functionals
out
at
the
edge
really
really
doing
a
lot
of
that
heavy
lifting
for
the
analytics
that
they're
looking
at
and
since
we
focus
so
hard
on
building
out
that
that
secure
DevOps
infrastructure
and
that
pipeline
and
really
wrapping
it
around
kind
of
that
DoD
flavor
pushing
it
as
far
out
to
the
edge
as
we
can
and
other
than
that.
I
think
I'll.
Leave
that
because
I
want
to
get
to
the
bigger
discussion.
B
D
Yeah
definitely
I
think
you
know
when
you
look
at
how
a
commercial
space
is
doing
right
now,
right,
very
distributed
development
I
think
one
of
the
opportunities
that
we
have
once
once
you've
kind
of
matured
and
modernized
the
infrastructure
to
really
have
that
type
of
ecosystem
to
support
DevOps.
Then
there's
there's
a
lot
of
tooling
out
there
and
automation:
that's
already
ready
to
go
where
you
can
actually
push
it
out.
D
D
We
have
a
bunch
of
capabilities
that
are
sitting
out
there
right
now
that
allow
you
to
build
some
of
those
analytics
how
disconnected
and
either
once
reconnected
or
even
just
hand,
pass
being
able
to
bring
that
back
to
the
enterprise
and
quickly
pushing
it
through
a
pipeline
to
get
it
onto
production.
I
think
that's!
That's
a
big
deal,
I
think
that's
where
the
future
is
gonna
be
and
I
think
we'll
start
treating
a
lot
of
this.
You
know
right
now.
It's
kind
of
cool
and
everyone's
excited,
but
I
think
in
two
three
years
we're.
D
B
E
Absolutely
Tom,
you
know:
I'm
super
excited
to
be
able
to
join
everyone
today,
I
happen
to
be
I.
I
live
in
Florida,
just
just
south
of
Cape
Canaveral,
which
is
kind
of
a
fun
place
to
live,
because
I
get
to
watch.
Rockets
go
off
all
the
time,
but
today,
I'm
in
Amsterdam
and
I
am
traveling
with
one
of
the
thought
leaders
who's
been
writing
a
lot
about
DevOps
and
I've,
been
working
with
Gary
Gruber
for
a
number
of
years.
E
Frankly,
and
Gary
and
I
have
been
doing
road
shows
going
and
talking
to
customers
and
helping
people
to
learn
about
where
they're
at
in
their
DevOps
Tyrian.
How
do
they
go
on
that
transformation?
We've?
We
were
talking
with
banks
and
heavily
regulated
industries
and
government
agencies.
We
had
London
yesterday
where
we
had
the
Department
of
Work
and
Pensions,
and
we
had
government
agencies
talking
about
how
they're,
how
they're
on
their
own
journey
to
do
the
transformation.
E
If
I
go
a
little
ways
back
in
my
career,
I
was
a
naval
officer
and
I
I
was
on
the
receiving
end
of
a
lot
of
the
technology
that
that
this
team
builds
as
a
communications
officer
and
really
receiving
the
technology
and
using
it
to
help
accomplish
and
achieve
missions.
So
I
understand,
speed
to
mission
and
I'm
excited
to
be
part
of
the
part
of
the
panel.
B
Thanks
John
and
I've
got
a
quick
question
for
you:
where
do
we?
Where
does
the
federal
government
compare
to
the
rest
of
you
know
the
world
in
in
this
DevOps
journey?
Are
they
you
know
they
always
say
the
government's
behind?
How
far
behind
our
way
are
we
behind
it'd
be
good
to
get
some
perspectives
on
where
we
compare
to
other
sectors?
B
E
Know
the
Tom
it's
a
great
great
question:
I
think
it
in
a
typical
consulting
sort
of
answer.
It
depends.
It
depends
on
the
agency.
It
depends
on
the
leadership
you
know
when,
when
leaders
take
on
organizations
and
start
to
drive,
a
transformation
mark
is
a
great
example
and
and
how
mark
helps
to
drive
a
transformation
you
know
at
DHS
and
how
how
they
evolved
there
and
adopt
and
and
embrace
DevOps,
so
they're
I
think
they're.
E
Our
evangelists,
who
are
driving
transformations
and
I,
think
there
are
other
parts
of
the
of
the
federal
government
that
are
laggards
and
I
think
this
is
exactly
the
same
as
true
in
in
the
in
the
civilian
side
as
well.
In
the
commercial
where
there
are
organizations
that
are
the
culture
is
resistant
to
change,
they
don't
feel
the
need
to
go
faster.
It's
it's.
It's
very
similar,
I
think
there's
a
lot
of
parallels,
I,
don't
think
I,
don't
think
in
general.
The
government
is
that
far
beyond
yeah.
B
I
think
sometimes
the
government
thinks
they're
further
behind
than
they
are
in
every
every
kind
of
aspect
in
and
really
they
probably
aren't
first
but
they're
they're,
definitely
not
not
too
far
behind
and
before
we
get
into
the
Q&A.
Just
from
my
observations,
I've
seen
the
entire.
The
entire
federal
government
I
do
think
that
the
big
issue
that
we
have
we
got
some
great
tools
out.
B
There
I
definitely
think
it's
the
culture
and
I
think
the
development
cycles
from
doing
software-development
myself
is,
you
know,
we're
kind
of
used
to
waterfall
we're
kind
of
used
to
building
out
a
process
and
the
security
kind
of
comes
at
the
end
and
I
think
it's
Gardner,
that's
reported
doing
those
Corrections
at
the
end,
it
cost
about
30
times
as
much
so
I
think
it's
just
getting
this
getting
this
culture
changes.
Obviously
I
think
one
of
the
biggest
challenges
I
think
the
good
tech
is
out
there.
B
So
anyway,
I
will
I
have
a
few
questions,
but
I
would
love
to
get
some
audience
participation,
but
anyway
be
the
first
question
I
have
is
in
maybe
Leo
you
can
touch
on
it.
What
is
the
main
cultural
challenges
faced
by
the
public
sector
when
a
development
adds
up
DevOps
practice?
How
do
I
even
get
started
on
this,
and
we,
if
you
could
flesh
that
out
a
little
bit
and
any
of
the
other
panels?
Can
chip
in
sure.
D
Definitely
Anna
and
I'm
glad.
You
said
what
you
said,
because,
because
I'm
with
you
right,
I
think
one
of
the
things
that
we
see
in
the
federal
space
is
that
kind
of
traditional
model
and
that's
what
we've
been
used
to
and
around.
That
is
the
fact
that
both
both
of
how
we
acquire
capabilities
right,
whether
it
be
software
or
an
integrator
coming
and
how
we
contract
is
definitely
very
much
tied
and
and
in
its
own
little
box
that
that
really
supports
waterfall
in
that
traditional
model.
So
how
do
you
get
there
right?
D
So
it's
interesting
right,
the
cultural
piece,
it's
challenging
right!
It's
and
it's
it's
a
people
thing
more
than
anything
else,
I
think
what
I
tell
folks
when
folks
kind
of
ask
me
hey:
how
did
you
get
from
A
to
B
besides
having
a
smart
answer
very
deliberately,
I
think
it
really
is
about
doing
that.
Transition
in
in
some
big
chunks,
right
and
and
those
big
chunks
are
the
ones
that
kind
of
help
you
get
there
and
again.
This
is
at
the
enterprise
level,
not
on
a
small
project.
D
Iii
think
that
first
thing
was
a
transition
right,
so
transition
from
from
a
more
traditional
waterfall
to
an
agile
approach.
I
think
that
that
was
kind
of
our
first
step
in
the
first
step
that
we
took
on
our
journey,
and
that
was
a
little
bit
further
down
line
right.
That
was
about
four
years
ago,
and
what
that
did.
D
So
if
you're
a
commercial
entity,
that's
pushing
out
Web
Apps
right,
you're,
gonna
kind
of
tool
yourself
to
focus
on
Web
Apps
and
puts
them
left
and
right
limits
around
that.
That
was
really
our
next
big
piece
is
to
start
building
out
that
ecosystem.
Knowing
that
we
were
moving
in
the
direction
to
kind
of
make,
our
entire
enterprise
really
follow
those
base,
agile
principles
and
and
what
building
out
that
ecosystem
did
was
it
showed
us
that
hey
we
can
work
the
configuration
management
piece?
D
We
can
work
the
process
piece
we
can
get
all
our
contracts
lined
up
to
do
agile.
We
can
bring
all
these
tools,
but
in
a
24
month
period
we
went
down
from
like
92
days
to
get
something
out
the
door
accredited
to
about
23
days
and
we
couldn't
move
any
faster
than
23
days
and
that's
really
when
about
a
little
less
than
two
years
ago.
We
said:
hey,
you
know
the
demand
signal.
Is
we
got
it?
We
got
to
push
capabilities
out
even
faster,
so
how
do
we
get
there
and
that's
what
we
really
started?
D
If
you
look
at
most
traditional
enterprises
right
their
policies,
their
processes
that
the
skill
set
of
folks
they
have
is
is
for
what
the
enterprise
has
today.
So
you
do
have
to
do
a
pretty
deliberate
transition
into
the
space.
That
being
said,
right,
24
months
is
pretty
fast
for
our
government
agency,
but
but
some
of
that
really
was
you
know
having
that
initial
shift,
agile
that
build
the
ecosystem,
those
pieces
bars
kind
of
laid
the
foundation
to
really
have
a
scalable
enterprise
were
very
quickly.
We
could
move
to
to
a
much
more
automated
fashion.
D
I
think
that
that
probably
was
the
biggest
cultural
challenges,
shifting
where
people
were
in
the
process,
right
and
and
integrating
them
to
be
able
to
get
stuff
out
the
door
and
and
that's
important
right,
I.
Think
you
see
a
you
see
a
shift
over
over
several
months.
There
really
matrix
in
your
folks
in
the
right
place
at
the
right
time
to
get
capability
out
the
door,
but
I
think
the
the
cultural
challenges
are
real,
I
I
think
we
and
we
still
see
them
right.
D
B
C
Happy
to
run
I
think
when
we
start
his
lying
skills
was
the
right
skill
set
from
I.
You
know
having
that
skill
set
matching
with
the
right
culture
as
we're
trying
to
it
was
a
big
challenge.
A
lot
of
education,
training
illustrating
benefits
going
through
that
definitely
just
adopting
automation
and
I.
C
Think
everybody
understand
ensuring
that
true
value
and
illustrating
that
you
still
do
have
a
job
after
you
start
to
automate
some
of
those
tasks
that
you've
been
doing
in
the
manual
fashion,
so
that
I
think
you
know
having
a
story
to
tell
and
showing
and
showcasing
those
examples
for
us
really
did,
make
a
difference
and
sort
of
moving
that
culture
and
moving
that
needle
to
to
more
of
an
automated
manner.
For
these
folks
and
really
to
help
set
the
stage
and
foundation
for
particularly
like
that
deficit.
Gobs.
C
Of
cultural
challenges
that
we
that
we
faced
was
just
in
communication
and
having
you
know,
teams
that
are
from
different
companies.
You
know
we're
in
the
organization
where
a
lot
of
the
folks
for
contractors
and
they're
from
different
companies
and
some
of
them
are
competitors.
Some
of
them
are
friendly.
Some
of
them
are
compendium
eights,
trying
to
navigate
those
waters
and
sort
of
set
a
baseline
of
like
this
is
for
the
mission
guys.
C
This
is
not
just
for
the
profit
of
the
company,
so
overcoming
that
I
think
it
was
also
a
large
challenge
and
I
think
one
of
the
ways
we
overcame.
That
was
to
be
able
to
focus
on
the
technology
and
change
from
more
of
a
static
communication
of
constantly
shifting
or
shipping
things
around
an
email
and
starting
to
leverage
the
technology
that
we
had
or
adopting
new
technology.
So
we
had
real-time
comms
that
transcended,
essentially
these
silos
of
people
and
contracts
and
projects.
C
D
D
There's
there's
some
great
options
out.
There
I
think
that
one
of
the
things
that
we
found
as
we
moved
into
the
DevOps
space
was
right
because
you're
gonna
have
different
contracts.
That's
just
real
is
really
focusing
on
building
really
smart
service
level
agreements
with
all
of
our
vendors
and
and
build
in
what
I
would
say
would
be
across
pass
court
or
service
level
agreements
right.
That's
it's
a
relationship
between
the
government
and
and
the
integrators,
but
I
think
right
still
focused
on
mission,
which
mission
being
the
primary
focus
has
been
the
driver.
E
Many
people
have
spent
large
parts
of
their
careers
building
software
in
a
waterfall
way
or
in
a
waterfall
way
or
a
or
maybe
even
a
water
scrum
fall
way
where
there's
trying
to
dabble
with
agile,
but
they
really
haven't
committed
and,
and
the
reality
is
that
they've
learned
that
the
the
big
fat
document
you
know,
the
BFD
that
they
would
write
was
usually
the
Bible.
They
write
the
requirements,
they
write,
the
design
they've
learned
a
process
of
doing
that
and
having
them
let
go
of.
E
That
requires
leadership
to
give
to
give
them
different
goals
and
a
different
objective.
If
you
will
a
mission
for
them
about
going
faster
and
evolving
and
and
what
I
think
is
amazing-
and
you
know
when
the
speed
at
which
Leo
talked
about
the
change
in
the
transformation
is
a
lot
of
organizations.
It
takes
them
years
to
start
to
incrementally
go
faster
where
they
start
to
apply
some
of
the
learnings.
They
make
mistakes.
They
learn,
they
start
to
go
faster
and
it
becomes
it's
truly.
E
A
pattern
of
of
crawl
walk
run
in
order
to
achieve
speed,
and
that,
if
you
tell
them
about
what
it
looks
like
to
go
fast,
you
know
for
us
at
get
lab
we're
releasing
on
our
website
sixty
times
a
day.
We're
deploying
you
know
we're
just
all
the
time
and
for
people
who
aren't
anywhere
near
that
they
think
that's
crazy.
They
think
that's
insane
and
it
requires
a
maturity
to
get
there
in
evolution
and
I.
E
B
C
Could
speak
I'll
just
a
high
level
on
procurement,
but
we're
really
from
legal
regulatory
really
from
just
compliance
in
general.
You
know
we
were
from
the
federal
perspective.
Of
course,
every
other
industry
has
some
level
of
compliance
early.
It's
that
we're
looking
at
the
missed
date
under
53,
the
sort
of
the
FISMA
or
FedRAMP
compliance
standards
and
then
within
DHS
as
well.
We've
got
our
own
layer
of
additional
controls
that
we
all
need
to
meet.
C
So
I
think
you
know.
We've
Leo's
already
brought
this
up,
but
understanding
what
those
challenges
are,
how
to
move
to
something
like
ongoing
authorization
and
building
that
into
your
pipeline,
so
really
adopting
that.
It's
a
pipeline
that
people
perspective
taking
on
the
the
compliances
code
perspective
has
helped
us
a
lot
so
we've.
Actually,
where
does
that
stem
from
again?
C
To
specific
databases
like
post
stress
so
actually
moving
in
that
into
that
direction
and
providing
just
that
that
repository
or
that
code
to
other
groups,
not
only
within
the
organization
but
now
essentially
externally
for
us,
has
been
a
huge
win
and
then
essentially
again
recently
adopting
pipeline
as
code
as
well.
So
not
only
just
having
you
know,
infrastructures
code,
but
also
having
our
pipelines
coats
and
that
entire
change
management
process
is
essentially
documented
and
is
a
pipeline
unto
itself,
but
then
provides
those
bodies
that
that
complete
audit
ability.
C
So
we
you
know,
I
could
go
on
and
on
about
this
forever,
but
I
know
from
a
getting
started.
I
think
it's
getting
those
building
blocks
in
place
that
can
be
leveraged
across
there,
even
if
it's
just
a
team
but
again
across
a
an
agency
promoting
that
and
showing
how
efficient
events,
as
has
helped
us
and
helped
essentially
speed
up.
Our
ability
to
you
know
achieve
a
TOS
or
authority
to
operate
in
a
much
faster
timeframe.
C
Now
there
is
a
bit
of
an
activation
energy
up
front,
of
course,
but
I
think
over
the
past.
You
know
a
few
years
we've
been
successful
in
having
pipelines
just
for
those
core
building
blocks,
that
a
lot
of
our
other
teams
and
portfolios
are
taking
advantage
of
to
the
point
now
where
we
are
essentially
providing
a
lot
of
our
development
teams
and
operation
teams,
essentially
a
parameterised
diamo
file
for
them
to
fill
out
where
their
endpoints
are
so
they
can
move
forward
and
not
tab
that
labor-intensive.
C
You
know
initial
energy
just
to
get
started
with
a
project
and
automate
a
project,
so
then
I
think
we're
moving
towards
a
more
advanced
method
of
reusability
as
well
as
just
you
know,
continuous
improvement
of
that
pipeline
and
of
the
tooling
that
we've
got
I
would
say
that
you
know
just
to
end
off
as
to
where
we're
heading
to
deal
with.
You
know
the
constant
changes
in
this
sort
of
venue
from
a
security
perspective.
D
C
D
Go
ahead
leo
yeah,
no
I
I'm
with
Rob
right
like
and
that's
where
I
talked
about
this,
like
building
out
that
ecosystem
right
I.
Think
our
big
push,
because
it
was
all
about
speed,
was
not
just
that
infrastructure
code,
but
the
whole
the
whole
process
right
bring
sre
into
it,
make
sure
you
can
document
as
much
as
you
can
make
sure
you
have
visibility
into
how
each
piece
of
code
right
from
birth
to
deployment
and
then
to
death
can
be
seen
on
your
enterprise
and
really
just
automate
all
that
right.
D
There
should
be
no
Excel
spreadsheet.
That
tells
you
where
stuff
is
or
what
release
you're
on
that's
insane
and
absolutely
makes
no
sense
when
there
is
all
this
automation
that
that's
ready
to
go
and
available
and
I
think
that
that's
the
key
right
if
I
went
both
come
and
ask
me:
hey!
Alright,
we're
gonna
start
here.
I'm,
like
your
end
state
should
be
continuous
authorization
right
when
you
look
at
the
NIST
cybersecurity
framework
and
and
in
DoD
the
risk
management
framework
right
at
the
end
of
the
day.
D
How
do
you
translate
your
policies,
your
processes
and
how
you
approach
the
problem
to
get
there,
but
that
should
be
everybody's
goal,
which
it
really
is
continuing
authorization,
because
it's
really
getting
that
capability
out
to
the
customer.
So
that's
that's
a
really
big
piece
to
it
and
I've
got
other
folks
are
moving
in
that
direction.
B
Fantastic
John
we've
got
a
question
from
the
audience:
Caleb
Cooper.
How
can
you
use
DevOps
to
manage
your
fleet
for
multiple
OSS
on
a
variety
of
device
types,
servers,
clusters,
desktops,
etc?
What
change
management
process
do
you
use
for
day-to-day
changes
that
fit
into
your
DevOps
workflow?
And
maybe
we'll
start
with
you?
John.
E
Well,
I
think
it's
a
question
of
building
out
and
automation.
I
mean
first
off
a
lot
of
what
what
I
see
people
taking
advantage
of
is
the
ability
to
containerize
and
leverage,
grenades
and
containers
to
help
manage
the
deployments
of
environments
and
deployments
of
applications
when
you're,
when
you're
looking
at
I
think
managing
down
to
the
desktop
or
down
to
the
actual
endpoint,
the
actual
final
device.
Then
it's
a
question
really
of
building
in
the
workflow
and
automation
required
in
order
to
actually
update
those
those
in
devices
that
becomes
a
key
part
of
it.
E
D
That
deployment
process
is
important
and
I.
Think
that
and
it's
a
great
question
right,
because
I
think
my
biggest
lesson
learned
day.
One
was
so
we
so
we
pushed
our
first
tool
through
our
pipeline
and
yep
it's
in
production,
but
you
know
some
DNS
entries
weren't
made
some
IPS
were
changed,
so
the
rest
of
the
network
wasn't
wasn't
you
know
flexed
with
with
that
deployment
and
at
that
point
I
stood
back
and
said:
well,
this
really
isn't
DevOps.
D
So
what
do
we
need
to
do
to
get
to
that
next
step
and
really
that's
when
you
get
into
into
building
out
those
yamo
files
right
and
doing
the
configuration
stuff
and
baking
that
into
the
pipeline,
so
it
becomes
not
just
right.
It
really
is
the
the
true
nature
of
infrastructure
is
code:
were
you
really
pushing
it
out
and
exercising
not
just
the
software
that
you're
developing
but
exercising
the
entire
network
to
get
capability
yeah?
So
my
stance
is
automate.
Everything
everything
that
can
be
automated
should
be
automated.
D
It
gives
you
better
pedigree,
right,
I
think
the
other
did
and
here's
the
piece
that
I
think
a
lot
of
folks
miss
in
this.
My
my
first
aha
moment
after
deploying
a
couple
of
things
on
the
network
was
sitting
back
and
looking
at
a
screen
and
thinking
wow.
This
is
the
first
time
ever
that
I
really
feel
comfortable,
that
I
have
a
full
situational
awareness
and
understanding
of
what's
been
done,
how
it's
been
deployed,
what
the
risks
are
right
and
how
that
fits
into
my
programmatic
portfolio,
that's
really
powerful
it.
Really.
D
B
D
People
right,
I,
think
I
think
the
the
the
the
people
challenge
was
hard.
Some
of
this
stuff
is
actually
really
scary
for
a
lot
of
folks,
right,
I,
think
and
I.
Think
Rob
said
it
upfront
right
the
the
concern
that
people
have
that
hey
this.
You
know
this.
This
box
has
taken
over
my
job
or
this
automation
is
gonna.
D
With
with
where
we
were
going
and
it's
hard
right,
it
is
fundamental
organizational
transformation,
so
it
takes
some
time
and
I
would
say
to
I.
Think
was
something
that
we
miss.
A
lot
is,
some
of
our
naysayers
were
actually
now
are
some
of
our
biggest
advocates,
because
they'd
learned
right,
they
make
mistakes
in
the
past
and
and
they
brought
up
good
things
that
made
us
kind
of
redirect
some
of
our
processes
and
policies
and
and
the
way
we
did
business
in
a
much
safer
manner.
D
Then
I
think
if
you
just
got
a
bunch
of
technologists
in
the
room,
so
I
think
the
the
change
right
it
is.
It
is
a
drastic
change
and
and
working
through
that
change
is
probably
the
biggest
thing
and
that's
that's
a
people
piece
and
again
right.
We
focused
on
I'm,
going
out
there
and
and
having
a
little
bit
of
a
different
flavor,
to
bring
folks
up
to
speed
and
using
some
what
I
would
consider
non-traditional
means
from
a
from
a
government
perspective
and
I.
B
That
last
thing,
you
said
I
think
we've
had
the
repercussions
of
the
GSA
conference
scandal
where
I
think
the
going
to
see
the
vendors
and
the
training
and
and
some
of
those
things
some
of
the
some
organizations
still
are
like.
Oh
I,
don't
I
don't
send
people
outside
of
my
office
to
to
learn
it's
it's
waste
of
time
and
I.
Think
we
definitely
we've
tried
to
do
that
at
a
targets
really
turned
that
around.
You
need
to
collaborate
with
other
government
colleagues,
but
you
also
need
to
collaborate
with
the
industry
college.
Great
and
Rob.
C
What
Leo
stated
people
is
always
anything
technology
is
relatively
easy.
It's
always
the
people
I
could
share
an
anecdote.
You
know
and
I
sort
of
a
tool
and
approach
that
we
took
here
to
help
with
that.
We
we
actually
started
to
help
with
this
adoption
and
help
with
you
know
the
cultural
bit.
The
people
part
was
we.
This
was
mark
Schwartz
we
created
first.
Essentially
such
there
was
a
management
instruction.
C
So
was
it
per
se
a
policy,
but
it
was
a
you
know:
a
yeah,
a
CIO
set
of
instructions
policy
like
to
help
people
get
spurred
along.
We
started
with
just
a
sort
of
an
agile
policy
or
management
instruction,
and
then
I
was
lucky
enough
to
participate
in
the
next
management
instruction,
which
essentially
provided
a
carrot
for
development
teams
as
well
as
operators
if
they
followed
these
sort
of
best
practices,
essentially
where
we've
got
a
release,
readiness
review,
which
is
a
governance
gate
before
you
can
deploy
the
production.
C
So
if
teams
portfolio
started
to
adhere
to
essentially
continuous
integration,
automated
testing
certain
number
of
deployments
per
for
every
two
weeks,
they
would
actually
have
this
release.
Readiness
review
gate
completely
removed,
essentially
giving
them
the
ability
to
deploy
I
will
so
reuse,
some
of
those
types
of
tools
per
se
to
help
spur
along
these
teams
and
get
them.
E
Are
you
doing
I'm
curious
Susie
as
we
talk
about
it?
Cuz
I
love,
I,
love.
The
conversation
I
agree
that
people
are
the
hardest
part
of
the
whole
thing
and
the
idea
about
making
the
right
path
the
the
right
way
to
do
it.
The
easy
way
make
it
that
the
easy
path
people
will
choose
that
over
the
hard
way.
What
are
you
doing
as
far
as
or
are
you
doing
anything
in
regards
to
doing
DevOps,
training
and
DevOps
dojo
I
know
target
implemented
a
dojo
model.
E
C
So
we
definitely
have
a
pretty
pretty
a
large
wealth
of
training,
that's
available
to
federal
and
contracting
staff
alike,
to
get
them
up
to
speed
and
where
it
may
seem,
they
get
to
choose
again.
It's
a
huge
swath
I
think
some
of
the
most
recent
additions
we
actually
have
is
some
Cerberus
training,
as
it
relates
to
how
you
can
use
server
lists
and
some
of
your
to.
C
Essentially,
you
know
abate
the
need
to
have
a
standard
pipeline
for
apps
that
just
don't
need
to
be
apps
we've
adopted
and
have
adopted
kubernetes
and
production
here
for
the
year
and
a
half
so
giving
giving
people
a
good
understanding,
not
just
how
containerization
works.
But
what
orchestration
looks
like
in
a
k-8
world
how
to
construct
properly
IMO
files,
how
they
would
leverage
well,
how
we've
stood
up
kubernetes
here
and
how
to
you
know,
take
advantage
of
the
wildcard
certificates
and
essentially
onboarding
those
tenants
and
just
focus
on
deploying
and
working
on
quality
code.
C
E
That's
that's
that's
key
because
you
can't
just
compile
you
know
a
cultural
change
or
people
change.
It's
not
a
kit
compiled
and
people
just
operate
differently.
You've
got
to
continue
to
reiterate
and
teach
and
train
so
that
that's,
but
that's
happening
in
the
civilian
sector.
It's
happening
across
the
board.
I
I
love
the
I
love.
What
you're
talking
about
here?
It's
common!
It's
a
common
problem.
Again,
it's
a
common
solution,
good.
B
Thread
you
pulled
there
John
and
that'll
go
into
the
next
question.
I
have
is
how
do
you
get
started?
We
probably
should
have
asked
that
first.
But
how
do
you?
How
do
you
get
started?
You're,
you've
been
pear
a
new
organization,
they
their
waterfall
they've,
been
doing
things
a
certain
way.
How
do
we
get
started?
I
know
Rob.
You
mentioned
the
Center
for
Excellence.
Maybe
you
can
lead
us
off
and
then
we'd
go
to
Leo
for
a
bit
sure.
C
Yeah
we
Freud
I
can
just
speak
to
what
we've
done
here
at
USGS
was
again
providing
teams
that
ability
to
fail
first
of
all,
culturally
and
like
failure,
is
actually
a
success.
So,
starting
there
I
think,
was
a
big
help
and
we
started
off
pretty
you
know:
every
team
essentially
had
their
own
Jenkins
server.
They
had
their
own
tooling.
It
was
really
Wild.
West
I,
think
that
you
know,
depending
upon
your
maturity
level,
where
you
are,
is
going
to
probably
help
dictate
where
you
need
to
be
and
what
you
need
to
start
to
adopt.
C
There's
plenty
of
those
do
a
self-assessment,
there's
plenty
of
professional
organizations
out
there
like
Dora.
That
can
help
you
understand
your
maturity
level,
but
if
you're,
you
know
ground
floor
depending
upon
the
size
of
the
group
I.
Would
you
know
budget
some
time
to
promote
experimentation
and
power,
those
folks
so
sort
of
Wild
West
it
a
little
bit
and
see
where
they
fit
in?
What
what
are
the
right
tools?
What
is
the
right
communication
structure?
Are
they
going
to
work
properly
with
the
goal
of
you
know,
speed
and
quality
at
the
at
the
forefront.
I.
C
The
pipeline
perspective.
If
you've
got
a
you
know
a
bunch
of
different
teams
using
a
million
different
artifact
repositories.
Good
luck
so
start
to
aggregate
on
a
good
common
set
of
of
dependency
management
tools
and
essentially,
a
good
supply
chain
for
your
developers
in
your
operation
teams
to
include
a
good
registry
where
it's
transparent
for
all
and
not
just
those
individual
teams.
D
Yeah
I'm,
with
Robin
I,
mean
I
think
we
took
a
very
a
very
similar
approach.
I
think
the
only
thing
I
would
add
to
that
is
right.
Skill
matters
and
there's
not
an
easy
template
for
this
I
think
the
bigger
thing
from
getting
started
is
really
focusing
on
what
you
want
to
deliver
right
and
what
I
mean
by
that
is
doing
this
at
an
enterprise
level
works
for
any
capability.
You
push
out
is
actually
really
hard,
I
think
starting
off
with
really
focused
on
hey
I,
wanna,
I
wanna.
D
You
know
kind
of
build
out
a
devil
pipeline
to
focus
on
delivering
analytics
to
to
a
big
data
stack
or
to
push
out
to
you
know
this
web
app
or
that
web
app
right
starts.
Building
out
that
ecosystem,
that
slowly
kind
of
gets
you
moving
down
that
path
and
gets
that's
an
important
thing
to
think
about,
and
leadership
buy-in
to
write
and
we've
said
it
a
couple
of
times.
Part
of
this
is
is
really
having
a
push
from
leadership.
D
From
a
mission
perspective,
ie
I
need
to
get
a
capability
out
faster
I
need
to
be
more
secure.
I
need
to
be
able
to
scale
development,
I
mean
those
things
right
there
and
having
that
that
mission
focus
I,
think
that
that's
a
luxury
that
we've
had
in
the
joint
professor
at
the
feeder
organization
is
that
that
focus
on
on
on
speed
of
delivery
kind
of
naturally
started
pulling
us
in
this
direction.
D
I
think
when
you
look
at
other
enterprises,
I
becomes
a
little
bit
more
challenging
when
it
when
it
may
not
necessarily
be
a
speed
thing.
I
think
also
getting
those
lessons
learned
if
you're
in
the
federal
space
right
talking
it
to
folks,
there's
a
couple
of
us
out
there
who
have
pretty
mature
capability
now
and
being
able
to
show
that
hey
yeah.
This
is
possible.
We
can
do
this
in
a
safe
and
secure
manner.
Just
really
helps
spread.
You
know
get
that
word
out
and
get
folks
to
start
buying
in.
B
And
that
leadership
thing
is
pretty
important:
it's
hard
to
do
anything
without
the
top
cover
from
leadership
that
is
on
board.
I
agree
with
that.
We
got
a
couple
quick
questions
that
maybe
we
can
fit
in
before
I
can't
believe
it's
almost
1
o'clock,
Eastern
Standard
Time.
Already
it's
gone
by
quick.
B
D
I
think
the
reality
is
and
just
because
capabilities
are
changing.
So
fast
is
you.
You
have
to
have
some
kind
of
organization
or
Enterprise
plan
to
get
at
that
problem
or,
if
not
we'll,
run
into
kind
of
the
problems
we're
trying
to
solve
with
DevOps
on
on.
You
know,
biotech
debt
and
all
that
what
you
don't
want
to
do
is
you
don't
want
to
buy
a
lot
of
tech
that
into
your
pipeline
either.
D
C
C
Mist
mist
actually
has
a
very
good
security
document,
800
190.
If
you
need
to
look
it
up,
it's
public.
All
these.
This
documents
are
public
so
from
the
standards
see
is
also
has
some
very
good
hardening
security
guidelines
that
you
can
follow
as
well,
and
there's
plenty
of
tools
out
there
that
you
can
embed
not
only
from
a
you
know.
B
C
I
think
just
like
any
sort
of
data
that
we
that
we
like
to
gather
on
the
business
side
to
provide
insight
into
how
we
operate
move
forward.
I
think
we
need
to
be
thinking
the
same
as
we
operationalize.
Let
move
forward
with
our
pipelines
the
tools
that
we've
got
aggravate
that
data
and
provide
meaningful,
useful
information
to
the
developers
to
the
operators
to
the
security
folks,
the
platform
engineers,
the
sres
and
ultimately
I
would
hope
to
start
to
apply
levels
of
AI
and
ml
to
that
information.
D
This
is
Leo.
I
hope
that
in
five
years
of
conversation,
that
we're
having
is
how
machine,
learning
and
and
some
AI
capabilities
are
allowing
us
to
actually
physically
have
the
right
less
code
and
be
able
to
go
through
our
whole
corpus
of
code
that
we're
pushing
out
to
really
validate
the
level
of
security.
I.
Think
that's
a
that's!
The
longer-term
piece!
D
That's
missing,
and
it's
probably
the
most
even
now
still
time-consuming
piece
from
it
from
a
human
perspective
is
at
the
end
of
the
day,
we
have
to
triage
self
right
if
it's
a
third
party
library
and
it's
bad,
a
human
has
to
go
in
there
and
do
a
lot
of
work
to
determine
whether
we
want
to
put
that
out.
I
think
that
I
hope
that's
what
we're
talking
about.
In
fact,
I
hope
we're
not
even
talking
about
DevOps
I,
think
it's
just
infrastructure
at
that
point
right.
D
E
I
would
second
the
comments
about
using
machine
learning,
both
to
increase
that
our
velocity
and
our
DevOps
pipelines
in
our
vote,
and
and
also
to
help
us
improve
how
we
code,
but
I,
really
hope
that
in
five
years
that,
as
we
start
to
work
together
in
a
collaborative
way
that
we're
really
unlocking
the
human
potential
that
we're
enabling
our
our
operators,
our
users
are
other
people
that
use
our
systems
to
come
together.
And
so
we
can
innovate
faster
and
more
collaboratively.
And
that's
something
I
think
that
is
right.
E
Now
it's
a
challenge
because
there's
so
many
different
silos
of
the
way
we
work
and
people
work
in
different
systems
in
different
places
and
and
I
hope.
The
future
and
I
hope
that
the
future
is
really
one
in
which
all
of
us
are
able
to
come
together
and
collaborate
as
a
team
and
to
work
and
to
leverage
the
technology
in
order
to
to
be
more
effective
and
to
solve
more
problems
faster.
So
I
think
it's
really
about
solving
business
problems.
E
B
You
John
we're
gonna
end
it
at
that.
Thank
you.
Rob
leo
John
and
I
really
want
to
thank
the
get
lab
team
they're
very,
very
dedicated
to
this
educational
process,
and
it
really
matches
the
mission
of
a
tarq
and
everybody
have
a
good
day
and
I
like
to
thank
the
audience
who
are
very
good
questions
appreciate
the
interaction
and
everybody
have
a
good
rest
of
the
day.
Thank
you.