►
From YouTube: Commit Virtual 2020: A Small (But Vital) Step In Our DevOps Journey - Rolls Royce UK (SMRS)
Description
Host: Scott Adams
With an engineer-constrained team experienced in waterfall methodologies, Rolls Royce UK SMRs set out to enable modern, Agile tools, techniques and philosophies. This presentation will detail how COVID-19 provided the catalyst to starting our DevOps journey, and how using GitLab as our lifecycle management tool has allowed us to incrementally migrate to a DevOps solution, providing value for inflight tasks, whilst enabling a framework to ease development, testing and deployment of an increasingly complex nuclear analytical method.
Get in touch with Sales: http://bit.ly/2IygR7z
A
B
So
why?
Why
am
I
here?
So
I'm
currently
leading
the
performance
methods
in
the
program
and
which
is
the
the
thermal
hydraulics
aspects
of
the
the
whole
nuclear
reactor
and
when
you
kind
of
break
it
down
into
its
parts?
It's
it's
data,
it's
commercially
off-the-shelf
software,
it's
in-house
codes
and
and
models
and
all
aspects
of
this
can
utilize
modern
software
techniques.
B
So
we
we
took
the
plunge-
and
I'm
here
to
talk
you
through
our
small
step
into
the
realms
of
devops.
So
essentially
we're
a
really
small
analytical
team
in
performance.
We
develop
test,
deploy
and
utilize
all
of
our
methods,
and
it's
it's
all
to
do
with
providing
data
not
only
through
design,
so
we're
still
in
divine
design
phase
of
this
nuclear
reactor,
but
once
we're
there,
we
want
to
justify
it
as
well.
B
So
all
of
this
was
kind
of
originally
developed
on
on
a
really
siloed
internet,
isolated
aging
network
that
had
the
the
version
of
python
that
it
was
kind
of
built
on
it.
So
we
we
used
python
2.4
originally
and
we
later
moved
to
the
groundbreaking
2.6
and
because
we
had
kind
of
little
software
experience.
B
So
there's
various
teams
dotted
around
that
are
making
quite
major
changes
in
some
cases
to
the
design,
and
we
need
to
change
our
models
to
be
able
to
capture
that
and
due
to
the
the
last
few
years
and
the
fact
that
we're
kind
of
still
in
design,
it
means
that
we've
actually
historically
had
quite
a
high
turnover
in
engineers
and
on
our
relatively
small
team,
which
hasn't
helped
with
our
update
process.
Either.
B
B
B
B
The
the
design
was
getting
increasingly
more
complicated
and
we
were
struggling
to
kind
of
keep
up
as
is,
and
we
were
starting
to
consider
kind
of
other
interactions
with
other
areas.
I
think
one
of
the
main
reasons
that
we
needed
to
change
was.
It
was
just
a
really
paper
heavy
kind
of
process,
so
we
had
a
five-step
qa
process
for
plan
design,
develop
test
and
deploy
and
at
stage
three
you'd
already
broken
your
solution
up
into
parts
and
for
each
of
those
parts.
B
You
need
the
memory
to
describe
what
your
what
your
design
was
and
then,
when
you
were
testing
it,
you
need
a
separate
test
plan
to
ensure
that
it
worked
standalone
and
that
needed
an
author.
They
needed
an
approver
to
make
sure
the
test
you
were
performing
right.
I
needed
someone
to
ensure
that
you'd
done
your
tests
and
then
more
often
than
not
the
the
system
owner
wanted
oversight.
So
for
just
that
small
part,
you
needed
four
people
to
look
at
it
and
we
were
already
in
a
five
person
team.
B
So
if
you
did
it
properly,
more
than
50
of
your
team
was
getting
involved
in
every
minor
update
and
then
to
make
things
worse.
When
we
deployed
we
pulled
all
of
these
together
into
a
colossal
document
with
integration
testing
evidence
which
just
was
more
time,
spent
writing
and
less
time
actually
testing.
B
So
I'm
gonna
put
little
snippets
of
advice
in
in
my
talk,
and
I
think
one
major
one
is
don't
go
waiting
for
your
catalyst
to
implement
a
solution.
We
waited
for
us
and
we
waited
too
long,
but
don't
wait
for
yours,
so
our
catalyst
was
kv19.
So
overnight
we
went
from
working
on
our
engineering
engineering,
pcs
quite
happily
to
having
basically
zero
capability
whatsoever.
B
Our
developments
came
to
a
standstill
and
so
did
ours.
We
had
some
standard
laptops
that
we
could
use,
but
they
they
kept
crashing.
Essentially,
every
time
you
you
opened
up
a
work
document,
they
wouldn't
be
able
to
run
the
codes
that
we
needed
to
so
the
the
key
requirements
for
our
kind
of
action
plan
that
I
put
forward
was
we
needed
to
be
able
to
enable
remote
working.
We
needed
to
work
with
what
we
had.
We
had
no
additional
budget
for
this
and
we
needed
a
quick
turnaround
as
quick
as
possible.
B
B
So
I
ended
up
using
mysql
for
our
data
git
lab
for
our
life
cycle
management
and
pocket
so
that
I
could
push
some
infrastructure
to
the
the
client
notes
why
these
tools,
so
I'm
kind
of
a
little
bit
nerdy.
But
I
I
run
a
few
servers
at
home.
I've
got
plaques
up
and
running,
so
my
boys
can
can
watch
as
much
frozen
as
they
want
on
their
tablets.
So
I
use
docker
for
that.
B
So
I
would
suggest
that
anyone
wanting
to
implement
changes
do
your
biggest
changes.
First,
I
mean
with
devops
there's
normally
a
big
mindset
shift
that
needs
to
happen
and
just
unlock
the
potential
quick
get
your
quick
wins,
it'll
be
a
big
help.
So
I
wanted
to
show
our
current
devops
score.
I
mean
it
looks
relatively
low,
but
I'm
I'm
really
proud
of
it.
It
kind
of
shows
that
what
I've
implemented
is
starting
to
to
click
and
starting
to
work.
So
people
are
happy
putting
issues
on
the
board
and
supplying
comments
for
peer
reviews.
B
So
where
are
we
going
to
go
next?
I
think
we
just
need
to
push
further
and
further
further
down
this
devops
chain.
So
I
want
to
utilize
ci
cd
for
all
of
our
testing
requirements.
Get
those
automated
build
our
method
into
a
container,
so
we
can
get
a
docker
image
that
we
can
deploy,
eventually
go
cloud-based
and
join
everybody
else
using
python
3..
B
B
We've
got
a
framework
to
build
on
our
peer
reviews
are
so
much
simpler
now
and
we're
configuration
controlled.
Finally,
we're
starting
to
automate
these
really
refessive
tasks,
which
is
really
good
to
see.
So
I'm
really
pleased
with
where
we
are
at
the
minute
and
kind
of
there's
a
closing
remark.
What
I
would
say
is
just
go
trust
yourself,
regardless
of
your
position,
if
you,
if
you
feel
any
part
of
devops,
will
give
you
a
benefit,
then
then
make
those
changes.