SlideShare a Scribd company logo

Introducing DevOps

•Download as PPTX, PDF•
•
Moataz Nabil
Moataz Nabil

DevOps is an approach that aims to break down barriers between development and operations teams. It promotes practices like automating processes, using consistent tooling across teams, and integrating operational skills into development work. DevOps works best for web applications hosted in cloud environments, especially when teams already practice agile development. It can be challenging for applications with dependencies, shared environments, multiple platforms, or in regulated industries. Whether an organization adopts DevOps should depend on how well they currently deliver quality releases in a timely manner.

1 of 11
Moataz Nabil Quality Lead | Automation Test Engineer | ALM Specialist MCSD-ALM , ISTQB Moataznabil.com Introducing DevOps
Introduction  What is DevOps? Well to understand DevOps you have to go back to the originations of Agile Development - where developers dissatisfied with the imposition of heavyweight processes, generation of unnecessary artefacts (typically documentation) and the unpredictable nature of software development - scribed the Agile manifesto and kick started an alternate and fundamentally more business focused view of developing and delivering applications.  Although, Agile development practices have unquestionably proved successful across a large and growing number of projects, the true value of the Agile (and in particular the practice of Continuous Integration and Delivery) has often been negated at the final push by traditional operational requirements. As an example, the diagram below highlights the current challenges that Agile teams typically face in moving applications into Production over a "virtual wall".
whilst Development (in order to meet changing Business needs) have been trying to put releases into Production more frequently by delivering incremental changes, Operations (particularly in large organizations) have been trying to reduce risk by slowing down the rate of change and formalizing the gates and handovers that they have to go through. This dichotomy, has led to some individuals and Organizations trying to break down this "virtual wall" of gateways and reviews by integrating Development and Operational skills and practices. An idealized view of DevOps is illustrated in the diagram below.
DevOps practices DevOps is not a technology, an application, or a defined method like Agile Scrum or XP. Currently, you cannot easily "do" DevOps by reading a book or by taking a course and becoming a certified DevopsMaster (like ScrumMaster). There are however some commonly agreed practices that will "influence" DevOps behavior and these are listed in the next silde
 Cross functional teams Whereas Agile has been espousing the benefits of integrating Development and QA roles into a single team, DevOps takes this further by integrating Operational roles.  Cross functional skills Again similar to Agile which encourages individuals to have a mix of skills, Devops encourages cross fertilization of the "operational" skills that are typically possessed by Operations staff (examples include skills in application security, monitoring and maintenance - all of the things that Operations do to keep applications healthy and running).  Develop for Production Early creation of operational artifacts as part of the development process (for example, deployment and update scripts, automated database migration scripts, monitoring and reporting scripts) and increased focus on delivering non-functional requirements early. List of DevOps practices
