What is DevOps?

DevOps connects development, quality assurance, and technical

operations personnel in a way that the entire build-test-release-runrepeat process operates as a factory, having clear roles and
responsibilities and well-defined inputs and outputs. It is a concept that
connects developers, quality assurance and technical operations people.
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.
The term DevOps typically refers to the emerging professional
movement that advocates Collaborative working relationship between
Development and IT Operations, resulting in the fast flow of planned work
(i.e., high deploy rates), while simultaneously increasing the reliability,
stability, resilience and security of the production environment.
DevOps doesnt differentiate between different sysadmin sub-disciplines
Ops is a blanket term for systems engineers, system administrators,
operations staff, release engineers, DBAs, network engineers, security
professionals, and various other sub disciplines and job titles. Dev is
used as shorthand for developers in particular, but really in practice it is
even wider and means all the people involved in developing the
product, which can include Product, QA, and other kinds of disciplines.

How does DevOps differ from Agile?

One tenet of the agile development process is to deliver working software

in smaller and more frequent increments, as opposed to the big bang

approach of the waterfall method. This is most evident in the agile goal of
having potentially shippable features at the end of each sprint (typically
every two weeks).
High deployment rates will often pile up in front of IT Operations for
deployment. DevOps is a way for the business to regain trust in the entire
IT organization as a whole.
DevOps is especially complementary to the agile software development
process, as it extends and completes the continuous integration and
release process by ensuring the code is production ready and providing
value to the customer.
DevOps enables a far more continuous flow of work into IT Operations.
When code is not promoted into production as it is developed (e.g.,
Development delivers code every two weeks, but is deployed only every
two months), deployments will pile up in front of IT Operations, customers
dont get value, and the deployments often result in chaos and disruption.
Agile and continuous integration and release are the outputs of
Development, which are the inputs into IT Operations. In order to
accommodate the faster release cadence associated with DevOps, many
areas of the ITIL processes require automation, specifically around the
change, configuration and release processes.
The goal of DevOps is not just to increase the rate of change, but to
successfully deploy features into production without causing chaos and
disrupting other services, while quickly detecting and correcting incidents
when they occur. This brings in the ITIL disciplines of service design,
incident and problem management

What are the unpinning principles of DevOps?

The First Way emphasizes the performance of the entire system, as
opposed to the performance of a specific silo of work or department
this as can be as large a division (e.g., Development or IT Operations) or
as small as an individual contributor (e.g., a developer, system
administrator).
The focus is on all business value streams that are enabled by IT. In other
words, it begins when requirements are identified (e.g., by the business or
IT), are built in Development, and then transitioned into IT Operations,
where the value is then delivered to the customer as a form of a service.
The Second Way is about creating the right to left feedback loops. The
goal of almost any process improvement initiative is to shorten and
amplify feedback loops so necessary corrections can be continually made.

The outcomes of the Second Way include understanding and responding

to all customers, internal and external, shortening and amplifying all
feedback loops, and embedding knowledge where we need it.
The Third Way is about creating a culture that fosters at two things:
continual experimentation, which requires taking risks and learning from
success and failure; and understanding that repetition and practice is the
prerequisite to mastery.
We need both of these equally. Experimentation and risk taking are what
ensure that we keep pushing to improve, even if it means going deeper
into the danger zone than weve ever gone.
And we need mastery of the skills that can help us retreat out of the
danger zone when weve gone too far.
The outcomes of the Third Way include allocating time for the
improvement of daily work, creating rituals that reward the team for
taking risks, and introducing faults into the system to increase resilience.

DevOps has 4 main value propositions

Increased Agility
Speed to market or better maximised agility through a constant and fully
integrated deployment capability is one key aspect here. Moving from a
release cycle from every quarter to deploying changes on a minute by
minute basis is real aspiration. For many clients this is a massive leap, for
some this is reality.
Increased Quality
High-performing organizations are still deploying code 30 times more
frequently, with 50 percent fewer failures than their lower-performing
counterparts. Increased quality is one on the key benefits DevOps. It will
however only increase quality if the organisation reached a certain level of
maturity.

