Demystifying Dev Ops – Part 1


I’m sure we’ve all been there…anyone with a few projects under their belt has seen the effect of deployment or build issues hinder or halt progress of a project.

Sometimes the results are obvious. When unstable code is checked in, a fix can be as simple as filing a defect and backing out a premature check-in. Some of the more dubious issues can linger, creating an almost religious habit of server restarts, cache clearing, and log purges before the project team realizes the root cause is more complex than a simple data clean up or restart effort. While other issues can outright halt any progress, production misbehaves and the entire situation becomes an “all hands on deck” effort. Scores of scenarios can be tried and tested, all with no success. Deployment artifacts, logs, and configuration files can be examined with a fine-toothed comb only to realize a simple line was updated in a pre-production environment that somehow never made it to production.

While we’ve all likely been here, and we generally never make the exact mistake twice, it isn’t uncommon to run into a similar issue with a different root cause, most of which can be remedied with some investment into “DevOps.”  In the first article of a multi-part series we’ll explore DevOps, the various maturity levels project teams can achieve, and the importance of employing DevOps within an organization. Let’s begin by visiting / revisiting some ideas and definitions.


Defining DevOps in itself can be a challenge, as most industry professionals do not consider it as an approach or a method. Many would likely consider it a “way” in the classic sense of Taoism for the software engineering ecosystem – a collection of code and behaviors across the development and operations lifecycle. A more common connotation could be phrased as a set of indoctrinated practices, procedures, and tools dedicated to repeatable and reliable high quality automated code delivery. While perhaps not a method or an approach, by most viewpoints, it has become an organizational philosophy that demonstrates an evolution from the once highly complex and error prone way of doing code packaging and release management described above.

Accepting these notions, other questions do tend to arise as to whether DevOps is considered “Continuous Integration,” “Continuous Delivery,” or “Automated Deployment,” a.k.a. CI/CD/AD. While sometimes used synonymously together, a number of practitioners have described DevOps as the key to the “machine” that makes CI/CD/AD happen – the secret invention that drives the conveyer belt in the software factory of code packaging, environment provisioning, and ongoing deployment. So one possible summary to these ideas is that DevOps takes on the philosophy of evolved release management, with CI/CD/AD being the end result.

So what does CI/CD/AD really mean?

CI/CD/AD takes on a fairly specific set of industry definitions across the spectrum of software development to product deployment, and are roughly defined as follows:

  • Continuous Integration (CI) refers to integrating, building, and testing software code within the development environment, with a key focus of lifting code quality and automating as many developmental and quality instruction sets as possible before the code is deployed to downstream environments.
  • Continuous Delivery (CD) refers to the capability to do automated and high quality code deployment at a high frequency and with increased levels of velocity.
  • Automated Deployment (AD or AD/CD) is automated or continuous production deployment, and requires both CI and CD to realize.

AD aligns and supports a pipeline of automated code packaging, environment provisioning and configuration, code promotion, and automated testing from development all the way to the production environment. The realization of AD allows an organization’s software factory to do high frequency software releases to one or many production environments in a single day. The achievement of AD removes a number of once compartmentalized steps to craft and move code from development into production operations; hence realizing the software factory outcome of DevOps. See the picture below for a graphical representation of how CI/CD/AD evolves in concert with team efforts.

For those reading this article that are interested in DevOps maturity and related tool suites, the following table outlines the various states a project team can achieve, and the following paragraph highlights the present popular industry tool suites organizations are employing.

Continuous Delivery (CI/CD) Maturity Model:

Adapted from Forrester’s “Continuous Delivery: A Maturity Assessment Model” (March, 2013)

Common Tools:

Vagrant, TeamCity, and Jenkins are some of the tools commonly used to achieve CI today. Additionally, applications like Serena™, and Nolio are widely used for release automation. When paired with tools like Chef™ and Puppet for infrastructure and environment provisioning, a common platform is created to achieve CD. Practitioners also are also leveraging container applications like Docker® to adopt automated deployment (AD) to the cloud.

So why employ DevOps? The short answer is simple – because companies have to. The market and customers are demanding it.

Today’s operational clock-speed to get high quality software products to market is set on a global stage and at a frenetic pace. Organizations not employing DevOps face steep competition from companies who have mastered the practices, tools, and the “way” of DevOps as part of their culture.

Once adopted, DevOps practices can streamline the most challenging aspects of software development and deployment by optimizing infrastructure setup, simplifying environment provisioning and configuration, and automating test coverage to improve quality. But aside from the need to move towards a DevOps culture, most organizations drive out wonderful benefits from employing even basic practices such as:

  • Improved Innovation Cycles – Engineering teams spend more time on actual development and less time on troubleshooting builds, packaging and deploying code from various repository branches, and manually provisioning and configuring various environments.
  • Increased ROI on Automation – More time across resources can be allocated to automation across the development lifecycle, which increases team velocity, promotes deeper and broader quality coverage, and can highly reduce technical debt.
  • Automated Deploys – New functionality is delivered frequently to leverage “Just in Time” testing and delivery.
  • Increased Confidence in Deployments – Less investigation on deployment issues (function or quality). Every deployment becomes a test to the process. Undocumented configuration changes don’t get promoted. Development teams can know early if new code impacted a code build.
  • Report of Automation Failures – Integrated directly into CI servers, plugins offer error reporting and coverage feedback to help continually tune the DevOps process.


The depth and breadth of a DevOps program that fully automates an end-to-end SDLC into production can be a prodigious effort. And while the notion of DevOps is considered to be critical to a company’s software product success, it is important to maintain a perspective on the idea of what is the “right sized” application of DevOps to fit an organization’s needs.

For companies just beginning the journey look for our next installment – DevOps: How to Get Started, coming soon.

Jamie Arnold