Automate for Release Automation of as much as possible including build and release, provisioning of servers, deployment and automated integration and acceptance testing. Consistent tooling Use of the same toolsets by Development and Operations, for example a single repository to store all Development source and Operational scripts (which get delivered together), and integration of any tools that support Development and Operational changes, for example, Service Management, Help Desk, Change Management, Issue and Defect Tracking. Deployment Pipeline Construction of an automated pipeline that model the full Deployment lifecycle, i.e. Development -> UAT -> Production and empowerment of users to be able to self- service deploy into their environment (potentially including server provisioning, application installation and test data installation). Pushed Phased Releases For rolling out releases across a large consumer environment (potentially consisting of thousands of servers), the contents of releases are typically push to a small number of servers (maybe internal facing), before being pushed to large and larger set (for example, regional servers, country then worldwide). This allows the release to be phased and any problems addressed before the whole of a community is affected Cont. DevOps practices
Benefits of DevOps  Decreased risk Since DevOps brings an earlier focus on to the operational aspects of an application, there will be less issues when an application is delivered into Production.  Decreased time to delivery By incorporating operational requirements early there will be no (or less) need for stage gates and readiness reviews as applications move from Development into UAT and Production. Since the main premise of DevOps is one of Continuous Delivery, the average time to delivery will be shorter than a traditional approach anyway (maybe daily but usually weekly). To be able to compare these different approaches would require capturing the number of "working features" delivered into Production over a defined period of time. With a DevOps approach this should be significantly more than if the same features had been developed in a "big bang" approach and moved into Production.  Increased visibility Since operational staff are now effectively involved in the Development process, they will have much better visibility of upcoming changes and the infrastructure requirements. They will therefore be able to respond better to business needs, by scaling purchasing of configuring infrastructure to meet demand.
Where DevOps works well  There are a number of areas where DevOps has already been adopted and working well, this includes:  Web based applications The architecture of web applications (with well defined Deployment Pipelines and ability to deliver incremental changes) is well suited to DevOps and indeed most of the supposed implementations of DevOps have been so. Note: it is difficult to currently ascertain which companies have been using DevOps practices.  Cloud or virtual infrastructure DevOps applications (predominantly web based as above) need a large amount of infrastructure and typically require environments to be provisioned and configured on demand; provisioning physical servers to support the testing and delivery of application enhancements can take significant amounts of time and significantly slow down releases. DevOps therefore work best when the infrastructure is Cloud based or Virtual. Also it is best if changes to the infrastructure can be made on-demand even when the application is live.  Agile adoption Since DevOps is closely aligned to some Agile practices, it goes without saying that any organization already executing successful Agile projects will have a good chance of implementing DevOps.  Independent applications DevOps works best when delivering changes for a single independent application (no matter what its size). DevOps can potentially struggle when a organization is delivering multiple, inter-dependent applications (see next section).  Although DevOps practices could potentially be implemented elsewhere, the above summarizes the current "sweet-spot" until DevOps implementation matures.
Where DevOps can be challenging  There are a number of areas where implementing DevOps can potentially be challenging, this includes:  Dependent applications Where multiple applications need to be delivered together and they have explicit dependencies, it is more difficult to implement DevOps. Making DevOps work in such a scenario is not impossible but will require strategic planning and delivery of dependent changes.  Shared environments If an organization is developing applications that share multiple Test and Production environments, DevOps can potentially cause conflicts. The rapid delivery of changes can potentially cause instability if an environment is being used for multiple purposes. Ideally DevOps environments should exclusively own their environments.  Multi-platform applications Similar to dependent applications, If an application is developed and delivered as multiple components across platforms, for example Windows/UNIX AND mainframe it can be difficult to establish Devops practices. In particular there might traditionally be different operational departments and requirements for distributed and mainframe platforms.  Regulated industries If applications are being delivered in highly regulated industries, i.e. Financial Services or Healthcare, there can be specific regulations that prevent DevOps.
Summary Whether an organization adopt DevOps or not should be driven any challenges they have in delivering quality releases into a Production in a timely way. Even with distinct Development and Operations teams, if the Business is happy with the frequency of deliveries and Operations are successfully managing their availability, Development should not try to implement potentially destabilizing DevOps practices just because they want more control over their applications as they move into Production. For specific types of applications though (Web based, monolithic, with large users bases) I am convinced that implementing DevOps practices can potentially yield significant results.
Thank You 

More Related Content

