patternModerate
Definition of "Done" for DevOps
Viewed 0 times
definitiondevopsfordone
Problem
I've being recently interviewed for a DevOps position. One of the questions I was asked was:
What is your definition of "done" in the DevOps context?
The question is rather broad, but, as I understand, the answer has to cover Automated builds & tests as well as Continuous Integration & Deployment & Delivery. I am looking for general principles and ideas that can be used to define "Done".
What is your definition of "done" in the DevOps context?
The question is rather broad, but, as I understand, the answer has to cover Automated builds & tests as well as Continuous Integration & Deployment & Delivery. I am looking for general principles and ideas that can be used to define "Done".
Solution
Instead of Continuous Integration and Continuous Delivery, I would define the definition of done as "Active Continuous Improvement at all levels of the organisation".
The other topics like automated builds, CI/CD, etc... these are just milestones and most definitely not the ultimate goal for the organisation in its DevOps efforts.
It does look like it might be "finished all DevOps" once you have an automated system with continuous integration. But in fact, even should you reach this stage, you will find plenty more to do.
Getting to a state where most people in the organization are constantly looking to continuously improve is extremely hard. Inertia often gets in the way, both existing inertia, and new inertia once some improvements were accomplished.
There is a lot to learn from Lean and from Theory of Constraints in this aspect. Both bodies of knowledge focus on the process of continuous/ongoing improvement and how to establish this process in an organization.
The other topics like automated builds, CI/CD, etc... these are just milestones and most definitely not the ultimate goal for the organisation in its DevOps efforts.
It does look like it might be "finished all DevOps" once you have an automated system with continuous integration. But in fact, even should you reach this stage, you will find plenty more to do.
Getting to a state where most people in the organization are constantly looking to continuously improve is extremely hard. Inertia often gets in the way, both existing inertia, and new inertia once some improvements were accomplished.
There is a lot to learn from Lean and from Theory of Constraints in this aspect. Both bodies of knowledge focus on the process of continuous/ongoing improvement and how to establish this process in an organization.
Context
StackExchange DevOps Q#1714, answer score: 12
Revisions (0)
No revisions yet.