The document outlines the principles and practices of DevOps, emphasizing the importance of flow, feedback, and continual learning within value streams. It details methods for optimizing work processes, enhancing feedback mechanisms, and fostering a culture of experimentation to improve service delivery. Additionally, it discusses the significance of technical practices, such as automated testing and deployment patterns, to facilitate effective development and operations collaboration.

1. The DevOps
Handbook
HARISH K M

2. Manufacturing Value
Stream Technology Value
Stream
The sequence of activities an
organisation undertakes to deliver
upon.
The sequence of activities
required to design, produce, and
deliver a good or service to a
customer, including the dual flows
of information and material.
Same principle and pattern.
A process required to convert a
business hypothesis into a
technology enable service that
delivers value to the customer.

3. Lead Time Process Time
Clock starts when request
is made and ends when it
is full filled.
Clock starts when we begin
work on the customer
request. This omits the time
that the work is in queue,
waiting to be processed.

4. The Three Ways

5. The Firstway
The Principles of Flow
Enables fast left-to-right flow of work from
Development to Operations to the customer.
In order to maximise flow, we need to make work
visible, reduce our batch sizes and interval of work,
build in quality by preventing defects from being
passed to downstream work centres, and constantly
optimise for the global goals.

6. The Second Way
The Principles of Feedback
Enables the fast and constant flow of feedback from
right to left at all stages of our value stream. It
requires that we amplify feedback to prevent
problems from happening again, or enable faster
detection and recovery. By doing this, we create
quality at the source and generate or embed
knowledge where it is needed - this allows us to
create ever-safer systems of work where problems
are found and fixed long before a catastrophic
failure occurs.

7. The Third Way
The Principles of Continual Learning
Enables the creation of generative, high-trust
culture that supports a dynamic, disciplined, and
scientific approach to experimentation and risk-
taking, facilitating the creation of organisational
learning, both from success and failures.

8. The Firstway
The Principles of FLOW

9. The Principles of Flow
MAKE WORK VISIBLE e.g. Sprint Board, KANBAN
Board

10. The Principles of Flow
• REDUCE BATCH SIZES
Mass production vs Single piece flow
Batch is code

11. The Principles of Flow
• REDUCE THE NUMBER OF HANDOFFS
Automate as much as possible
• Continually identify and elevate our constraints
Environment Creation
Code Deployment
Test setup and run
Overly tight architecture

12. • ELIMINATE HARDSHIPS AND WASTE IN THE
VALUE STREAM
Partially done work
Extra processes, Extra Features
Task Switching, Waiting
Defects, Nonstandard or manual work
Heroics
The Principles of Flow

13. The Secondway
The Principles of
FEEDBACK

14. The Principles of
FEEDBACK
• WORKING SAFELY WITHIN COMPLEX SYSTEMS
• SEE PROBLEMS AS THEY OCCUR
• SWARM AND SOLVE PROBLEMS TO BUILD NEW
KNOWLEDGE
• KEEP PUSHING QUALITY CLOSER TO THE
SOURCE
• ENABLE OPTIMISING FOR DOWNSTREAM WORK
CENTERS

15. The Principles of
Continual Learning
ENABLE ORGANISATIONAL LEARNING AND A SAFETY
CULTURE
INSTITUTIONALISE THE IMPROVEMENT OF DAILY
WORK
TRANSFORM LOCAL DISCOVERIES INTO GLOBAL
IMPROVEMENTS
INJECT RESILIENCE PATTERNS INTO OUR DAILY
WORK
LEADERS REINFORCE A LEARNING CULTURE

16. WHERE TO START ?

17. Green Field Brown Field
Greenfield development is
when we build on
undeveloped land.
Greenfield DevOps projects
are often pilots to
demonstrate feasibility of
public or private clouds,
piloting deployment
automation, and similar
tools.
Brownfield development is
when we build on land that
was previously used for
industrial purposes,
potentially contaminated
with hazardous waste or
pollution.
Brownfield projects often
come with significant
amounts of technical debt,
such as having no test
automation or running on
unsupported platforms.

18. CREATE A VALUE STREAM MAP
TO SEE THE WORK

19. START WITH MOST SYMPATHETIC
AND INNOVATIVE GROUPS

20. IDENTIFY THE TEAMS
SUPPORTING OUR VALUE STREAM
Product Owner
Development
QA
Operations
InfoSec
Release Manager
Technology Executives or Value Stream Manager

21. What Else?
CREATE A DEDICATED TRANSFORMATION
TEAM
AGREE ON A SHARED GOAL

22. CONWAY’S LAW
“organisations which design systems... are
constrained to produce designs which are copies of
the communication structures of these
organisations…. The larger an organisation is, the
less flexibility it has and the more pronounced the
phenomenon.”

23. ORGANISATIONAL
ARCHETYPES
Functional Oriented Organisation
Matrix Oriented Organisation
Market Oriented Organisation

24. Functional
Organisation
Matrix
Organisation
Market
Oriented
Organisation
Optimise for
expertise,
division of labour,
or reducing cost.
Tall hierarchical
organisational
structure.
Have
Development &
Operations Team
separately.
Mix of Both Optimise for
responding
quickly to
customer
needs.
Flat
organisational
structure.
Adopt DevOps.

25. Functional vs Market
Orientation

