The Road to DevOps V3
4 likes337 views
The document provides an overview of DevOps including its definition, history, components, and adoption process. DevOps is defined as a practice that emphasizes collaboration between development and operations teams. It aims to automate and monitor the software delivery process. The document outlines the people, processes, and technologies involved in DevOps. It also presents sample DevOps pipelines for different technology stacks and discusses adopting DevOps in an organization.
The Road to DevOps V3
- 1. The Road to DevOps Ahmed Misbah 2017
- 2. Agenda • Introduction – What is DevOps? – History of DevOps – What DevOps is not – Why DevOps? • DevOps Components • Adopting DevOps • Sample DevOps Pipeline
- 3. INTRODUCTION
- 4. What is DevOps? DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both Software Developers and other Information-Technology professionals while automating the process of software delivery and infrastructure changes.
- 5. What is DevOps? (cont’d) DevOps in an extension of the agile mindset and methodologies that is focused on brining customers value without compromising creativity (development) and stability (operations) “DevOps Fundementals Workshop” V. 1.0 - SECC
- 6. What is DevOps? (cont’d) DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. https://theagileadmin.com/what-is-devops/
- 7. What is DevOps? (cont’d) DevOps (a clipped compound of "development" and "operations") is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives. https://en.wikipedia.org/wiki/DevOps
- 8. History of DevOps • 2007: Frustration of Patrick Debois. • 2008: Agile Conference in Toronto. Andrew Sheppard proposed Ad Hoc session called “Agile Infrastructure”. No one attends. Session cancelled. Patrick and Andrew meet 1-1. • 2009: #DevOpsDays on October 30 and 31. • And the story continues……
- 9. What DevOps is not • DevOps is not simply combining Development and Operations in one team • DevOps is not (just) a function or title • DevOps is not a separate team • DevOps is not just tools • DevOps is not a one-size-fits-all solution • DevOps is not just automation
- 10. Why DevOps? From State of DevOps Report 2017 - Puppet.com
- 11. Why DevOps? (cont’d) From State of DevOps Report 2017 - Puppet.com
- 13. From State of DevOps Report 2016 - Puppet.com
- 14. Why DevOps? (cont’d) From State of DevOps Report 2016 - Puppet.com
- 16. DevOps Components • People: – Mindset – Roles and Responsibilities • Process: – Methodology – DevOps Pipeline – Practices (5 Cs, Release Management, IaC, etc.) • Technology and Tools: DevOps Toolchain
- 17. People – Mindset
- 18. People – Mindset (cont’d)
- 19. People – Mindset(cont’d) - CALMS Model
- 20. People – Roles and Responsibilities • Release Engineer • Infrastructure / Cloud People • System Administrators
- 21. People – Roles and Responsibilities
- 22. Process - Methodology • SCRUM • Kanban • Scrumban • Extreme Programming (XP) • Lean Software Development • Crystal Clear Methods • Feature-driven Development • Agile Unified Process/Methods (AUP) • Custom Hybrids
- 24. Process – Pipeline (cont’d)
- 26. Process – Practices (cont’d)
- 27. Process – Practices - Automation “Automated Software Engineering applies computation to software engineering activities. The goal is to partially or fully automate these activities, thereby significantly increasing both quality and productivity.” https://www.ercim.eu/publication/Ercim_News/ enw58/intro.html
- 28. Process – Practices - Automation Examples: • Build (Ant, Maven, Gradle, Sbt, Grunt, Gulp) • Unit tests (JUnit) • Code Inspection (SonarQube) • Packaging (JAR, Docker) • Deployment (Jenkins, Ansible, IBM Urban Code) • System/Functional tests (Cucumber, JBehave, Robot Framework, Selenium, Appium) • Provisioning (Ansible, Puppet, Chef) • Documentation (Swagger)
- 29. Process – Practices – 5 Cs
- 30. Process – Practices – Continuous Delivery and Deployment
- 31. Process – Practices – Continuous Testing
- 32. Process – Practices – Continuous Testing Web Security Testing Performance Testing
- 33. Process – Practices – Continuous Integration
- 34. Process – Practices – Continuous Monitoring
- 35. Process – Practices – Release Management
- 36. Process – Practices – Infrastructure as a Code • Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools • There are generally three approaches to IaC: declarative (functional) vs. imperative (procedural) vs. intelligent (environment aware).
- 37. Process – Practices – Infrastructure as a Code • There are two methods of IaC: 'Push' and 'Pull' . The main difference is the manner in which the servers are told how to be configured. In the Pull method the server to be configured will pull its configuration from the controlling server. In the Push method the controlling server pushes the configuration to the destination system.
- 38. Process – Practices – Infrastructure as a Code Tool Released by Method Approach Written in Ansible Tower Ansible (RedHat) Push Declarative and imperative Python CFEngine CFEngine Pull Declarative - Chef Chef Pull Imperative Ruby Otter Inedo Push Declarative and imperative - Puppet Puppet Pull Declarative Ruby SaltStack SaltStack Push and Pull Declarative and imperative Python
- 39. Process – Practices – Containerization
- 40. Process – Practices – Containerization
- 41. Process – Practices – Containerization
- 42. Tech. and Tools– DevOps Toolchain
- 43. Tech. and Tools – DevOps Toolchain
- 44. Tech. and Tools – DevOps Toolchain
- 45. ADOPTING DEVOPS
- 46. Adopting DevOps 1. Prepare/Present case to Management: – Problems – Solution – Risks – Plan – Cost – ROI 2. Setup Team 3. Architect Process and Pipeline
- 47. Adopting DevOps (cont’d) 4. Develop POC 5. Assess and Refine 6. Spread the word
- 49. Adopting DevOps (cont’d) • Mean Time To Production: How long does it take for any newly committed source code to reach production? • Deployment Frequency: How often are releases deployed into production? • Average Lead Time: How long does it take for a new feature to be developed, built, tested, and deployed into production? • Deployment Speed: How much time does it take to deploy a new release into production? • Production Failure Rate: How often do failures occur in production? • Mean Time To Recover (MTTR): How long does it take to recover from a failure?
- 51. CI/CD Pipeline for Java Microservices
- 53. Technology Stack • Terraform • Jenkins 2 • Github • SonarQube • Jacoco • Docker • Docker Hub • jUnit • Mockito • MockMVC • H2 • Embedded Cassandra • Embedded Kafka • Flyway • Ansible • Robot Framework • Swagger • JMeter • Kubernetes
- 54. CI/CD Pipeline for Android Application
- 55. Technology Stack • Terraform • Jenkins 2 • Github • SonarQube • Mockito • Robolectric • Espresso • Ansible • Robot Framework • Swagger • Appium • RDT/STF • HockeyApp • Play Store
- 56. CI/CD Pipeline for Javascript Application
- 57. Technology Stack • Terraform • Jenkins 2 • Github • NPM/Grunt/Gulp • ESLint/SonarQube • Chai/Mocha • Ansible • Robot Framework • Swagger • Selenium
- 58. Monitoring
- 59. Advanced Topics
- 60. Extended Reading