Improve Innovation
Running less outages, deploying code with increased quality will lead to
more time spend thinking about further improvements or new ways of
working. It will enable the organisation to drive more value, rather than
having to dedicate time fixing issues caused by changes deployed
Reduced Outages
Reports mention that "80% of unplanned outages are due to ill-planned
changes made by administrators ("operations staff") or developers." And
60% of availability and performance errors are the result of
misconfigurations.

DevOps QA Is About Preventing Defects, Not

Finding Them
QA takes a critical role in this organizational structure because they have
the visibility and the directive to push code out when it is working, and roll
it back when it is not. This is a very different mind-set from QA
organizations of 10 years ago, whose primary responsibilities involved
finding bugs. Today QA groups are charged with preventing defects from
reaching the public site.
This has several implications:

QA owns continuous improvement and quality tracking across the

entire development cycle. They are the ones who are primarily responsible
for identifying problems not just in the product but also in the process,
and recommending changes wherever they can.
Tests are code, as any test automation expert will tell you. Its a
necessity, of course. If your process is designed to publish a new release
every day (or every hour) there is no room for manual testing. You must
develop automation systems, through code, that can ensure quality
standards are maintained.
Automation rules. Anything that can be automated should be
automated. When Carl describes Unbounces deployment process as
push-button easy, this is what hes talking about.
Testers are the quality advocates, influencing both development and
operational processes. They dont just find bugs. They look for any
opportunity to improve repeatability and predictability.
High deployment rates typically associated with DevOps work
streams will often put enormous pressure on QA and Infosec. Consider the
case where Development is doing ten deploys per day, while information
security requires a four month lead time to turn around for application
security reviews. At first glance, there appears to be a fundamental
mismatch between the rate of code development and security code
testing.

The good news for QA and Infosec is that Development

organizations capable of sustaining high deploy rates are likely using
continual integration and release practices, which often goes hand in hand
with a culture of requiring continuous testing. In other words, whenever
code is checked in, automated tests are automatically run, and issues
must be fixed right away, just as if a developer checked in code that didnt
compile. By integrating functional, integration and information security
testing into the daily operations of Development, defects are found and
fixed more quickly than ever.

DevOps implementation
Figure below shows the different aspects involved with transforming an
organization to a DevOps way of working, grouped according to 3 principal axis:
Mindset, methodology and tooling. Note that, while Devops may be perceived as
just a new set of tools and automation to implement, experience shows that a
DevOps implementation is actually 75% organizational and processes
transformation and only 25% tooling and technology implementation. So any
DevOps implementation that neglects the organizatorical, and people
components is not likely to realize all the expected benefits.

Where to start?
DevOps transformations can start from different parts within the organization1 .
Each approach has advantages, disadvantages and risks:
Start from the Operations teams

This requires is a relatively easy place to start, with gradual transition path
where resources migrate from a central operations organization into DevOps
teams, while maintaining an Operations core organization that maintains the
shared resources, like the PaaS platform. However, it requires that the operations
teams have the skills and time to start automating and scripting their processes.
Set up a skunk-works team
Before rolling out DevOps to the entire organization, handpick resources from
different teams (or recruit externally) to form a DevOps skunkworks project. This
team must have the freedom to work out their own DevOps methodology.
Start from Development
Allow Development teams to work in a DevOps fashion in Dev and Test, and
allow them to engage their own Ops members. Initially they hand-over their
deliverables to DevOps experts with the operations teams.
Greenfield implementation
This is the rare situation, most likely to occur within startup organizations. These
can start a completely new team using DevOps methodologies from the start to
develop new applications. In this case there is no real transition to implement.
Force DevOps on the complete organization
This is the highest risk transformation, whereby teams are just put together and
told to work in a DevOps manner. The risk is that many of the existing resources
will just not be able to work in a DevOps manner, and leave the company,
creating gaps in the organization, knowledge, and impacting the existing projects
and SLAs. This method is only advised if there are a sufficient number of DevOps
able resources, or the organization believes they can re-staff fast enough to
make up for the resources lost through attrition.