You might insist that the word “DevOps” doesn’t contain the letter “Q” anyways, so the title is misleading, for which there’s no reason in reading beyond this point. I kindly ask you to bear with me, so that in the next few lines I can show to you that there is a "Q" for quality in DevOps, even though it might be invisible at a first glance.
A vast part of my daily work here at SAP I spend in explaining various people what DevOps is, how Continuous Delivery relates to it and how we could implement both. When people hear that I work for SAP's central quality organization, they're often confused: What role does quality play in DevOps?
If we look into the first two ways of the three ways which are the underpinning principles of DevOps we see that the first way is about systems thinking.
The first way tries to improve the complete product creation flow. One prominent technique to archive a better flow at software creation is Continuous Delivery. Continuous Delivery enables you to build better software by speeding up the delivery and feedback cycles with your customer. Building software in fast iterations, allows you to build the right product right.
You might say: "Great, lots of theory, but: Where’s the quality you promised?"
Let’s have a look at the Deployment Pipeline, a key concept of implementing Continuous Delivery:
The pipeline starts with building and packaging your software and ends by handing over the software to your customer. Everything in between, and your pipeline most likely will look a bit more complex than my example given above, is done to ensure high quality. Unit tests, integration tests, end-to-end test automation, functional and non-functional tests (like security and performance tests and others) are the traditional measures to ensure good quality. If you wouldn’t care about quality, you’d (locally) build and package your software and directly push it into production with no testing at all.
But even then, the build and packaging step at the beginning of the pipeline is a quality process. Your compiler ensures quality, while compiling your code. Maybe you even do lint checks before compiling or you enforce nice code formatting.
Looking at the end of the pipeline, you’ll also find quality measures, like smokes tests or health checks.
Quality is an integrated part of the first way, which must be considered in each stage.
The second way of DevOps, talks about amplifying feedback loops. Getting feedback fast into your organization is key to build the right product.
Which feedback? Well, all the feedback you can get!
It starts with monitoring and telemetry data of your productive system. Technical numbers like CPU usage, incoming and outgoing requests, memory consumption, … all of that is relevant if you want to understand the quality of your product. At least equally important: analytical data of your users and certainly direct user feedback.
Why do I tell you this?
Because quality plays a significant role also in the second way.
Monitoring and telemetry can be tested. Your systems recovery functionscan must be tested. Your new feature should be A/B tested.
Quality is about meeting the customer’s requirements. Without collecting feedback you simply don't know whether you meet (or even exceed) the customer’s requirements.
All of this is not new, but the culture change that occurs with a move to DevOps requires a conscious expansion of a traditional view of a product’s quality strategy. The complete product team needs to…:
To wrap it up: Quality is a manifold task that touches all aspects of a product lifecyle. Automation and automated tests have a strong relevance but are just one of many feedback channels.
Quality is fitness for your customer’s purpose and it's an integrated part of DevOps. Integrated to such a high extend that it doesn’t need an extra mentioning. That’s why there is no Q in DevOps (like: DevQOps*), but now you know that it’s there (as it alway was its precondition).
* = also: DevQOps would be a nightmare to pronounce
Dirk is a DevOps evangelist and Continuous Delivery expert at SAP.
Since 2001 Dirk worked in various roles at SAP including Development and Operations.
Together with his former team "TwoGo by SAP" he established the first Continuous Delivery implementation at SAP, delivering value daily to their customers.
In his current role, Dirk is a Cloud Quality Coach at SAP with focus on Continuous Delivery and DevOps practices.
Dirk is a frequent speaker at international conferences on DevOps and Continuous Delivery.
Contact:
Twitter: @doergn
LinkedIn
We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know
A vast part of my daily work here at SAP I spend in explaining various people what DevOps is, how Continuous Delivery relates to it and how we could implement both. When people hear that I work for SAP's central quality organization, they're often confused: What role does quality play in DevOps?
If we look into the first two ways of the three ways which are the underpinning principles of DevOps we see that the first way is about systems thinking.
The first way tries to improve the complete product creation flow. One prominent technique to archive a better flow at software creation is Continuous Delivery. Continuous Delivery enables you to build better software by speeding up the delivery and feedback cycles with your customer. Building software in fast iterations, allows you to build the right product right.
You might say: "Great, lots of theory, but: Where’s the quality you promised?"
Let’s have a look at the Deployment Pipeline, a key concept of implementing Continuous Delivery:
“At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users.”
- Continuous Delivery, Jez Humble & Dave Farley
The pipeline starts with building and packaging your software and ends by handing over the software to your customer. Everything in between, and your pipeline most likely will look a bit more complex than my example given above, is done to ensure high quality. Unit tests, integration tests, end-to-end test automation, functional and non-functional tests (like security and performance tests and others) are the traditional measures to ensure good quality. If you wouldn’t care about quality, you’d (locally) build and package your software and directly push it into production with no testing at all.
But even then, the build and packaging step at the beginning of the pipeline is a quality process. Your compiler ensures quality, while compiling your code. Maybe you even do lint checks before compiling or you enforce nice code formatting.
Looking at the end of the pipeline, you’ll also find quality measures, like smokes tests or health checks.
Quality is an integrated part of the first way, which must be considered in each stage.
The second way of DevOps, talks about amplifying feedback loops. Getting feedback fast into your organization is key to build the right product.
Which feedback? Well, all the feedback you can get!
It starts with monitoring and telemetry data of your productive system. Technical numbers like CPU usage, incoming and outgoing requests, memory consumption, … all of that is relevant if you want to understand the quality of your product. At least equally important: analytical data of your users and certainly direct user feedback.
Why do I tell you this?
Because quality plays a significant role also in the second way.
Monitoring and telemetry can be tested. Your systems recovery functions
Quality is about meeting the customer’s requirements. Without collecting feedback you simply don't know whether you meet (or even exceed) the customer’s requirements.
All of this is not new, but the culture change that occurs with a move to DevOps requires a conscious expansion of a traditional view of a product’s quality strategy. The complete product team needs to…:
- …be deeply conscious about quality
- …include the feedback created in/at the productive system
- …understand the feedback
- …utilize the feedback
To wrap it up: Quality is a manifold task that touches all aspects of a product lifecyle. Automation and automated tests have a strong relevance but are just one of many feedback channels.
Quality is fitness for your customer’s purpose and it's an integrated part of DevOps. Integrated to such a high extend that it doesn’t need an extra mentioning. That’s why there is no Q in DevOps (like: DevQOps*), but now you know that it’s there (as it alway was its precondition).
* = also: DevQOps would be a nightmare to pronounce
Further Info
Useful links & references
About the Author
Dirk is a DevOps evangelist and Continuous Delivery expert at SAP.
Since 2001 Dirk worked in various roles at SAP including Development and Operations.
Together with his former team "TwoGo by SAP" he established the first Continuous Delivery implementation at SAP, delivering value daily to their customers.
In his current role, Dirk is a Cloud Quality Coach at SAP with focus on Continuous Delivery and DevOps practices.
Dirk is a frequent speaker at international conferences on DevOps and Continuous Delivery.
Contact:
Twitter: @doergn
We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know
- SAP Managed Tags:
