This document discusses DevOps from several perspectives. It begins by defining DevOps as bridging the gap between development and operations using Agile techniques. It then discusses some key aspects of DevOps including culture, automation, measurement, and sharing. It notes there are different perspectives from specialized IT roles and challenges in coming to a common definition. The document also outlines some DevOps strategies and benefits such as more frequent deployments with shorter lead times and fewer failures.

1. Devops
M MARIS PRABHAKARAN
Agile Coach, Singapore

2. Questions
• Development Team Operational Team

3. Questions
• Development Team Operational Team

4. It works fine for me...

5. Wall of Confusion
“Wall” is caused by a combination of
conflicting motivations, processes, and tooling.

6. What is Devops ?

7. Devops Terminology

8. Devops Terminology
• Bridging the gap between projectsand operations
by using Agile techniques both in
development,project management
and system administration.
Patrick Debois
• Devops is banner for change
• Devops is a culture and Professional movement

10. Devops is CAMS
Culture
• People and process first. If you don’t have culture, all automation attempts will be fruitless.
Automation
• This is one of the places you start once you understand your culture. At this point, the tools can start
to stitch together an automation fabric for Devops. Tools for release management, provisioning,
configuration management, systems integration, monitoring and control, and orchestration become
important pieces in building a Devops fabric.
Measurement
• If you can’t measure, you can’t improve. A successful Devops implementation will measure everything
it can as often as it can… performance metrics, process metrics, and even people metrics.
Sharing
• Sharing is the loopback in the CAMS cycle. Creating a culture where people share ideas and problems
is critical.
John Willis

12. Disciplined DevOps
• Disciplined DevOps is the streamlining of IT
solution development and IT operations
activities, and supporting enterprise-IT
activities, to provide more effective outcomes
to an organization.

13. Closing the gap

14. Devops Model
.

15. Difficult to Come to a Common
Definition
• Specialized IT practitioners. Many IT professionals still tend to specialize – someone will choose to focus on being a programmer, an
operations engineer, an enterprise architect, a database administrator (DBA) and so on. As a result they tend to see the world through
the lens of their speciality. Programmers will focus on the software development aspects of DevOps, operations engineers the
operations aspects of DevOps, enterprise architects on the long-term planning and modelling aspects, and DBAs on the data
management aspects. Few people are looking at the overall “big picture”.
• Agilists are focused on continuous delivery. Right now agile and lean developers are investing a lot of effort to figure out continuous
delivery practices so as to streamline the regular deployment of value into production. Advanced teams are releasing daily if not
several times a day due to adoption of practices such as automated regression testing, continuous integration (CI), and continuous
delivery (CD). As a result most of the DevOps discussion in these communities focuses on these topics, sometimes straying into other
practices such as canary testing, feature toggles, and production monitoring frameworks. Clearly important techniques, but still not
covering the full potential range of DevOps. These practices and more are described later in this article.
• Operations professionals are often frustrated. Many operations groups are overwhelmed already with the rate of updates being
foisted upon them by development teams. This is often exacerbated by the inconsistent use of technologies – the impact of the lack of
enterprise awareness within undisciplined development teams is largely felt by the operations group who needs to support the
plethora of technology platforms used by the full range of development teams. Worse yet, the internal operations processes are often
based on heavy implementations of ITIL orITSM and have yet to be streamlined so that operations engineers are in a better position to
collaborate with development teams.
• Tool vendors have limited offerings. As a result of this the DevOps messaging from tool vendors will focus on just the aspects of
DevOps supported by their tools, narrowing the discussion to what they have on offer. Yes, tools are important, but they are only part
of the DevOps picture. Even if there was a vendor with a full range of tools, and if they actually interoperated smoothly (yes ALM
vendors, we’re referring to you), you would still need to understand how to use those tools effectively. To paraphrase an old saying – A
fool with a DevOps tool is still a fool.
• Service vendors have limited offerings. Similar to the issues surrounding tool vendors, service vendors are also making great claims
about their deep expertise in DevOps. Upon examination you will often find, like the tool vendors, their definition of DevOps will focus
on whatever they can currently support.
• Tool vendors treat DevOps as a marketing buzzword. To be blunt, many vendors have taken their existing products, and started
marketing them as DevOps products (regardless of how well those products actually support DevOps practices). Granted, these
products may have been very good at supporting traditional ways of working, but when it comes to supporting DevOps they prove to be
rather clunky even though they may have added a few new features.
• The DevOps=Cloud vision. There is a lot of rhetoric, particularly coming from Cloud vendors, about how cloud-based tooling and
deployment environments are critical to success in DevOps. Yes, having a cloud-based infrastructure clearly enables many DevOps
practices and given the choice we prefer to work in an environment which leverages cloud-based technologies whenever
appropriate. But, that doesn’t mean that the cloud is a prerequisite for doing DevOps.

16. Devops Strategies
• General Strategies(Collaborative work, Training, education, and mentoring, Continuous improvement)
• Teaming Strategies (Warranty period,Production support)
• Development Strategies (Canary tests, Split test)
• Operations Strategies
• Support (Help Desk) Strategies
• Release Management Strategies
• Data Management Strategies
• Enterprise Architecture Strategies
• https://disciplinedagiledelivery.wordpress.com/2015/02/08/devop
s-strategies-development/

17. Dev ops benefits
.
High-performing IT organizations deploy 30x more frequently with 200x shorter lead
times; they have 60x fewer failures and recover 168x faster

18. • Thank you
marisagility@gmail.com
https://www.linkedin.com/in/marisprabhu
#marisagility