DevOps: Finding Your Path to Successful and Continuous Improvement

Georges Lteif

Georges Lteif

Software Engineer

Last Updated on April 10, 2022.
Subscribe now to stay posted!
About Us
7 min read

1. Overview

Looking at the below graph from Google Search Trends, we can see that DevOps has picked up much momentum in the last five years and is steadily increasing, making it interesting to understand more about it.

devops search trends
DevOps vs Waterfall vs Agile Search Trends

The graph compares DevOps search trends with Agile and Waterfall, both software project delivery methodologies. This categorization might give you the impression that DevOps is another methodology competing with Agile and Waterfall, but it’s not quite that.

In this article:

  • We look at DevOps and what it means in the context of software delivery.
  • We will explore the concepts of Continuous Integration, Continuous Deployment, and Continuous Delivery.
  • We will also attempt to find out where do these relatively new practices stand concerning Agile and the current state of software delivery in general.
  • Whether you should consider using DevOps as your primary software delivery methodology.

DevOps is another tool (or set of tools) that you can use to enhance your delivery processes. While the principles we listed under Operational Excellence for Software Development do not require specific instruments, practitioners must be fluent in the popular ones before making a long-term commitment to any of those, including DevOps.


2. Table of Contents


3. Definitions

Before we attempt to define DevOps, let’s first go over a few essential terms and what they mean in the context of software delivery.

3.1 What is Continuous Delivery

To put it in relatively simple terms, if your organisation can ship changes to production quickly and frequently, then it is doing Continuous Delivery.

The traditional Software Development Lifecycle is usually something like this:

  1. Analysis
  2. Design
  3. Code changes followed by code review
  4. Software Testing which can cover a whole lot of types:
  5. Deployment to production
  6. Monitor and report any bugs

We have emphasized the Testing stage by listing all of its types because it is quite relevant to this discussion.

To ship new features frequently and quickly, you need to ensure they arent breaking anything, and in the unfortunate case where they do, you need to ensure you can determine the problem and fix it in hours and not days.

You can be reasonably sure that your new feature isn’t breaking anything only when the new release has successfully passed all the testing mentioned in that list.

Let’s now turn our eyes back to Continuous Delivery.

The series of tests is called a deployment pipeline.

3.2 What is Continuous Integration

Continuous Integration is a feature of your software delivery methodology. It means the following:

  • Several developers working on new product features can integrate their changes daily in the same codebase.
  • If a new bug is introduced, it can be identified promptly by running tests on the application to determine the specific change responsible for the problem.

Three factors favour the ability to identify issues rapidly:

  1. The use of test automation.
  2. Pushing code changes in small sizes.
  3. The presence of a comprehensive battery of test cases.

Continuous Integration is a requirement for Continuous Delivery.

3.3 What is Continuous Deployment

There is some disagreement in the community on what Continuous Deployment means, but we have found the definition from Atlassian’s website to be the most useful:


Continuous Deployment (CD) is a software release process that uses automated testing to validate if changes to a codebase are correct and stable for immediate autonomous deployment to a production environment.
Atlassian

Martin Fowler describes Continuous Deployment as the action of frequent deployment to production, whereas Continuous Delivery is having the ability to do just that.

As per Fowler, the difference between Continuous Deployment and Continuous Delivery lies in that deployment to production is essentially a business decision. 

Regardless of what the business decides on each new feature, doing Continuous Deployment means that developers must have enough confidence in deploying any changes as soon as the business gives the green light for deployment.

3.4 What is DevOps

Now that we have Continuous Delivery, Deployment, and Integration well described and understood, we turn our attention to DevOps.

Although a formal definition of DevOps is hard to come across, I find the one from Atlassian to be the most useful:


DevOps is a set of practices that works to automate and integrate the processes between software development and IT teams, so they can build, test, and release software faster and more reliably.

Atlassian

In this first definition, we detect the first hint of a significant deviation from the familiar Agile and Waterfall project delivery methodologies: the incorporation of Operations as a relevant and influential factor in software delivery.

Up until now, operations (production deployment, monitoring, and support) were not issues that developers had to worry about.

Once a change has been tested locally, or under lab settings, it was deemed ready for production. Because of the radical differences between the two environments, production deployment was always a significant event.

Martin Fowler emphasizes this fact in another lucid definition of DevOps along the same lines.


