%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
DevSecOps for the DoD
1. A short history lesson (for context) and a case for the
future of software development and delivery in the DoD.
DevSecOps for the DoD
James Harmison
Sr. Specialist Solutions Architect
North American Public Sector
jharmison@redhat.com
2. A short history lesson (with context)
Where we’re coming from, why and how did we get to DevOps
1970
4. Source:
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
“[...] the implementation described above is risky and
invites failure. [...] The testing phase which occurs at
the end of the development cycle is the first event for
which timing, storage, input/output transfers, etc., are
experienced as distinguished from analyzed. [...] Yet if
these phenomena fail to satisfy the various external
constraints, then invariably a major redesign is
required.”
Waterfall Development Model?
5. Source:
https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/PB121670.xhtml
Where Waterfall Came From
● 1956 Office of Naval Research
symposium
● Presented by engineers from Lincoln
Laboratories at MIT
● First known recorded instance of a set
of linear phases for software
development
● Operational Plan
○ Machine Specifications
○ Operational Specifications
○ Program Specifications
● Coding Specifications
● Coding
● Parameter Testing Specifications
● Assembly Testing Specifications
● Shakedown
● System Evaluation
Symposium on Advanced Programming Methods for Digital Computers
(broad requirements)
(definition of required hardware -
predates common ISAs)
(definition of the expected interfaces)
(overall program architecture)
(interface design for subcomponents)
(implement coding specifications)
(basically, unit testing)
(basically, integration testing)
(basically, E2E testing)
(basically, acceptance testing)
13. Source:
https://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf
The Lesson the DoD Learned
● “This standard [...] establishes uniform
requirements for the software development that
are applicable throughout the system life cycle.”
● “The contractor shall implement a software
development cycle that includes the following six
phases:”
● Contractors can select any development
methodology they like, as long as it’s waterfall.
DOD-STD-2167A 4 JUNE 1985
14. A short history lesson (with context)
Where we’re coming from, and why did we get to DevOps
1994-ish
1956? 1970?
1976? 1985?
?
15. Source:
http://www.cvauni.edu.vn/imgupload_dinhkem/file/pttkht/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf
“Amateurs often want to follow cookbook steps;
professionals know that right approaches to
development usually lead to inept design products, born
of a progression of lies, and behind which developers can
shield themselves from accepting responsibility for
earlier misguided decisions. The amateur software
engineer either ignores documentation all together, or
follows a process that is documentation-driven, worrying
more about how these paper products look to the
customer than about the substance they contain. The
professional acknowledges the importance of creating
certain documents, but never does so at the expense of
making sensible architectural innovations.”
The Booch Method
16. Source:
http://www.cvauni.edu.vn/imgupload_dinhkem/file/pttkht/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf
The Booch Method
● Often explicitly tied to his diagramming format
● Diagramming format led to UML
● Chapter 6 - The Process
○ Two major traits:
■ Strong architectural vision
■ Iterative, incremental design
● “How then do we reconcile the need for creativity
and innovation with the requirement for more
controlled management practices?”
○ Two distinct loops
■ Carried out independently/overlapping
■ One satisfied management, the other
created good software
OBJECT-ORIENTED ANALYSIS AND DESIGN (second edition) Ch. 6
18. Source:
http://www.cvauni.edu.vn/imgupload_dinhkem/file/pttkht/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf
The Booch Method
● Emphasis on OOP in terminology
● Very low-level
○ “The micro process of object-oriented
development is largely driven by the stream
of scenarios and architectural products that
emerge from and that are successively
refined by the macro process.”
● Individual steps can be adjusted for other
programming paradigms, languages, frameworks
○ What are you trying to accomplish
○ What constructs could help get you there
○ How should the constructs connect
○ Design interfaces, implement
The Micro Development Process
19. A short history lesson (with context)
Where we’re coming from, and why did we get to DevOps
1994-ish
1956? 1970?
1976? 1985?
?
ISO/IEC/IEEE 12207
1995
25. Source:
https://www.iso.org/standard/63712.html
So What Happened?
ISO/IEC/IEEE 12207
● 1995 - 57 pages
● 2008 - 123 pages
● 2017 - 145 pages
The standard is BLOATED, and it gets
more bloated all the time. It is less about
the software and more about the
processes that ISO, IEC, and IEEE view as
necessary to support software. The
development is a black box. The
operations, too.
But delivering software isn’t just writing
software. There needs to be something.
26. A short history lesson (with context)
Where we’re coming from, and why did we get to DevOps
1994-ish
1956? 1970?
1976? 1985?
?
ISO/IEC/IEEE 12207
1995
2001
The Agile Manifesto
28. Source:
https://agilemanifesto.org/principles.html
Principles Behind the Agile Manifesto
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
29. Source:
https://www.halfarsedagilemanifesto.org/
Manifesto for Half-A**ed Agile Software Development
We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:
Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact
Working software over comprehensive documentation
as long as that software is comprehensively documented
Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.
Cobbled together one Saturday morning before breakfast by
Kerry Buckley (@kerryb), following an article by Ron Jeffries
and this suggestion from Eastmad.
30. A short history lesson (with context)
Where we’re coming from, and why did we get to DevOps
1994-ish
1956? 1970?
1976? 1985?
?
ISO/IEC/IEEE 12207
1995
2001
The Agile Manifesto
2008
DevOps
32. Source:
https://www.youtube.com/watch?v=LdOe18KhtT4
10+ Deploys Per Day
TOOLS
1. Automated infrastructure
2. Shared version control
3. One step build and deploy
4. Feature flags
5. Shared metrics
6. IRC and IM robots
CULTURE CHANGES
1. Respect
2. Trust
3. Healthy attitude about failure
4. Avoiding Blame
John Allspaw and Paul Hammond (Flickr)
Dev and Ops Cooperation at Flickr
33. 10+ Deploys Per Day
https://red.ht/10-deploys
Dev and Ops Cooperation at Flickr
35. A short history lesson (with context)
Where we’re coming from, and why did we get to DevSecOps
1994-ish
1956? 1970?
1976? 1985?
?
ISO/IEC/IEEE 12207
1995
2001
The Agile Manifesto
2008
DevOps
DevSecOps
2012
36. “The community of developers
whose work you see on the Web,
who probably don’t know what
ADO or UML or JPA even stand
for, deploy better systems at less
cost in less time at lower risk than
we see in the Enterprise.”
Source:
https://www.tbray.org/ongoing/When/201x/2010/01/02/Doing-It-Wrong
Tim Bray
Doing It Wrong, 2010
DevSecOps in a Nutshell
You’re doing it wrong.
39. DevSecOps
Think About The DoD
● Acquisition-heavy (dev is hard)
○ “Soldiers don’t build weapons”
○ Contractors/Civs either, really
■ (mostly just Ops)
● Security-heavy (risk-averse)
○ RMF, MDMP, ATO
● Rooted in process, procedures,
checklists (not just security)
● Many manual processes
● Tons of rework
○ Every small problem is not unique
■ (novel solutions make for
better evaluation bullets)
40. DevSecOps
Some First Steps (and what they may get you)
● Incorporate your application vendors
○ Maybe contractually?
○ Maybe just take their releases
■ (build your own tests)
● Accredit processes
○ Not systems
● Abandon the checklists, automate the
processes, put the procedures in
documentation, and train better
● Working towards this now (CFT)
○ It’s been done this before (BCT)
■ You’ve got to build communities,
and celebrate them.
● Acquisition-heavy (dev is hard)
○ “Soldiers don’t build weapons”
○ Contractors/Civs either, really
■ (mostly just Ops)
● Security-heavy (risk-averse)
○ RMF, MDMP, ATO
● Rooted in process, procedures,
checklists (not just security)
● Many manual processes
● Tons of rework
○ Every small problem is not unique
■ (novel solutions make for
better evaluation bullets)
42. linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
Red Hat is the world’s leading provider of enterprise
open source software solutions. Award-winning
support, training, and consulting services make
Red Hat a trusted adviser to the Fortune 500.
Thank you
James Harmison
Sr. Specialist Solutions Architect
North American Public Sector
jharmison@redhat.com
Slide Download Link:
https://red.ht/devsecops-dod
