Understanding DevOps

June 3, 2019 Posted by Programming 0 thoughts on “Understanding DevOps”

What is DevOps?

Linguistically, DevOps is a mashup of two departments: development and operations. Functionally, DevOps is an outlined set of procedures, philosophies, and tools  that aim to bring those two departments together to facilitate faster feedback loops. Faster feedback loops between development and operations means that products can be built, tested, and pushed to the public more reliably. The problem many have when they hear the word DevOps is that they think it’s a special ops team akin to the military. Implementing DevOps into a company isn’t a magic bullet since it requires both your developers and, say, IT guys/gals, to adopt certain philosophies that encourage co-operation.

It could be that a company is so well structured that they’re practicing DevOps without formally calling their system DevOps. That’s because the whole concept of DevOps is really a mashup of  agile, lean principles, continuous delivery, automation, and a product-focused mindset.

If you really break down these principles, you’ll understand exactly what “DevOps” values. Oftentimes, in studying development principles you’ll notice an overlapping of buzzwords. Agile is essentially a superset of lean, continuous delivery, and automation. Let’s look at the 12 principles of Agile as stated in the manifesto and examine how closely DevOps adheres to these principles. We’ll even translate some of the principles into “DevOps speak.” In this way, you can really see what DevOps stands for and why it’s not so radically different from all the other methods out there.

Agile and DevOps

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software/ DevOps: Dev and ops teams that work together facilitate this with tightly coupled feedback loops.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project. / DevOps: This is exactly what DevOps proposes, except it adds the Ops people into the mix.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done./ DevOps: Again, DevOps uses this Agile principle to propose the meshing of devs and ops.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation./ DevOps: Dev teams and ops teams shouldn’t be bunkered behind their respective cubicles.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams/ DevOps: This is the crux of DevOps, that collaboration should become a natural phenomenon where product managers, QA teams, design teams, operations, and developers work together on a single product. This creates a product-focused mindset, rather than a functional, dull, assembly-line-like procedure of shifting the burden of responsibility from team to team
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Leaning into automation

As you can see DevOps is congruent with many, if not all, agile principles. Lean principles mostly echo many of the principles outlined above. What I’ll add are some lean principles that address the advantage of DevOps: Built-in quality, knowledge creation, and respect. In terms of quality assurance, a DevOps team optimizes for this with a product-focused mindset that onboards QA. What furthers collaboration, however, is taking on the challenge of quality assurance if you’re a non QA. The principle of built-in quality assures the highest spirit of collaboration since it does not put the burden of one task on a single member.

Shared responsibility requires both knowledge creation and respect. Documentation, code reviews, and training will allow teams to stay on the same page. Proper knowledge creation requires a level of respect for your peers. They cannot be seen as the “Other Team.” That’s the mentality that DevOps seeks to cure by employing lean and agile principles.

These heady principles get funneled into automation. The idea is that teams will be more apt to work together if they can rely on computers to automate the “grunt work.” Another way of viewing this is that working together encourages automation. The buzzword that often comes out of this is continuous delivery(an Agile principle). From a DevOps point of view, continuous delivery is the product of a well-implemented DevOps culture. In a blog post, Martin Fowler described the acid test of continuous delivery.

The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment’s notice – and nobody would bat an eyelid, let alone panic.

Then he mentioned what you’d need to achieve continuous delivery: “a close, collaborative working relationship between everyone involved in delivery (often referred to as a DevOpsCulture ). ”


DevOps was born in 2009, when Patrick Debois, a project manager and agile practitioner, created a Devopsdays conference in Ghent, Belgium. “DevOps” entered our lexicon and the rest was history, as the saying goes.  DevOps as an idea, of course, wasn’t created overnight. Whatever ideas have been added over the years have served to solve a single solution: bridging the gap between development and operations.



Please follow and like us: