DevOps is an approach that aims to unify software development (Dev) and software operation (Ops) practices to reduce the time between code changes and deployment to production. Some key aspects of DevOps include: - Cross-functional teams that include both developers and operations staff - Automating testing, builds, and deployments to speed up the delivery process - Continuous integration, delivery, and deployment to get code changes to users faster - Monitoring and measuring key metrics like change lead time to track progress

1. DevOps 101
Liran Y. Levy
Product Manager

2. About Me
2
 Product manager for ALM Octane
 Previously Sr.DevOps Manager for ADM Lifecycle Management portfolio-
 ALM/QC
 AGM
 ALM Octane
 7+ Years in HPHPEMF
 liran.levy@microfocus.com
 Linkedin

3. The DevOps Notion

4. Creating Value
Dev Product Customer
$$$
Hey,
Show me the value !
We have lots
Of great ideas !
Get them to the
Customer fast !
QA Ops
How can
we help ?

5. The Technology Value Stream (TVS)
5
Plan Define Develop Integrate Test Release Deploy Operate
Business Customer

6. Dev QA Ops Eng. Customer
Don’t know
if want…
TVS with Change Lead Time (CLT) of Months

7. Dev QA Ops Eng. Customer
This is want I
wanted !
TVS with Change Lead Time (CLT) of Hours/Days

8. DevOps Mission Statement
IdeaFeature, Bug
Fix, Enhancement
Deliver fast (low CLT) w/ quality
Get feedback
Customer

9. DevOps In Theory
DevOps is the philosophy of unifying functional teams across culture, processes and
tools to achieve accelerated and more frequent delivery of value to the customer, by
improving quality in order to increase velocity.
DevOps can also be viewed as:
• The outcome of applying lean principles to the technology value stream.
• The response to the interdependence of software development and IT operations.
• The natural continuity of the lean startup movement.

10. DevOps In Practice
In practical terms DevOps can involve any combination of a wide range of ideas:
• Agile software development
• Cross-functional teams
• Continuous testing's
• Continuous integration
• Continuous delivery
• Continuous deployment
• Continuous Operations
• Test, Build and deployment automation
• Deploy the same to all
• Ops shifts to:
• Infra as a Code
• Configuration as a Code
• Dev shifts to:
• Fixing production problems
• Plan for security, resilience and scalability
• Data driven lifecycle management
• ….

11. DevOps Principals - The 3-Ways
Putting the first way into practice
include enabling fast flow
through the technology value
stream.
Putting the second way into
practice include detecting errors
as fast as possible. And stop
them from passing along the
value stream.
11
Putting the third way include
creating a culture of learning
and experimentation to improve
the value stream.

12. The DevOps Elements

13. The DevOps Elements
Culture
Tools
Processes
Measurement

14. Processes
14
Continuous Integration (CI)
Continuous Delivery (CD)
Continuous Deployment (CD)
Develop Integrate Test Release Deploy

15. Culture
Plan for small batchesCross-functional teams
Take ownership and
Immediately fix failures
Blameless post mortem
Encourage learning and
experiments
Collective knowledge
mechanisms

16. Tools

17. Measurement
CLTChange Lead Time
• The time elapse from pushing a change to the mainline and till it reach production
CFTChange Feedback Time
• The time elapse from pushing a change to the mainline and till getting a feedback from the CI server
CFRChange Failure Rate
• The number of failures out of the total number of changes
MTTRMean Time To Recover
• The mean time elapse from alerting on CI break till fixed by RnD
CRCoverage Rate
• The number of code lines covered by tests out of the total number of code lines

18. Examples: Enabling Flow

19. Continuous Delivery Landscape
19
Contributor
SCM CI CD CustomerARM
FeedbackPush
Publish

20. Continuous Integration Landscape
20
Contributor
Push Changes
SCM
Push Trigger
Feedback
ARM
Publish
DB
CI Server Build
Servers
Test Servers
AUT
Servers
Package
Stop
App
Integration
Tests
API Tests
Start
App
System
Tests
Static
Analysis
Unit TestsCompile
Push
Validations

21. Example: Java Stack
21
Package
Stop
App
Integration
Tests
API Tests
Start
App
System
Tests
Static
Analysis
Unit TestsCompile
Push
Validations

22. Continuous Delivery Landscape
22
DB
Orchestor Server
LB App
Servers
Customer
UI
Servers
ARM
Smoke
Test
Start AppUpgradeConfigureExtractFetchStop App

23. Example: Java Stack
23
Smoke
Test
Start AppUpgradeConfigureExtractFetchStop App

24. 24
~7000 automated tests
Example

25. Examples:
Enabling Feedback Loops

26. 26
CI Reporting

27. 27
Canary Release Gradual Exposure

28. 28
Google Analytics

29. Examples:
Enabling Continuous Improvement

30. 30
Decoupled Architecture
Pros Cons
Monolithic 1
All functionality in one
application
• Simple at first
• Low inter-process latencies
• Single codebase, one deployment unit
• Resource-efficient at small scales
• Overhead increases as team grows
• Poor enforcement of modularity
• Poor scaling
• All-or-nothing deploy (downtime, failures)
• Long build times
Monolithic 2
Sets of monolithic tiers:
“front end presentation,”
“application server,”
“database layer
• Simple at first
• Join queries are easy
• Single schema, deployment
• Resource-efficient at small scales
• Tendency for increased coupling over time
• Poor scaling and redundancy (all or nothing, vertical
only)
• Difficult to tune properly
• All-or-nothing schema management
Microservices
Modular, independent,
graph relationship vs. tiers,
isolated persistence
• Each unit is simple
• Independent scaling and performance
• Independent testing and deployment
• Can optimally tune performance
(caching, replication, etc.)
• Many cooperating units
• Many small repos
• Requires more sophisticated tooling and
dependency management
• Network latencies
CLT/
CFT/
CFR/
MTTR

31. 31
Blue-Green Deployment CLT

32. 32
0 Tests == 0 Productivity
Mainline is not stable to
work with
5000 Tests == 0 Productivity
Mainline has high probability
that at least 1 test is failing so
cannot push
Max productivity
The right test coverage
that ensure mainline is
stable for most
CI should be here
Maximize the Productivity Function CLT/
CFT/
CFR/
MTTR

33. Quick Full Integration
Example: CI Layering
33
•Purpose - Developers can work
•When - After every commit
•If tests failed - Stop
•What to test - Core flows in the system
Quick
• Purpose - Software pass basic sanity
• When - Every 3 hours
• If tests failed - Investigate
• What to test - Basic sanity
Full
• Purpose - The echo system works
• When - Every night
• If tests failed - Open defect
• What to test - Deployment, upgrade, integrations
Integration
CFT

34. Thank You !