📺 Develpreneur YouTube Episode

Video + transcript

Dev Ops Overview - Part 1

2022-03-24 •Youtube

Detailed Notes

DevOps is a hot topic in recent years.  However, it is often misunderstood or ill-defined.  This presentation tries to correct that.  We look at its short history and how DevOps is used.  Likewise, we look at the pros and cons involved when your team embraces this facet of software development.

DevOps Is a Steadily Growing Area While a young way to look at a part of the software development process, it is still rapidly growing.  The tools available to assist in this area grow daily.  Also, the growth of the Cloud and systems deployed there make DevOps more and more a necessity for developing modern solutions.

Transcript Text
[Music]
so focus today in this presentation is
devops it is definitely a buzzword
something we've heard about a lot
depending on what
size company you're in
but even
even mid and even small size companies
there is
a
sense of devops in a lot of cases
and particularly when you get into the
world of cloud
it really
you'll find as we're talking through it
it is well suited to a lot of the cloud
related
features the pros and cons of working in
the cloud
so we're going to
give a nice little overview of that
today it's definitely a
an area that you can go deeper in it's
like
like agile it's one of these things that
it's
there are a lot of pieces so you can say
you do it but you may or may not do
different pieces of it you may do it
differently
uh it's definitely just we're gonna hit
sort of the tip of the iceberg to try to
get an idea of what they are and
what
things fall into the
under the umbrella of devops
and so we'll start with just a sort of a
brief little sort of definition
a little bit of the history of it which
we'll find is not very deep or long uh
what does it provide why who cares
basically about this devops thing what
does it do for us and then talk about
some of the practices the methods that
are
that fall under that umbrella that are
devops practices and methods
how you
how it fits in with some of the various
methodologies that are out there
and then sort of a pros and cons
benefits and concerns about
devops and what you what you get out of
it and what you need to be worried about
with it
so definition
um and this came unfortunately i forgot
the link to where this came from but i
think it was off basically on wikipedia
but um the word devops it's a
combination of just development and
operations so it's as you would sort of
guess what it means that's what it is
it's the development and operations and
it is where you have a collaboration
between the developers
and the operation side of software
development developers are the ones that
are building software operations are the
ones that are basically deploying
maintaining doing upgrades and patches
and things of that nature
they
sometimes it's configuration management
back in the day
when we think about the waterfall life
cycle software development life cycle
we talk about a there's a deployment
step that's typically
the operations type people are taking
that that's what they own
in its broadest meaning it is a
philosophy that promotes better
communication and collaboration between
these teams
there have been
historically
it's almost like a throw it over the
wall approach where the developers do
their stuff they say all right i've got
it on a you know development machine or
a testing machine or something like that
and now we're going to send it off the
operations people
and they
promote it to production and they have
to deal with it
doesn't work super well doing that
so devops is a way to try to clean up
that relationship and make it smoother
and along the way do some other things
like remove
you know make it less error prone
make it more
streamlined scalable things of that
nature
it also covers
the term devops also covers culture
changes
that is
how we change looking at the development
team and the operations team in some
cases they've been seen as
vastly different
groups that don't really you know back
that communication thing they don't
really talk they don't do much together
they don't they don't interact much
and or when they do it's you know
through a simple email or document or
something like that
this turns us in devops has more idea of
like bringing those
groups together so there's much more
cohesion from
the beginning of creating software all
the way through deploying it and testing
it and putting it out to production
making sure that we've got
the platforms and the places that we're
putting these things the you know the
servers and the resources
match
appropriately
and so that devops is sort of the
uh
they help look at that
and help the development team
do a better job of moving their code out
to
[Music]
testing and users
things of that nature but this because
of all this
devops includes there's different roles
there's different approaches there's
different views there's different best
practices
and all of this will sort of like i said
we'll touch on there's a you could spend
days there's devops conferences and such
out there you could spend a lot of time
talking about it we're gonna
try to cover it in a very short period
of time
so brief history which you'll find there
there isn't much more than a brief
history of devops
it was a it's a term that was
essentially created in 2009 by patrick
dubois it was actually
through a conference it was the dev ops
conference
and from there
uh it quickly has grown into
there's
devops became something that was like oh
that's a neat idea to this is something
we really want to use
it was embraced within the first few
years by the itil
champions people that are into processes
and reproducing
software development tasks and promotion
and deployment tasks
it's
if you want to think of sort of a
[Music]
a core document about devops
is there's a fictional book called the
phoenix project that came out in 2013
and it
definitely it gives you sort of the
instead of the theory it's hey here's
how this would look it's more of an uh
an application view
of
devops and how that should work in the i
guess in the real world
it's really been
it's been embraced and sometimes is
intertwined with continuous integration
content continuous deployment
because definitely that
you really almost need devops to do that
so that you've got people that are
that own the cicd part of development as
opposed to like coders that are or you
know software developers that are
writing stuff you have they just don't
have the time or the bandwidth a lot of
times to do
the integration and deployment piece and
so that's where devops has become more
and more of a
almost a need
and when you look at agile and rapid
turnarounds if you look at
cloud infrastructures
as code and things like that
there were a lot of changes in the last
almost 15 years now
that have really helped
push devops to the forefront and
made it much more valuable
much more
useful if you go back 20 or 30 years ago
when you had
essentially zero virtual machines
there was it was a different
approach and you can't you know like you
can't use
source code to create a physical hard
server
if you've got vms you can you can spin
stuff up and down based on code so
there's things like that that
just the progression of technology has
allowed devops to become
a thing and a very useful one and
something that we probably do more often
than we think
so with that what is what does devops
give us how does that help us in our
software development tasks
now
devops although it is not the same as
continuous integration and deployment
there's
it it enables that
it makes that something that we can do
and
it's really almost it really is also
goal of devops is to do
that is to have that
quick and steady and
continuous flow of code into
uh some sort of a production type or a
usable environment it may not be
production it could be test it could be
some sort of staging environment and
something along those lines
and so when you have that
when you have things like either
instantaneous or daily builds
and deployments then you're by nature
going to have smaller and more easily
reversible changes to the code
you're going to be doing smaller blocks
of work
and you're going to
be validating that within the bigger
system on a regular basis
so if you do that if you do daily builds
and with daily builds it's implying that
there's also
a social regression test going on and
things like that so code is committed
validated maybe reviewed
there's a regression test it goes
through
then it gets pushed out
and if not if it fails anywhere then you
get a message back to so you know that
your little bit of code whatever you
worked on today
didn't work
however you know you may get more or
less details than that but you know what
what broke you know it was the work you
did today and not necessarily the work
you did in the last three months or
something like that or i guess it's the
work you've committed today so it could
have been work you've been working on
for a while but
typically because of how
devops
pushes us as a development teams
we're more likely to do
frequent more frequent commits smaller
sections of code much more
defined and then that makes it easy to
reverse you know easy to pull it back
out and also easier to debug
and that leads to shorter cycle times
from requirements all the way up to live
software
because much like we've talked about
when we talk about agile and
sprints
and ideally you're releasing software at
the end of every sprint or you know
every other sprinter every third sprint
or whatever it is
but there's regular deployment there's
regular software made available to users
ci cd
it's an even shorter cycle time
so
you may see you may have requirements
and you may see live software that's you
know some pieces of functionality that
are showing up you know within days
it gives us
devops gives us silos for development
and operations and really
highlights that those exist when we
talked way back when we talked about the
waterfall
approach the waterfall methodology
that was one of the things is you had
these silos for
testing for development
when you got to deployment it was a
little murky because it depended on the
size of software depending on the
environment and a lot of times you would
have the developers or the testers would
also be
essentially the operations piece
or
in some cases operations wasn't even
considered until after the fact so you
would go build software put it out there
to users and then say oh crud i gotta
have a i'm gonna have some sort of
support desk or something like that
and it wasn't
it wasn't really considered it wasn't
definitely was not part of development
it was just sort of this other thing
that was like a attack on add-on thing
we do after the software is done
and
what devops gives us is highlighting
that these are the roles that we need
this is uh these are skill sets that we
need this is experience that we need in
these various areas we we're comfortable
with yeah we need developers but there's
also operations that needs to be there
and we need to
account for that
with the
with some of the things that devops
gives us the ability to move
quickly from
like a development environment to a
staging environment or testing
environment production
we have more
realistic testing opportunities
instead of
developers just sort of creating their
own little uh development sandbox and
they're playing around and doing stuff
and their code's not necessarily all
together and you know up to date with
everybody else's
and their test data may be completely
wonky
now you've got these environments that
you can actually
make them more
real for lack of a better term
but put actual maybe something that is
much closer to mimicking
the
what the production environment is going
to look like as far as like including
size of data if you're a developer and
you've got to enter in data you're not
going to enter into more than a few
records because it just takes too much
time
but if you've got a team
that's either you know maybe the
operation side is has some data load
scripts or
you just have a lot of people working on
the system you're going to get more data
and it's going to be different from what
you would do as a developer and so you
have better testing opportunities you
get to test more against something that
that looks real when you're doing it
using devops
a key thing to hold this is that then
starts it it gets us closer to solving
the it works on my machine problem which
you see a lot of times with developers
where they they write their code they do
a build that works for them they can
show you it works for them they can show
you exactly how it it is but then as
soon as you put it to somebody else's
machine as soon as you put it to the
test environment it breaks
and because
without devops
we don't necessarily know what the
differences are between the development
chain and the qa machine and
development in particular because it
developers are famous for having a whole
bunch of stuff on their
uh on their machine in their environment
that is not going to be there even when
you go to the test or the stage
environment
and those things can
you know those can impact whether
something works or not
so if you don't really if you don't know
what you have if you can't define
in detail the differences in the
environments it's that much harder to
figure out
why it doesn't work
the flip side if you've got
you know like
go to the nicest thing if you've got a
script that builds your
development environment then that same
script should be able to point to your
qa environment and build that and so you
know that the environments are
for all intents and purposes identical
and that way if it works on the
development machine
then it needs to work you know you know
it's going to work on the qa machine or
vice versa or at the very least
you know that it's not a difference in
the machine in the in the environment
itself
or at least you've got a better starting
point i guess
so let's talk about some of the
practices and methods i've actually
touched on some of these already
but i think it's good to you know walk
through them and and this may have even
been one of those things that's sort of
out of place in the presentation but
i think there were it helps to
give you an idea of what the value is of
devops a little bit and at a high level
before we get into some of the
specifics
so
some
specific things that you're going to
find in
devops one is build automation i've
talked about this already uh which is
basically combined with infrastructure
as code
is devops is going to automate as many
things and script out as many things as
possible
when you think of you know if you want
to do a comparison think about testing
is that there are manual testers
and there's automated testing and
as you grow systems you want more and
more to be automated testing because you
just
it's not feasible
to do
manual testing with the uh the frequency
and the size that you want
devops is the same thing
when you get into operations where
you're building out
dozens maybe hundreds maybe thousands of
machines or devices or deploying out to
them
[Music]
you're dealing with you know maybe
as many projects
millions of lines of code and all these
different complex build strategies and
integrations and things like that
you want to automate it it's not
something where you want somebody you
know they have to run this script and
they have to type this thing in they
have to build this and do this other
thing
you want that
done as a script
and there are a lot of tools that help
us do this
uh you can look at hudson hudson and
jenkins and things like that that have
been around for a while that
provide us these ci cd tools continuous
integration and employment ways to
commit software commit code changes
and then have a process somewhere that's
watching that says hey i have a commit
i'm gonna do a build whatever that looks
like i'm gonna you know check out the
latest code
if i if there's merges or something
maybe it does it maybe it kicks back to
somebody that says hey this requires a
manual merge
if it's gonna do the build it's going to
run through some sort of test
to say yep the build was successful we
built what we wanted to and it roughly
works
and then push it out to you know deploy
it out to some target whether that's uh
it could be a development machine it
could be
qa or even production
you
Transcript Segments
0.62

