Devops

DevOps is a cross-functional systems engineering culture that aims at unifying systems development (Dev) and systems operations (Ops) with the ability to create and deliver fast, cheap, flexible and with adequate quality, whereby the team as a whole is responsible for the quality. Usually, other types of expertise, like Business Analysis and Quality Assurance (including testing), are integrated in the team.

DevOps is aimed at solving inefficiencies within the systems manufacturing process. A DevOps culture has an Agile mindset that can be supported/implemented by, for example, the Scrum framework.

DevOps activities

DevOps is an elusive phenomenon. There are discussions about who is the founder of DevOps and what a DevOps delivery model should look like. To avoid this discussion, we use a “simplified” model based on which most common activities are plotted.

We identify six DevOps activities: Monitor, Plan, Code, Integrate, Deploy and Operate. These activities provide excellent support to explain the integration of DevOps activities with the quality assurance and testing activities (“topics”). See “Topics plotted on the IT delivery models“. 

Monitor

• Collect data and provide analytics. Commonly used indicators are (for more indicators please see section ‘indicators’):
  • Non-functional indicators
    • CPU usage, memory usage, diskspace usage
  • Functional indicators
    • Heartbeat check, health check, metrics (e.g. http response status and http response time), auditing
• Inspect the performance of the CI/CD pipeline and improve where necessary to increase the productivity of the development and operations teams.
• Measure the team performance as a basis for continuous improvement.

Plan

• Collect requirements and feedback from stakeholders and customers, and use input from monitoring.
• Build a product roadmap for delivery of the pursued business value.
• Write epics, features and user stories together with the criteria to be fulfilled at the end of each DevOps activity. Of course, other ways to describe functionality can also be used, such as use cases.
• Build a backlog.
• Plan iterations (when using a Scrum board) and allocate tasks or use another approach like Kanban.
• The list of epics, features and user stories must be maintained and adapted to new insights.

Code

• Write code for epics, features, user stories, et cetera from the plan.
• Automate processes (e.g. deployment and test automation).
• Commit code to a shared repository, that allows historical viewing, branches, versioning, and more.
• Define and run the automated unit tests.
• An important part of this activity is confidence. Developers will store code in a code manager. Besides this, each piece of software must include its own automated tests.

Integrate

• The code is integrated to a deployable and testable application, the so-called build.
• Perform a series of manual and automated tests. For instance:
  • run automated integration and end-to-end tests.
  • run traditional – manual – user acceptance test (UAT) which must give confidence that the software doesn’t fail or negatively impact other pieces of software, the acceptance criteria are met, and – possible – anomalies identified.
  • run security, performance and other non-functional tests.
  • check for changes in infrastructure.

Deploy

• Release the build – automatically – into production using a CI/CD pipeline.
  • When done manually: Continuous Delivery.
  • When done automatically: Continuous Deployment.

Operate

• The new release is live and used by customers.
• This is where the business value is experienced.
• Create a feedback loop and use tooling with which customers can give feedback on the services.
• Use the feedback for updating the backlog.

DevOps prerequisites

Prerequisites that are often mentioned together with DevOps are:

• Disciplines
• Responsibility
• Service flow
• Cross functional
• 100% Allocated

CALMS

Jez Humble, co-author of The DevOps Handbook [Humble 2016], mentioned CALMS as a conceptual framework for the integration of development and operations team functions and systems within an organization. The CALMS framework is often used to evaluate whether an organization is ready for DevOps.

CALMS pillars

• Culture
  Organizations embrace system thinking and a “learn fast” culture. This makes interdisciplinary and cross-functional collaboration easier. For example, business, development, quality assurance & testing, operations and architecture work together within integrated development and delivery processes.
• Automation
  By automating DevOps processes, these processes are anchored in the organization. From the automation of continuous integration and cloud provisioning to the automated performance of regression or performance tests.
• Lean
  Processes become more efficient and flexible. Firstly, it stimulates productivity. Secondly, it makes it possible to respond quickly to current customer requirements.
• Metrics
  Measure continuously. For example, the change failure rate, mean time to recover, the total lead time and the customer responses to improvements. Measurement thus forms the basis for continuous improvement.
• Sharing
  By sharing tools, knowledge, an architecture or code, an open culture is realized inside and outside the team. DevOps as the engine of digital transformation requires a new way of working, whereby Development & Operations go hand in hand with efficient, flexible processes supported by suitable applications. This is how the digital organization continuously learns, responds quickly to developments, and becomes and remains agile.

Continuous everything

The main goal for an organization to implement DevOps is to enable continuous delivery of value to the end users. That is why in DevOps, a CI/CD pipeline is implemented to be able to deliver the pursued business value to the users. Continuous Integration (CI) handles possible problems caused by multiple people developing in parallel and thus introducing dependencies in the code.

CI/CD is the backbone and an enabler of DevOps. It bridges, maybe even closes, the gap between development and operations teams by automating the building, testing, deployment of applications and provisioning of infrastructure. In addition to CI/CD, there are of course other aspects (pillars) that bridges the gap between Dev and Ops.

Because CI/CD implementation is common in DevOps, Building Block “CI/CD pipelines“, explains the continuous activities and discusses how to set up such a pipeline and often-used tools.