DevOps is a movement that envisions no friction between the development groups and the operations groups.

Why should you care about DevOps?

If you are involved in building software systems and your organization is interested in reducing the time to market for new features, then you should care. DevOps practices will influence the way that you organize teams, build systems, and even the structure of the systems that you build. If you are a software engineering student or researcher then you should care how the adoption of DevOps practices could influence the problems that you choose to work on.


DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

Let’s look at some of the implications of our definition:


The quality of the deployed change to a system is important.
Quality means suitability for use by various stakeholders including end users, developers, or system administrators. It also includes availability, security, reliability, and other “ilities.”

Methods for ensuring quality:
  • A variety of automated test cases that must be passed prior to placing changed code into production.
  • Test the change in production with a limited set of users prior to opening it up to the world.
  • Closely monitor newly deployed code for a period of time.

High quality Delivery mechanism:

Reliability and the repeatability of the delivery mechanism should be high. If the delivery mechanism fails regularly, the time required increases. If there are errors in how the change is delivered, the quality of the deployed system suffers.

Five different categories of DevOps practices:

Treat Ops as first-class citizens from the point of view of requirements. These practices fit in the high-quality aspect of the definition. Involving operations in the development of requirements will ensure that these types of requirements are considered.

Make Dev more responsible for relevant incident handling. These practices are intended to shorten the time between the observation of an error and the repair of that error.

Enforce the deployment process used by all, including Dev and Ops personnel. These practices are intended to ensure a higher quality of deployments. This avoids errors caused by ad hoc deployments and the resulting misconfiguration.

Use continuous deployment. Continuous deployment are intended to shorten the time between a developer committing code to a repository and the code being deployed. Continuous deployment also emphasizes automated tests to increase the quality of code making its way into production.

Develop infrastructure code, such as deployment scripts, with the same set of practices as application code. Practices that apply to the development of infrastructure code are intended to ensure both high quality in the deployed applications and that deployments proceed as planned. Errors in deployment scripts such as misconfigurations can cause errors in the application, the environment, or the deployment process.

Example of Continuous Deployment:

IMVU, Inc. is a social entertainment company whose product allows users to connect through 3D avatar-based experiences. IMVU does continuous integration. The developers commit early and often. A commit triggers an execution of a test suite. IMVU has a thousand test files, distributed across 30–40 machines, and the test suite takes about nine minutes to run. Once a commit has passed all of its tests, it is automatically sent to deployment. This takes about six minutes. The code is moved to the hundreds of machines in the cluster, but at first the code is only made live on a small number of machines (canaries). A sampling program examines the results of the canaries and if there has been a statistically significant regression, then the revision is automatically rolled back. Otherwise the remainder of the cluster is made active. IMVU deploys new code 50 times a day, on average.

*In next blogs one by one we will take some of the popular devops tools like docker, jenkins etc and will discuss how to use them. We will also discuss on some other concept of devops.


DevOps: A Software Architect’s Perspective