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. 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.

11. Thank You 