[Music]

26.8

so focus today in this presentation is

29.76

devops it is definitely a buzzword

32.96

something we've heard about a lot

34.32

depending on what

35.68

size company you're in

37.76

but even

38.96

even mid and even small size companies

41.12

there is

42.32

a

43.12

sense of devops in a lot of cases

45.84

and particularly when you get into the

47.2

world of cloud

49.12

it really

50.96

you'll find as we're talking through it

52.8

it is well suited to a lot of the cloud

55.84

related

57.44

features the pros and cons of working in

59.28

the cloud

60.879

so we're going to

62.32

give a nice little overview of that

64.239

today it's definitely a

66.32

an area that you can go deeper in it's

69.6

like

71.04

like agile it's one of these things that

72.72

it's

73.76

there are a lot of pieces so you can say

76

you do it but you may or may not do

78.08

different pieces of it you may do it

79.6

differently

80.799

uh it's definitely just we're gonna hit

82.799

sort of the tip of the iceberg to try to

84.56

get an idea of what they are and

86.88

what

87.68

things fall into the

90.159

under the umbrella of devops

93.92

and so we'll start with just a sort of a

95.759

brief little sort of definition

98.4

a little bit of the history of it which

100.64

we'll find is not very deep or long uh

103.52

what does it provide why who cares

