my understanding of fundamentals of DevOps and how it relates conceptually to Agile, Scrum, Kanban, etc.
SlideShare does not allow uploading a new version of existing presentation. Hence I have to upload the new verson.
Goto https://www.slideshare.net/nitinbhide/devops-understanding-core-concepts for latest version.
2. Some basic guidelines
ï This is a âLearning Programâ and not a âtraining
programâ.
⊠Hence your Active Participation is needed.
⊠Participate in discussions
⊠Ask questions/doubts.
⊠If you have not understood some point/concept, Raise your
hand and ASK
ï Avoid side conversations
ï Avoid phone calls/emails.
8/21/2017 Commercial in confidence. (C) Nitin Bhide 2
3. Some basic guidelines
ï Understand that there are no 'absolute truths' in
software development. Hence We may disagree with
some points/ ideas. And THAT IS OK.
ï In dealing with disagreements, focus on the technical
merits.
⊠And not on who said it. (Somebodyâs guidelines, some
books etc etc)
8/21/2017 Commercial in confidence. (C) Nitin Bhide 3
5. Some History
ï DevOps movement really started with a Session in
Velocity Conference in 2009
ï Session was
â10+ Deploys Per Day: Dev and Ops Cooperation
at Flickrâ
by John Allspaw and Paul Hammand
ï Video
6. Dev Vs Ops Conflict
Its Not my
Code, its your
machines
Its not my
machine, its
your code.
10. Discourage change in the interest of stability
OR
Allow change to happen as often as it needs to
Is there way to achieve stability and still
allow change ?
Choice !!!
13. Key DevOps Practices
1. Automated Infrastructure
2. Shared Version Control (between Dev and Ops)
3. One Step Build
4. One Step Build and Deploy
5. Change Tracking â Who, When, What ?
6. Small Frequent Changes and Deploy
7. Feature Flags
8. Shared Metrics
9. ChatBots â IRC/IM Robots
-- John Allspaw and Paul Hammand, Velocity Conf. 2009
14. Culture
ï Respect for One Another (Dev, QA, Ops)
ï Trust
ï Shared Runbook and Escalation Plans
ï Healthy Attitude About Failure
⊠Fail Fast
⊠Assume Operation Failures will occur and plan for fast
recovery
ï Avoid Blame
15. DevOps is NOT EASY
Its easier to continue shouting at each other
However, DevOps is much more rewarding
16. Fast Changing World of DevOps
âą 10+ Deploys per Day in Flickr
2009
âą Amazon â 23,000 deploys/day
âą Google â 5,500 deploys/day
âą Netflix â 500 deploys/day
âą Typical Enterprise â ONCE every Nine Months
2012
17. Business Value of DevOps
Why Companies are suddenly SO interested in DevOps
????
Data shows that Companies who use DevOps have
ï 30X more frequent code deploys
ï 8000x faster code deployment lead times
ï 2x change success rate
ï 12x faster MTTR (Mean Time to Repair)
ï 2x more likely to succeed in profitability, market
share and productivity goals
18. Let me ask you a Question
How long it takes for your team to
deploy a change
that involves one single line of code
??
(rephrasing the quote from Mary Poppendiek, Lean
Software Deveopment Guru)
20. Projects
We are doing âprojectâ, our customerâs operations team
(or another vendor) does a deploy. Now
ï Customer wants all vendors to do DevOps
ï We claim that we are doing DevOps.
Are we ??
21. Desktop Applications
We develop a desktop app and release it to our
Customers/End Users.
ï So we are the âDevsâ but then who is our âOpsâ ?
ï How do we do DevOps then ?
25. DevOps Perspective of SDLC
Design Code Build Test
Deploy
Monitor/Track
in Operation
AnalyzeFeedback
Dev
Ops
26. What are you doing to âlower the risk of changeâ ?
Are your tools practices âlowering the risk of changeâ
DevOps Insight - 2
DevOps
is a way to
LOWER the risk of âChangeâ
with
TOOLS and CULTURE
27. TIP - How to lower the âriskâ of change ?
KEY â Find out what kind of change you are
afraid of
THEN Just do the kind of âchangeâ more
often.
ï For example, deploy everyday rather than holding up a list
of features for end of month deploy
ï Develop tools to roll back a deploy if things go wrong
28. Key DevOps Practices
1. Automated Infrastructure
2. Shared Version Control (between Dev and Ops)
3. One Step Build
4. One Step Build and Deploy
5. Change Tracking â Who, When, What ?
6. Small Frequent Changes and Deploy
7. Feature Flags
8. Shared Metrics
9. ChatBots â IRC/IM Robots
-- John Allspaw and Paul Hammand, Velocity Conf. 2009
29. What are you doing to âLower the Risk of Changeâ ??
ï If you are , then you are following âspiritâ of DevOps
ï Lets list some of these practices/tools that you are
using ?
31. Agile/DevOps/Kanban/LEAN
Agile/DevOps are applying Concepts of âFLOWâ from
Toyota Production System /TQM /LEAN to Software
ï Reduce Batchsize to reduce WIP
ï âPushâ vs âPullâ production systems
ï Left to Right Flow
32. Reduce the âbatch sizeâ and do more
batches/releases/deployments with smaller
number of features/changes/bug fixes
Just do the same kind of âchangeâ more
often.
34. Reduce WIP by reducing batch sizes
ï Timeboxed short sprints
⊠Remember 1 month Sprint has 2x âWIPâ than 2 week sprint
and hence can double the âoverall costâ.
ï Ultimately leading to continuous delivery (or Single
Piece Flow)
ï WIP â Work In Progress Inventory
35. Achieving Early ROI
Monthly/Quarterly
Releases - Worst
ROI
âą Integrated build
prepared on
developer desktop
and tested.
âą Manual work.
Daily Shippable
Build â Better ROI
âą Automated binary
creation
âą Automation of
static analysis,
unit tests, etc
Continuous
Integration â Even
Better ROI
âą Prepare binaries
and run tests on
every commits
âą Really low
regression bugs
Continuous
Delivery â BEST
ROI
âą Best releases are in
end users hands
immediately
âą No more Periodic
Major releases.
36
36. Visual Control
ï Current status of Project is Visible to EVERYONE
ï HOW ?
⊠Burndown charts
⊠Daily Build Status
⊠Status of Automated Tests (Success/Failures)
37. Continuous Improvements and Automation
ï Always Ask
⊠What can I automate ?
⊠What can be improved (in quality, in speed/performance,
etc etc)
⊠What mistakes can be prevented by automation ?
38. Automation - Remember
If you Automate a âmessâ, you get âautomated messâ
â Rod Michael
Most powerful tool that we have as developers
is âAutomationâ
â Scott Hanselman
39. Mistakes WILL Happen â Hence Fail Fast
ï Same as Toyotaâs Principle of âAnyone Can Stop Assembly
Lineâ.
ï Mistakes WILL Happen
⊠How to reduce the impact of mistakes ?
⊠How to detect mistakes early ?
ï How ??
⊠Static Code Analysis
⊠Zero Warnings Code
⊠QA Picks up installable ONLY after all Automated Tests Pass
41. Few Key Practices in DevOps
There are few key practices you have to have.
ï Excellent Configuration Management Practices
⊠This is more than just I know âcommit/updateâ and Hence I am an expert of âversion controlâ
ï A Build Server
⊠A Build Server is a âcenter of the universeâ for software development team.
⊠Daily Build, Continuous Integrations, Automated Tests, static analysis, build packaging etc
etc. ALL happens on Build Server
ï Continuously Develop tools/features to Help Ops
⊠Add Monitoring and Tracking from Day 1 (e.g. centralized logging, crash monitoring etc)
ï Automate the Deploy
42. Excellent Configuration Management
Practices
ï Do you have separate branches for baseline, release, bug fixes in
past releases ?
ï Do you have âdocumented/definedâ branching strategy ? Is every
member of the team know this document âby heartâ ?
ï Do you merge code bases regularly across branches using âsvn
mergeâ or other version control merge tools and NOT WinMerge
or Araxis Merge ?
ï Do you tag every release sent to customer ?
ï Do you have âdefinedâ tagging convention ?
ï Do you regularly review and delete âdead branchesâ ?
ï Do you take âupdateâ and âcommitâ at least twice a day ?
43. Build Server
ï Do you have a âbuild serverâ ?
ï Does your QA Engineer Pickup Build ONLY from Build Server ?
ï Every release package sent to customer is âcompiled/preparedâ on build server and
NOT on developer machine.
ï Do you have a âone clickâ build (and a scheduled daily build)
ï Do you have automated tests running on the build ?
ï Can you prepare a âcompleteâ release package in one click ?
⊠Checkout and compile
⊠Release tagging
⊠Installer creation
⊠Deploy/upload to FTP etc
⊠Notify to users that a new build is available
⊠Fully or partially auto generated ârelease notesâ
ï Does developers give HIGHEST priority to âbuild breakâ ?
⊠Do team check every day for Build Success And Target 99.9% build success rate ?
44. Tools for monitoring
1. Do you have centralized âcrash loggingâ ?
2. Do you have centralized event logging ?
1. Do you use operating system logging facilities like syslog
or windows event log ?
3. Do you have a way of collecting operational metrics ?
4. Do you have a way of visualizing operational metrics
?
5. Do your Ops regularly use your monitoring and
analysis tools ?
45. Automatic Deploy
ï Can you do a âone clickâ deploy ?
ï What is your deploy strategy ?
⊠You push the deploy to server/user OR
⊠User/Server pulls a new update when available?
ï Can you deploy multiple times a day if required?
ï Can you deploy without user being aware of it ?
52. References
ï Slides of 10+ Deploys Per Day: Dev and Ops
Cooperation at Flickr
ï Practical Science of Batch size
(https://yow.eventer.com/yow-2012-1012/the-practical-science-
of-batch-size-by-don-reinertsen-1269)
ï http://www.innolution.com/blog/agile-
documentation-and-the-economics-of-batch-size
53. Unix Philosophy
1. Make each program do one thing well. To do a new job, build afresh rather
than complicate old programs by adding new features.
2. Expect the output of every program to become the input to another, as yet
unknown, program. Donât clutter output with extraneous information. Avoid
stringently columnar or binary input formats. Donât insist on interactive
input.
3. Design and build software, even operating systems, to be tried early,
ideally within weeks. Donât hesitate to throw away the clumsy parts
and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming
task, even if you have to detour to build the tools and expect to throw
some of them out after youâve finished using them.
Doug McIlroy, [McIlroy78] The Bell System Technical Journal. Bell Laboratories.
M. D. McIlroy, E. N. Pinson, and B. A. Tague. âUnix Time-Sharing System
Forwardâ. 1978. 57 (6, part 2). p. 1902.