The Battle Scenario – Before and After the Advent of
DevOps
Before DevOps came onto the scene, both Development
and Operations worked in an isolated manner. The only
time they crossed-paths were during the release phase. The
development team, already notified about the release date,
intended to interject some new and additional features
before the time of release. Whereas the operational team
knew from beforehand whether the current release version
had any new or additional features interjected. This way,
before deploying the release to the customer’s site, the Ops
team performed rigorous testing to be satisfied with its
stability and operability and only then permitted its
deployment.
The arrival of DevOps and its rise in adoption led to a
paradigm shift from this culture. Developers now no longer
need to wait for a release date to bring-forward new and
enhanced features. Instead, they have the capability to
release new features on a regular basis by using the concept
of Continuous Integration and Delivery. This has prompted
developers to emphasize that the operation team must
manage this regular flow of new features imperatively
before it gets deployed to the customer’s site. But this
approach gave rise to a new problem, as Ops have to deal
with a pipeline of releases at a regular interval due to this.
They now need to be extremely attentive and careful about
the quality testing of the systems as the deployed builds on
the customer site may or may not be entirely free from
bugs.
The Resolution
The most feasible and obvious solution to this opposing
friction is the synchronization between Dev and Ops,
popularly termed as DevOps. Coined by Patrick Debois,
known as “the father of DevOps,” DevOps is an operational
philosophy that helps to bridge the gap between
Development and Operations by emphasizing upon
integration, collaboration, and communication.
August 2017
It is the most salient methodology through which an
organization can check and assure a balance between
development and quality. In order to reach an equilibrium
point in this resolution, both Dev and Ops need to embrace
the DevOps methodologies by modifying their outlook and
their way of working, as follows:
From the Operations Perspective
Ÿ Extensive monitoring of all running environments such
as staging or production, so as to react and prevent any
issues from cropping up and spreading, respectively.
Ÿ Operations need to be much more flexible in their
approach in accepting regular or frequent changes.
Ÿ Operations should facilitate an effective and healthy
collaboration with the Development team.
From the Development Perspective.
Ÿ Sound engagement needs to be performed to assess the
quality metrics that Ops emphasizes on, to track customer
production systems and quality.
Ÿ Dev need to be more involved with the testing of their
own code in the production phase instead of leaving out
from the field after writing the system or application
code.
Ÿ Developers should facilitate an effective and healthy
collaboration with the Operations team.
Hence, it can be safely exclaimed that both Dev and Ops
team need to change substantially in their functioning and
outlook to successfully adopt the DevOps methodology.
Adapting to DevOps culture is by no means a silver bullet,
as it brings with itself a considerable amount of changes.
But upon successful communication between developers
and operators, an organization will be able to reap
significant advantages through the same. The battle between
Dev and Ops may continue for years, but DevOps has the
distinct capability to bridge the gap between the two.
21