105.6

basically about this devops thing what

107.36

does it do for us and then talk about

109.04

some of the practices the methods that

110.72

are

112.24

that fall under that umbrella that are

114.32

devops practices and methods

117.119

how you

118.479

how it fits in with some of the various

120

methodologies that are out there

122.079

and then sort of a pros and cons

123.6

benefits and concerns about

126.159

devops and what you what you get out of

128

it and what you need to be worried about

129.84

with it

131.68

so definition

134.08

um and this came unfortunately i forgot

136.48

the link to where this came from but i

138

think it was off basically on wikipedia

139.599

but um the word devops it's a

141.84

combination of just development and

143.28

operations so it's as you would sort of

145.68

guess what it means that's what it is

148

it's the development and operations and

150.48

it is where you have a collaboration

153.2

between the developers

154.959

and the operation side of software

157.92

development developers are the ones that

160

are building software operations are the

161.84

ones that are basically deploying

164.239

maintaining doing upgrades and patches

166.64

and things of that nature

168.72

they

169.68

sometimes it's configuration management

171.519

back in the day

173.12

when we think about the waterfall life

175.92

cycle software development life cycle

178.8

we talk about a there's a deployment

181.04

step that's typically

183.12

the operations type people are taking

186.72

that that's what they own

189.68

in its broadest meaning it is a