26. Specialists vs Generalists
vs E-shaped

27. So, To get Greater
Outcome
• Design Team boundaries in accordance with Conway’s Law
• Create loosely coupled architectures to enable developer productivity and
safety
• Keep team sizes small (The two pizza team rule)
• Create shared services to increase developer productivity
• Embed DevOps engineer into our service teams
• Assign an DevOps liaison to each service team
• Invite DevOps to our dev stand-ups and retrospectives
• Make relevant DevOps work visible on shared KANBAN board

28. The Technical
Practices of Flow

29. The Technical Practices of
Flow
• Create the foundations of our deployment pipeline.
Create single repository of truth for the entire system
Enable On-Demand creation of Dev, Test, and Production environments
Spinning up a new environment in Cloud e.g. AWS
Infrastructure as a Code e.g. Terraform
Configuration Management Tools e.g. Ansible
Virtualised environment e.g. Vagrant
Make Infrastructure easier to rebuild than to repair.
• Modify Definition of Development “DONE” to include running in production-like
environments

30. • Enable Fast and Reliable Automated Testing
• Continuously build, test, and integrate our code and
environments.
The Technical Practices of
Flow

31. • Build a fast and reliable automated validation test suite
Unit Tests. Single method, Function or Class tested
in isolation. ‘Stub out’ Databases, Network calls
Acceptance Tests. Test the application as a whole.
Business acceptance criteria of a User Story.
Integration Tests. Testing application correctly
interacts with other production applications
• Catch errors as early in our automated testing as
possible
The Technical Practices of
Flow

32. The Technical Practices of
Flow

33. • Ensure tests run quickly(In parallel, if necessary)
• Test Driven Development. Write our Automated tests before we write the code.
Ensure tests fail
Ensure tests pass
Refactor & Ensure tests pass
• Automate as many of manual tests as possible
• Integrate Performance Testing into our Test suite
• Integrate Non functional requirements testing into our test suite
Availability, Scalability, Capacity, Security, and so forth
• Pull ‘Andon Cord’ when the deployment pipeline breaks
The Technical Practices of
Flow

34. • Enable and practice CI
• Adopt TRUNK based development practices
The Technical Practices of
Flow

35. • Automate and enable low risk releases.
• Ensure we maintain consistent environments.
• Deploying the same way to every environment.
• Automated Smoke testing our deployments.
The Technical Practices of
Flow

36. • Release Patterns
• Environment based release pattern
• Two or more environments. One environment receives customer’s
live traffic. New code is deployed to non-live environment, and the
release is performed moving traffic to this environment.
• E.g.
• Blue Green deployments pattern
• Canary Releases
• Cluster Immune Systems
The Technical Practices of
Flow

37. • Release Patterns
• Application based release pattern
• Modify the application and selectively release and expose
specific functionality by small configuration changes.
• E.g.
• Feature Flag. Visible to Development Team, Internal
employees, Selected customers.
• Dark Launch. Provides testing in production itself.
The Technical Practices of
Flow

38. • Blue Green deployment pattern
• Create two databases
• Decouple database changes from application
changes. Make only additive changes and never
mutate database objects.
The Technical Practices of
Flow

39. • The Canary release pattern
• Cluster Immune System release patterns.
Automatically rollback based on performance
threshold.
The Technical Practices of
Flow

40. • Architect for Low-Risk Releases
• Architectural Archetypes: Monoliths Vs
MicroServices
• Use Strangler Application pattern to safely evolve
our enterprise architecture.
The Technical Practices of
Flow

41. The Technical Practices of
Flow

42. The Technical Practices of
Flow
Strangler Application Pattern
Too tightly-coupled architecture.
Develop, Test, and Deploy the decoupled functionality
independently.
Placing existing functionality behind an API, where it remains
unchanged, and implementing new functionality using our
desired architecture, making calls to the old system when
necessary. When we implement strangler applications, we
seek to access all services through versioned APIs, also
called versioned services or immutable services.

43. The Technical
Practices of Feedback

44. The Technical Practices of
Feedback

45. • Create our centralised Telemetry Infrastructure
Data collection at the business logic, application,
and environments layer
An event router responsible for storing our events
and metrics.
• Create application logging telemetry that helps solving
production issues
DEBUG, INFO, WARN, ERROR, FATAL
The Technical Practices of
Feedback

46. • Create self-service access to telemetry and information radiators
• Find and fill any telemetry gaps
• Business Level. e.g. Number of sales transactions, revenue of sales
transactions, user signups etc.
• Application Level. e.g. Transaction times, User response times, application
faults etc.
• Infrastructure Level. e.g. WebServer traffic, CPU load, Disk usage etc.
• Client Software Level. e.g. JavaScript client errors, Mobile application errors,
crashes etc.
• Deployment Pipeline Level. e.g. deployment lead times, deployment
frequencies, environment status etc.
The Technical Practices of
Feedback

47. • Analyse Telemetry to Better anticipate problems
and achieve goals.
Use MEANS and STANDARD DEVIATIONS to
detect potential problems.
The Technical Practices of
Feedback

49. finally {
if ( !devOpsPrinciplesFollowed || !devOpsPracticesFollowed ) {
}
}

51. For Listening to `this.flow`
Do share `your.feedback`
Thanks