Introducing DevOps

  • 1. Moataz Nabil Quality Lead | Automation Test Engineer | ALM Specialist MCSD-ALM , ISTQB Moataznabil.com Introducing DevOps
  • 2. Introduction  What is DevOps? Well to understand DevOps you have to go back to the originations of Agile Development - where developers dissatisfied with the imposition of heavyweight processes, generation of unnecessary artefacts (typically documentation) and the unpredictable nature of software development - scribed the Agile manifesto and kick started an alternate and fundamentally more business focused view of developing and delivering applications.  Although, Agile development practices have unquestionably proved successful across a large and growing number of projects, the true value of the Agile (and in particular the practice of Continuous Integration and Delivery) has often been negated at the final push by traditional operational requirements. As an example, the diagram below highlights the current challenges that Agile teams typically face in moving applications into Production over a "virtual wall".
  • 3. whilst Development (in order to meet changing Business needs) have been trying to put releases into Production more frequently by delivering incremental changes, Operations (particularly in large organizations) have been trying to reduce risk by slowing down the rate of change and formalizing the gates and handovers that they have to go through. This dichotomy, has led to some individuals and Organizations trying to break down this "virtual wall" of gateways and reviews by integrating Development and Operational skills and practices. An idealized view of DevOps is illustrated in the diagram below.
  • 4. DevOps practices DevOps is not a technology, an application, or a defined method like Agile Scrum or XP. Currently, you cannot easily "do" DevOps by reading a book or by taking a course and becoming a certified DevopsMaster (like ScrumMaster). There are however some commonly agreed practices that will "influence" DevOps behavior and these are listed in the next silde
  • 5.  Cross functional teams Whereas Agile has been espousing the benefits of integrating Development and QA roles into a single team, DevOps takes this further by integrating Operational roles.  Cross functional skills Again similar to Agile which encourages individuals to have a mix of skills, Devops encourages cross fertilization of the "operational" skills that are typically possessed by Operations staff (examples include skills in application security, monitoring and maintenance - all of the things that Operations do to keep applications healthy and running).  Develop for Production Early creation of operational artifacts as part of the development process (for example, deployment and update scripts, automated database migration scripts, monitoring and reporting scripts) and increased focus on delivering non-functional requirements early. List of DevOps practices
  • 6. Automate for Release Automation of as much as possible including build and release, provisioning of servers, deployment and automated integration and acceptance testing. Consistent tooling Use of the same toolsets by Development and Operations, for example a single repository to store all Development source and Operational scripts (which get delivered together), and integration of any tools that support Development and Operational changes, for example, Service Management, Help Desk, Change Management, Issue and Defect Tracking. Deployment Pipeline Construction of an automated pipeline that model the full Deployment lifecycle, i.e. Development -> UAT -> Production and empowerment of users to be able to self- service deploy into their environment (potentially including server provisioning, application installation and test data installation). Pushed Phased Releases For rolling out releases across a large consumer environment (potentially consisting of thousands of servers), the contents of releases are typically push to a small number of servers (maybe internal facing), before being pushed to large and larger set (for example, regional servers, country then worldwide). This allows the release to be phased and any problems addressed before the whole of a community is affected Cont. DevOps practices
  • 7. Benefits of DevOps  Decreased risk Since DevOps brings an earlier focus on to the operational aspects of an application, there will be less issues when an application is delivered into Production.  Decreased time to delivery By incorporating operational requirements early there will be no (or less) need for stage gates and readiness reviews as applications move from Development into UAT and Production. Since the main premise of DevOps is one of Continuous Delivery, the average time to delivery will be shorter than a traditional approach anyway (maybe daily but usually weekly). To be able to compare these different approaches would require capturing the number of "working features" delivered into Production over a defined period of time. With a DevOps approach this should be significantly more than if the same features had been developed in a "big bang" approach and moved into Production.  Increased visibility Since operational staff are now effectively involved in the Development process, they will have much better visibility of upcoming changes and the infrastructure requirements. They will therefore be able to respond better to business needs, by scaling purchasing of configuring infrastructure to meet demand.
  • 8. Where DevOps works well  There are a number of areas where DevOps has already been adopted and working well, this includes:  Web based applications The architecture of web applications (with well defined Deployment Pipelines and ability to deliver incremental changes) is well suited to DevOps and indeed most of the supposed implementations of DevOps have been so. Note: it is difficult to currently ascertain which companies have been using DevOps practices.  Cloud or virtual infrastructure DevOps applications (predominantly web based as above) need a large amount of infrastructure and typically require environments to be provisioned and configured on demand; provisioning physical servers to support the testing and delivery of application enhancements can take significant amounts of time and significantly slow down releases. DevOps therefore work best when the infrastructure is Cloud based or Virtual. Also it is best if changes to the infrastructure can be made on-demand even when the application is live.  Agile adoption Since DevOps is closely aligned to some Agile practices, it goes without saying that any organization already executing successful Agile projects will have a good chance of implementing DevOps.  Independent applications DevOps works best when delivering changes for a single independent application (no matter what its size). DevOps can potentially struggle when a organization is delivering multiple, inter-dependent applications (see next section).  Although DevOps practices could potentially be implemented elsewhere, the above summarizes the current "sweet-spot" until DevOps implementation matures.
  • 9. Where DevOps can be challenging  There are a number of areas where implementing DevOps can potentially be challenging, this includes:  Dependent applications Where multiple applications need to be delivered together and they have explicit dependencies, it is more difficult to implement DevOps. Making DevOps work in such a scenario is not impossible but will require strategic planning and delivery of dependent changes.  Shared environments If an organization is developing applications that share multiple Test and Production environments, DevOps can potentially cause conflicts. The rapid delivery of changes can potentially cause instability if an environment is being used for multiple purposes. Ideally DevOps environments should exclusively own their environments.  Multi-platform applications Similar to dependent applications, If an application is developed and delivered as multiple components across platforms, for example Windows/UNIX AND mainframe it can be difficult to establish Devops practices. In particular there might traditionally be different operational departments and requirements for distributed and mainframe platforms.  Regulated industries If applications are being delivered in highly regulated industries, i.e. Financial Services or Healthcare, there can be specific regulations that prevent DevOps.
  • 10. Summary Whether an organization adopt DevOps or not should be driven any challenges they have in delivering quality releases into a Production in a timely way. Even with distinct Development and Operations teams, if the Business is happy with the frequency of deliveries and Operations are successfully managing their availability, Development should not try to implement potentially destabilizing DevOps practices just because they want more control over their applications as they move into Production. For specific types of applications though (Web based, monolithic, with large users bases) I am convinced that implementing DevOps practices can potentially yield significant results.