191.68

philosophy that promotes better

193.2

communication and collaboration between

194.959

these teams

196.159

there have been

197.44

historically

198.959

it's almost like a throw it over the

200.239

wall approach where the developers do

201.76

their stuff they say all right i've got

203.76

it on a you know development machine or

205.92

a testing machine or something like that

207.28

and now we're going to send it off the

208.48

operations people

210

and they

211.04

promote it to production and they have

213.12

to deal with it

215.04

doesn't work super well doing that

218.08

so devops is a way to try to clean up

220.56

that relationship and make it smoother

223.92

and along the way do some other things

226

like remove

227.92

you know make it less error prone

230.159

make it more

231.599

streamlined scalable things of that

234.08

nature

235.92

it also covers

238

the term devops also covers culture

240.08

changes

241.36

that is

244.159

how we change looking at the development

246.48

team and the operations team in some

248.4

cases they've been seen as

250.4

vastly different

252.319

groups that don't really you know back

254.159

that communication thing they don't

255.519

really talk they don't do much together

258.239

they don't they don't interact much

261.44

and or when they do it's you know

263.6

through a simple email or document or

265.6

something like that

267.6

this turns us in devops has more idea of

270.16

like bringing those

272.479

groups together so there's much more

275.12

cohesion from

276.72

the beginning of creating software all

278.88

the way through deploying it and testing

280.639

it and putting it out to production

282.639

making sure that we've got

284.24

the platforms and the places that we're

286.88

putting these things the you know the

288.639

servers and the resources

291.12

match

292.16

appropriately

294.32

and so that devops is sort of the

296.56

uh

297.44

they help look at that

299.52

and help the development team

301.919

do a better job of moving their code out

305.52

to

305.81

[Music]

307.039

testing and users

309.199

things of that nature but this because

310.96

of all this

312.24

devops includes there's different roles

314.08

there's different approaches there's

315.36

different views there's different best

316.96

practices

318.479

and all of this will sort of like i said

320.72

we'll touch on there's a you could spend

322.8

days there's devops conferences and such

325.6

out there you could spend a lot of time

327.44

talking about it we're gonna

329.199

try to cover it in a very short period

331.36

of time

336.32

so brief history which you'll find there

339.12

there isn't much more than a brief

340.88

history of devops

343.12

it was a it's a term that was

344.479

essentially created in 2009 by patrick

347.68

dubois it was actually

350.08

through a conference it was the dev ops

352.639

conference

354.16

and from there

356.08

uh it quickly has grown into

359.52

there's

360.4

devops became something that was like oh

362

that's a neat idea to this is something

364.56

we really want to use

367.36

it was embraced within the first few

368.88

years by the itil

370.88

champions people that are into processes

373.44

and reproducing

376.24

software development tasks and promotion

379.039

and deployment tasks

381.84

it's

383.28

if you want to think of sort of a

384.68

[Music]

385.919

a core document about devops

389.52

is there's a fictional book called the

391.28

phoenix project that came out in 2013

394.319

and it

395.919

definitely it gives you sort of the

398.96

instead of the theory it's hey here's

400.88

how this would look it's more of an uh

403.199

an application view

405.039

of

405.919

devops and how that should work in the i

408

guess in the real world

410.16

it's really been

412.96

it's been embraced and sometimes is

414.72

intertwined with continuous integration

416.8

content continuous deployment

419.28

because definitely that

421.12

you really almost need devops to do that

423.52

so that you've got people that are

425.84

that own the cicd part of development as

428.88

opposed to like coders that are or you

431.039

know software developers that are

432.319

writing stuff you have they just don't

434.08

have the time or the bandwidth a lot of

436.319

times to do

437.919

the integration and deployment piece and

440.24

so that's where devops has become more

442

and more of a

444

almost a need

445.759

and when you look at agile and rapid

448.4

turnarounds if you look at

450.479

cloud infrastructures

452.4

as code and things like that

454.88

there were a lot of changes in the last

458

almost 15 years now

460

that have really helped

461.919

push devops to the forefront and

464.56

made it much more valuable

466.56

much more

468.16

useful if you go back 20 or 30 years ago

470.56

when you had

471.759

essentially zero virtual machines

475.039

there was it was a different

477.44

approach and you can't you know like you

479.68

can't use

481.28

source code to create a physical hard

483.919

server

485.199

if you've got vms you can you can spin

487.199

stuff up and down based on code so

488.879

there's things like that that

490.479

just the progression of technology has

492.72

allowed devops to become

494.639

a thing and a very useful one and

496.639

something that we probably do more often

498.479

than we think

502.4

so with that what is what does devops

504.56

give us how does that help us in our

506.72

software development tasks

511.36

now

512.24

devops although it is not the same as

516.24

continuous integration and deployment

518.8

there's

521.279

it it enables that

523.36

it makes that something that we can do

526.48

and

527.36

it's really almost it really is also

529.519

goal of devops is to do

531.92

that is to have that

534.64

quick and steady and

537.279

continuous flow of code into

540.8

uh some sort of a production type or a

543.519

usable environment it may not be

544.8

production it could be test it could be

546.48

some sort of staging environment and

548.08

something along those lines

551.279

and so when you have that

553.2

when you have things like either

555.36

instantaneous or daily builds

558.56

and deployments then you're by nature

561.44

going to have smaller and more easily

563.12

reversible changes to the code

566

you're going to be doing smaller blocks

567.839

of work

569.12

and you're going to

571.2

be validating that within the bigger

573.2

system on a regular basis

575.36

so if you do that if you do daily builds

577.6

and with daily builds it's implying that

580.48

there's also

582.16

a social regression test going on and

584.08

things like that so code is committed

586.64

validated maybe reviewed

589.44

there's a regression test it goes

590.88

through

592.48

then it gets pushed out

594.48

and if not if it fails anywhere then you

596.24

get a message back to so you know that

598.399

your little bit of code whatever you