DevOps is really saying that application developers should have to be aware of operational needs… and it means that operations people have to think: How can we smooth rapid deployment so that it becomes less of an event.

Martin Fowler

The traditional separation of duties and responsibilities between development and operations created much friction between the corresponding teams.

The operations teams viewed new releases with a wary eye, while developers viewed production issues as part of support and not an immediate problem that they needed to be overly concerned with.

Therefore, the primary objective of DevOps was to remove that friction, an idea eloquently put forward by Patrick Debois.


DevOps is whatever you do to bridge friction created by silos, and all the rest is engineering.

Patrick Debois

All these definitions imply a movement towards uniting two teams, developers and operations, that mostly lived and worked in isolated silos before DevOps.


4. State of DevOps 2021

The 2021 State of DevOps report is produced yearly and follows closely the adoption of DevOps practices across organizations participating in the surveys. The current account has some interesting statistics.

We start with the below graph, which shows the percentage of participants who reported having different levels of DevOps practices in their organizations.

devops adoption stats
DevOps Adoption in 2021

In 2021, 18% of organizations surveyed reported having highly-evolved DevOps practices in their teams.

DevOps Impact on Deployment Frequency, Lead Times and Change Failure Rates

Now, look at what the highly-evolved organizations report to be able to achieve in terms of:

  • The frequency of production deployment which went down from a month to on-demand
  • Lead times for new product changes which were cut down from weeks or months to minutes
  • And finally, the change failure rate which was reduced three folds from 15% to 5%.

These numbers are pretty impressive when considering the gap between what those on the higher tiers can achieve compared to the lower ones in terms of outstanding delivery capabilities.

Even the mid-level organizations are not too far off.


5. Should You Start Using DevOps Now?

5.1 Pre-Requisites

The fact that you can implement DevOps (or Agile, for that matter, see our article on this topic) in bits and pieces is what makes software delivery a complex endeavour. Deciding what the right tools and practices for your specific team are can be a challenge, and the same applies to upgrading your production processes.

For this reason, we consider the following steps as a great guide to help you make a decision:

  1. Determine the gap between Agile or Waterfall and DevOps
  2. Understand the requirements for implementing DevOps

The following sections will delve into the details of these two steps.

5.2 What Is Missing in Agile and Waterfall

As described in previous sections, both Agile and Waterfall focus on development; their job falls short of deployment and operations.

Deployment to production has always been risky, and today’s organizations can no longer afford that kind of risk. The reasons why that risk exists can be summarized as follows.

5.1.1 Laboratory Testing Conditions

Software is typically developed and tested under laboratory conditions; this limitation can be problematic as issues may go unnoticed.

Let’s look at some examples of the discrepancies between lab and production settings to appreciate the extent of the problem:

  • Mismatches on OS versions or patches: a common problem is updated libraries and interfaces that may become unusable. Another issue is when supporting multiple OS platforms, such as Linux and Windows; you use a function that runs OK on one OS but not the other.
  • Different third-party application versions (database engines, external systems or services): updated versions may, for example, support additional configuration or modified function calls.
  • Mismatching configuration that can differ significantly between clients: unless you offer a one-size-fits-all solution, a modified feature needs to be tested under a wide array of setups, typically one per client, to be on the safe side.
  • Hardware resources: This difference can be an issue when running performance tests on lab machines and extrapolating the results into production ones.

5.1.2 Bulk Deployment of Changes

Deploying a large bulk of changes means that if something breaks, any of those changes (alone or combined with other changes) can be responsible for the issue. This practice makes it hard to identify the problem and fix it quickly (less than an hour, for example).

By deploying frequently and in small pieces, Continuous Delivery practices reduce or eliminate this risk.


6. Implementing DevOps

6.1 Overview

Like Agile or any other radical change applied to existing production processes, DevOps requires a few necessary ingredients such as specialised skills, effort, resources, and infrastructure.


Low-evolution teams have a familiar (if dizzying) mix of blockers to better DevOps practices. Most cite organizational resistance to change (31 percent), followed by legacy architecture (28 percent), shortage of skills (23 percent), limited or lack of automation (20 percent), and unclear goals or objectives (20 percent).
State of DevOps Report 2021

The following sections list a few obvious as well as non-obvious requirements. You will notice a congruence between these requirements and the challenges reported in the State of DevOps Report of 2021.

6.2 Automation

