Dev ops culture and practices

60 %
40 %
Information about Dev ops culture and practices

Published on October 26, 2016

Author: AnkaraCloud

Source: slideshare.net

1. DevOps Culture and Practices Sezgin Küçükkaraaslan sezgin@opsgenie.com @Olric https://www.opsgenie.com

2. What is DevOps? Culture ? Collaboration of development and operation teams ? Using automation tools ? Using monitoring tools ?

3. How do you measure software value? Revenue - Cost of development - Cost of operations = Value The iron triangle

4. Google Failures

5. Scientific Method

6. Lean Startup Have a vision for your product, make the business model Build the minimum viable product Test and iterate Pivot when you reach local maximum

7. Fast Feedback Loops build test release monitorplan Delivery Pipeline Feedback LoopDevelopers Customers

8. Fast Feedback Loops build test release monitorplan Delivery Pipeline Feedback LoopDevelopers Customers DevOps is cultural, organizational, technological changes that speed up this lifecycle

9. What is wrong with Waterfall model? There exists a reasonably well-defined set of requirements if we only take the time to understand them. During the development process, changes to requirements will be small enough that we can manage them without substantially rethinking or revising our plans. System integration is an appropriate and necessary process, and we can reasonably predict how it will go based upon architecture and planning. Software innovation and the research and development that is required to create a significant new software application can be done on a predictable schedule. Assumptions

10. What is wrong with Waterfall model? The software systems that we craft are unlike the mechanical and physical devices of the past. Software is intangible. The “Yes, But” syndrome. Customer does not know what he/she wants. Changing business behavior. The approach of full requirements definition, followed by a long gap before those requirements are delivered is no longer appropriate. Software integration and deployments take too much time. Happens at very late night or morning and involves multiple people. The Real Life

11. 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. Working software is the primary measure of progress. http://agilemanifesto.org/principles.html

12. Operations Engineering Waterfall Organization Business Requirements Design Coding and Unit Test System Integration Operations and Maintenance

13. Operations Engineering Water - Scrum - Fall Business Requirements System Integration Operations and Maintenance Analysis Testing Development Scrum

14. Continuous Integration Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. Martin Fowler

15. Continuous Integration Maintain a single source repository Automate the build Make your build self-testing Every commit should build on an integration machine Keep the build fast Test in a clone of the production environment Make it easy for anyone to get the latest executable Practices https://www.thoughtworks.com/continuous-integration

16. Continuous Integration Developers check out code into their private workspaces. When done, commit the changes to the repository. The CI server monitors the repository and checks out changes when they occur. The CI server builds the system and runs unit and integration tests. The CI server releases deployable artefacts for testing. The CI server assigns a build label to the version of the code it just built. The CI server informs the team of the successful build. How to do it https://www.thoughtworks.com/continuous-integration

17. Continuous Integration Check in frequently Don’t check in broken code Don’t check in untested code Don’t check in when the build is broken Don’t go home after checking in until the system builds Team Responsibility https://www.thoughtworks.com/continuous-integration

18. Continuous Delivery Low-risk releases Faster time to market Higher quality Lower costs Better products Happier teams Why ? https://continuousdelivery.com/

19. Continuous Delivery Build quality in Work in small batches Computers perform repetitive tasks, people solve problems Relentlessly pursue continuous improvement Everyone is responsible Principles https://continuousdelivery.com/

20. Continuous Delivery / Configuration Management Reproducibility Traceability Goals https://continuousdelivery.com/ Benefits Disaster Recovery Auditability Higher Quality Capacity Management Response to Defects

21. Hotfix Process Load Balancer us-west-2b Redis DynamoDB Web version 1 Web version 1 Engine version 1 Engine version 1 us-west-2c Web version 1 Web version 1 Engine version 1 Engine version 1

22. Hotfix Process Load Balancer us-west-2b Redis DynamoDB Web version 1 Web version 2 Engine version 2 Engine version 1 us-west-2c Web version 2 Web version 1 Engine version 1 Engine version 2

23. Hotfix Process Load Balancer us-west-2b Redis DynamoDB Web version 2 Web version 2 Engine version 2 Engine version 2 us-west-2c Web version 2 Web version 2 Engine version 2 Engine version 2

24. Monitoring System Monitoring Application Performance Monitoring Web Monitoring Mobile Monitoring Error Detection Log Detection

25. Monitoring

26. Monitoring

27. Monitoring

28. Alert / Incident Management On-call management Escalations MTTA / MTTR Alert Fatigue

29. Culture Transparency Responsibility

30. What is Next ? Web Server Rest Api Server Email Server Engine Sender

31. What is Next ? Web Server Rest Api Server Email Server Engine Sender Account Pricing Alerting Scheduling Integration Heartbeat Reporting Call Routing Notification Mass Notification

32. What is Next: Microservices Nanoservices (Serverless) Hybrid

33. Resources The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (Gene Kim, Kevin Behr, George Spafford) Release It!: Design and Deploy Production-Ready Software (Michael T. Nygard) Continuous Integration (Paul Duvall, Steve Matyas, Andrew Glover) Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Jez Humble, David Farley) Infrastructure as Code: Managing Servers in the Cloud (Kief Morris) The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Gene Kim, Jez Humble, John Willis, Patrick Debois) Building Microservices (Sam Newman) The Lean Startup (Eric Ries)

34. How do you measure software value? Quality Product and Happy Customers

35. How do you measure software value? People

36. Thank you :) Sezgin Küçükkaraaslan sezgin@opsgenie.com @Olric https://www.opsgenie.com

Add a comment