599.6

worked on today

601.36

didn't work

602.48

however you know you may get more or

604.16

less details than that but you know what

608.079

what broke you know it was the work you

609.519

did today and not necessarily the work

611.2

you did in the last three months or

613.279

something like that or i guess it's the

614.88

work you've committed today so it could

616.399

have been work you've been working on

617.44

for a while but

619.6

typically because of how

622.16

devops

623.68

pushes us as a development teams

626.88

we're more likely to do

628.64

frequent more frequent commits smaller

630.72

sections of code much more

633.279

defined and then that makes it easy to

635.04

reverse you know easy to pull it back

636.72

out and also easier to debug

639.6

and that leads to shorter cycle times

641.36

from requirements all the way up to live

644.24

software

645.519

because much like we've talked about

647.279

when we talk about agile and

649.44

sprints

650.48

and ideally you're releasing software at

652.88

the end of every sprint or you know

655.04

every other sprinter every third sprint

656.56

or whatever it is

657.92

but there's regular deployment there's

660.399

regular software made available to users

664.399

ci cd

666

it's an even shorter cycle time

669.04

so

669.76

you may see you may have requirements

671.76

and you may see live software that's you

674.399

know some pieces of functionality that

676.24

are showing up you know within days

679.839

it gives us

681.2

devops gives us silos for development

684.16

and operations and really

686.72

highlights that those exist when we

689.279

talked way back when we talked about the

690.72

waterfall

692.24

approach the waterfall methodology

695.12

that was one of the things is you had

696.32

these silos for

698.079

testing for development

700.399

when you got to deployment it was a

702

little murky because it depended on the

704.399

size of software depending on the

705.92

environment and a lot of times you would

708

have the developers or the testers would

710.88

also be

712.639

essentially the operations piece

715.6

or

716.399

in some cases operations wasn't even

718.639

considered until after the fact so you

720.72

would go build software put it out there

722.8

to users and then say oh crud i gotta

725.68

have a i'm gonna have some sort of

727.12

support desk or something like that

730.16

and it wasn't

732.48

it wasn't really considered it wasn't

734.399

definitely was not part of development

736.079

it was just sort of this other thing

737.36

that was like a attack on add-on thing

739.68

we do after the software is done

742.56

and

743.519

what devops gives us is highlighting

745.36

that these are the roles that we need

748

this is uh these are skill sets that we

750.32

need this is experience that we need in

752.56

these various areas we we're comfortable

754.72

with yeah we need developers but there's

756.839

also operations that needs to be there

760.16

and we need to

761.92

account for that

765.04

with the

767.6

with some of the things that devops

769.04

gives us the ability to move

771.279

quickly from

772.48

like a development environment to a

774

staging environment or testing

775.12

environment production

777.12

we have more

778.56

realistic testing opportunities

780.88

instead of

783.04

developers just sort of creating their

784.959

own little uh development sandbox and

788.32

they're playing around and doing stuff

789.519

and their code's not necessarily all

791.36

together and you know up to date with

793.279

everybody else's

794.639

and their test data may be completely

796.56

wonky

799.04

now you've got these environments that

800.88

you can actually

803.04

make them more

805.279

real for lack of a better term

807.279

but put actual maybe something that is

809.04

much closer to mimicking

811.6

the

812.32

what the production environment is going

813.519

to look like as far as like including

815.6

size of data if you're a developer and

817.519

you've got to enter in data you're not

819.12

going to enter into more than a few

820.56

records because it just takes too much

822

time

823.12

but if you've got a team

825.12

that's either you know maybe the

826.8

operation side is has some data load

829.68

scripts or

830.959

you just have a lot of people working on

832.48

the system you're going to get more data

834.32

and it's going to be different from what

835.839

you would do as a developer and so you

838.8

have better testing opportunities you

841.199

get to test more against something that

843.6

that looks real when you're doing it

845.279

using devops

847.519

a key thing to hold this is that then

849.76

starts it it gets us closer to solving

852.32

the it works on my machine problem which

854.8

you see a lot of times with developers

856.399

where they they write their code they do

858.72

a build that works for them they can

860.8

show you it works for them they can show