We have argued in a previous article about the crucial role of automation when migrating to Agile. The centre of attention was on automating the majority of testing activities. 

devops automation
DevOps and Automation

With DevOps, this requirement now extends to other areas of the software development lifecycle, such as build and deployment. Like in the case of Agile, this requirement is mandatory.

Participants from the State of DevOps 2021 Survey reported the following:

  • 90% of the respondents said their teams had automated most repetitive tasks.
  • 97% of the respondents agree that automation has improved the quality of their deliveries.

The table below shows all the areas that can benefit from automation. Tools and practices already exist to achieve that level of automation.

StageAutomated Activities
BuildCompiling and building applications on different OS platforms, with varying building and packaging parameters.
Unit TestsRun all unit tests on the latest code and make sure they pass before applying the changes.
Infrastructure PreparationsWith the availability of programmable infrastructure, containerization, and cloud technology, you can spin up a fresh environment for every build or test run.
System Integration TestingFor each new build, you spin up a new test environment, apply specific configuration settings, and then run all system integration tests and report the results automatically to JIRA.
Production DeploymentAvoid any user or human errors when deploying or operating new software by rehearsing all upgrade operations on test environments and executing the same scripts on production in an automated manner.
Monitor Production EnvironmentsSpecial applications can look at live system parameters and report faults in real-time.
Benefits of Automation at Different Stages of the SDLC

6.3 Infrastructure

A DevOps infrastructure can be thought of as a sequential integration of tools that allow the implementation of a Continous Integration/Continuous Deployment (CI/CD) pipeline.

DevOps pipeline
DevOps Pipeline

The table below shows the various stages of a CI/CD pipeline, the operations performed at each step, and the tools used in the process.

StageOperationTools
PlanProject planning, resource allocation, epic and user story creation, solution design, sprint planning.Confluence, JIRA, MS Office
CodeFeature development which includes building unit or integration tests when using Test-Driven DevelopmentGit, JUnit, Google Test
BuildBuilding of applications. You might want to have a different build per customer, OS, or some other parameter.Maven, Ant, Gradle
TestTesting and quality assurance is performed at this stage. These can be unit, integration, or regression tests. Containerization with Docker, for example, and the setup of fresh test systems can be highly convenient for better results.JUnit, Google Test, Selenium, Mockito.
ReleasePackaging and release of new application versions.Codeship
DeployDeployment, onsite or cloud-based.Kubernetes, Docker, AWS, Azure
OperateDeploying and configuring applications in different setups.Chef, Puppet, Ansible.
MonitorMonitoring application health and smooth operations.Nagios, Zabbix, Splunk.
Breakdown of DevOps CI/CD Pipeline

A few ideas that are worth noting when thinking about a DevOps infrastructure:

  1. You can use a subset of the tools in a simple pipeline to enhance your current production processes without the need to set up and run the whole suite in its most elaborate form. A simplified setup can be an option if there is no business need or you don’t have the budget and resources. Think of Agile, Waterfall, and the Hybrid models in between.
  1. Tools are never enough, and it is easy to lose sight of the big picture once you find yourself immersed in the setup of sophisticated environments. The objective of adding new tools is to upgrade your production processes. It would be best to decide, before any major investment, whether this will bring you closer to achieving Continuous Integration or Continuous Deployment, assuming that this is what you are after in the first place.
  1. As you might have noticed, the number of available tools on the market is impressive and deciding on which ones are the most suitable can be challenging. A great rule-of-thumb is always to prefer mature and time-tested methods and means over the latest craze.

6.4 Support from Leadership

Due to the potentially disruptive nature of migrating to new and demanding software delivery processes and the cost involved in time and effort, support from leadership is imperative.

This fact has been mentioned numerous times in the State of DevOps 2021 Report with a powerful message on the impact of leadership support on the DevOps adoption process.


The most highly evolved firms benefit from top-down enablement of bottom‑up transformation.
State of DevOps Report 2021

The quote above has two critical ideas regarding organizations with highly-evolved DevOps practices: 

  1. A top-down enablement exercise emphasizing the role of leadership
  2. A bottom-up transformation underlining the importance of stakeholder management in decision making.

Fewer than two percent of high-level organizations report resistance to DevOps from the executive level.
State of DevOps Report 2021

The results of transformations on a large scale might be evident on longer time scales only, and hurdles will need to be cleared. Without leadership support, fatigue might set in.

There are times in significant transformations where painful decisions need to be made, such as abolishing or changing the roles of QA staff. Decisions of such magnitude need to be made on senior levels.


Strong teams can create substantive change within themselves and in adjacent teams, yet in the absence of meaningful leadership support, success will be confined to pockets, and widespread evolutionary improvement will not occur.
State of DevOps Report 2021

In our article on Operational Excellence, we have argued the importance of having process governance to ensure standardization and knowledge propagation is shared across the organization. Process standardization is fundamental to avoid improvements remaining in isolated and inconsequential instances.

6.4 A Non-Resistant Culture

Organizational cultures play a significant role in the organization’s evolution, and they can either inhibit or foster innovation and change.

devops cultural blockers
DevOps Cultural Blockers

The State of DevOps 2021 Survey reports the following statistics among mid-level respondents regarding cultural blockers:

  • 21% report their culture discourages risk-taking
  • 20% state responsibilities among team members are unclear
  • 18% report that fast flow optimization is not a priority
  • 17% insuficient feedback loops

Aspects of organizational culture that can greatly impact the adoption of different methodologies are as follows:

devops maturity process
Clear Roles and Responsibilities

Let’s see if we can elaborate more on the impact of organizational culture when it comes to change. The below are leverage points where organizational culture has much influence.

  1. Risk appetite for trying new things
  2. Acceptance (or lack thereof) vis-à-vis “Failed Experiments.”
  3. Clear roles and responsibilities, especially when it comes to process governance
  4. Top-down enabled and delegation of power, i.e. how much trust the leadership shows for the team and how much power it’s willing to share
  5. Prioritization of process improvement over BAU
  6. Unobstructed information flow in both directions: top-to-bottom and vice versa

6.5 Agile Maturity and Fluency

DevOps is closer to Agile than it is to Waterfall, which, in my view, emphasizes the importance of having some fluency in Agile practices. It just makes it easier to make sense of what drives DevOps and Continuous Delivery.

This fact, however, does not mean that you cannot move into DevOps without going through the Agile first; our view is that it is somehow irrelevant to the final result. It’s just that DevOps is an even more radical departure from the old ways of Waterfall, and some exposure or understanding of Agile can help assimilate the ideas behind DevOps.


7. Final Words

DevOps presents significant benefits that can radically improve your software delivery capabilities, and therefore, we believe it needs to be part of any discussions on process improvement.

That being said, religiously following specific ideas and making a cult out of them is never great; we believe it will have the opposite effect.

Like any other methodology, DevOps is neither good nor bad, and its utility depends heavily on the specific circumstances where it’s applied.


8. Further Readings

Great talk by Martin Fowler.


Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles

1. Overview I could not find a better way to start an article on Risk and Risk Management than by quoting the opening lines of Donald Lessard and Roger Miller’s 2001 paper that, briefly but lucidly, summarizes the nature of large engineering endeavours. It goes like this: This article leans heavily on three handbooks thatContinue reading “Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles”

Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction

1. Overview Dealing with complexity is an integral part of our lives, even if we do not realise it.  An organisation can be modelled as a complex system from the scale of megacorporations right down to the smallest teams. The architecture of software solutions can be equally complicated, and megaprojects and implementations are certainly involved.Continue reading “Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction”

Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos

Synopsis Most physical theories adopt a mechanistic view when examining natural phenomena where any system can be modelled as a machine whose initial conditions and dynamics govern its future behaviour. In this book, Programming the Universe — A Computer Scientist Takes on the Cosmos, Professor Seth Lloyd proposes a radically different approach centred around aContinue reading “Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos”

From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems

1. Overview Software design and architecture are two very elusive concepts; even Wikipedia’s entries (ref. architecture, design) are somewhat fuzzy and do not clearly distinguish between the two. The Agile manifesto’s statement on architecture and design is especially brief and raises more questions than answers. The most common definition of software architecture is as follows:Continue reading “From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems”

Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects

1. Overview The complexity of business requirements in IT projects has experienced exponential growth due to pressures by increasingly sophisticated client preferences, novel technologies, and fierce competition. Consider, for example, the case of financial payments. In the mid-80s, most payment transactions occurred inside bank branches, and only the biggest banks offered services on ATM orContinue reading “Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects”

Loading…

Something went wrong. Please refresh the page and/or try again.

Leave a Reply