862.399

you exactly how it it is but then as

865.36

soon as you put it to somebody else's

867.44

machine as soon as you put it to the

868.8

test environment it breaks

872.72

and because

874.32

without devops

876

we don't necessarily know what the

878.399

differences are between the development

880.48

chain and the qa machine and

883.12

development in particular because it

884.8

developers are famous for having a whole

886.88

bunch of stuff on their

889.199

uh on their machine in their environment

892.399

that is not going to be there even when

894.24

you go to the test or the stage

895.6

environment

896.72

and those things can

898.399

you know those can impact whether

899.76

something works or not

901.36

so if you don't really if you don't know

903.12

what you have if you can't define

906

in detail the differences in the

907.76

environments it's that much harder to

909.44

figure out

910.8

why it doesn't work

912.72

the flip side if you've got

915.36

you know like

916.48

go to the nicest thing if you've got a

918.079

script that builds your

920.16

development environment then that same

922.16

script should be able to point to your

923.68

qa environment and build that and so you

925.76

know that the environments are

927.76

for all intents and purposes identical

930.959

and that way if it works on the

932.079

development machine

933.519

then it needs to work you know you know

935.04

it's going to work on the qa machine or

937.199

vice versa or at the very least

939.36

you know that it's not a difference in

941.68

the machine in the in the environment

943.519

itself

944.8

or at least you've got a better starting

946.56

point i guess

950.56

so let's talk about some of the

951.68

practices and methods i've actually

953.36

touched on some of these already

955.759

but i think it's good to you know walk

958.16

through them and and this may have even

959.759

been one of those things that's sort of

960.88

out of place in the presentation but

963.36

i think there were it helps to

965.519

give you an idea of what the value is of

968.16

devops a little bit and at a high level

970.32

before we get into some of the

972.16

specifics

974.079

so

976

some

976.8

specific things that you're going to

978.24

find in

980.16

devops one is build automation i've

983.04

talked about this already uh which is

985.759

basically combined with infrastructure

987.519

as code

989.199

is devops is going to automate as many

991.759

things and script out as many things as

994.079

possible

995.199

when you think of you know if you want

997.199

to do a comparison think about testing

998.88

is that there are manual testers

1001.839

and there's automated testing and

1004.399

as you grow systems you want more and

1006.48

more to be automated testing because you

1008.56

just

1009.68

it's not feasible

1012

to do

1013.04

manual testing with the uh the frequency

1015.839

and the size that you want

1018.639

devops is the same thing

1020.399

when you get into operations where

1022.959

you're building out

1025.199

dozens maybe hundreds maybe thousands of

1028.799

machines or devices or deploying out to

1031.039

them

1031.39

[Music]

1032.72

you're dealing with you know maybe

1034.88

as many projects

1037.28

millions of lines of code and all these

1039.28

different complex build strategies and

1041.76

integrations and things like that

1044.079

you want to automate it it's not

1045.839

something where you want somebody you

1047.439

know they have to run this script and

1048.64

they have to type this thing in they

1049.919

have to build this and do this other

1051.44

thing

1052.64

you want that

1054.08

done as a script

1056.32

and there are a lot of tools that help

1057.919

us do this

1059.2

uh you can look at hudson hudson and

1061.84

jenkins and things like that that have

1063.2

been around for a while that

1065.28

provide us these ci cd tools continuous

1068.559

integration and employment ways to

1071.76

commit software commit code changes

1075.039

and then have a process somewhere that's

1076.88

watching that says hey i have a commit

1079.52

i'm gonna do a build whatever that looks

1082.08

like i'm gonna you know check out the

1083.84

latest code

1085.12

if i if there's merges or something

1086.799

maybe it does it maybe it kicks back to

1088.48

somebody that says hey this requires a

1090.48

manual merge

1092.4

if it's gonna do the build it's going to

1094.48

run through some sort of test

1096.4

to say yep the build was successful we

1099.52

built what we wanted to and it roughly

1101.28

works

1102.16

and then push it out to you know deploy

1104.24

it out to some target whether that's uh

1106.48

it could be a development machine it

1108

could be

1109.36

qa or even production

1126.72

you