This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
What DONE Looks Like in DevOps
Have you ever wondered about the meaning of DONE in DevOps? If you’re including DevOps in the definition of DONE, what are the agile changes that need to occur?
Fortunately, after working with many organizations exploring these questions, I’ve figured out that the answer isn’t that difficult.
So, what’s the meaning of DONE in a DevOps world?
Definition of Done in a DevOps World
DevOps creates the need for a lot of changes in the development process, not just from the technical aspect of continuous delivery, etc., but also with regards to agile. One of the aspects of agile that’s most interesting is the definition of DONE in a DevOps environment.
This isn’t a new problem by any means; people have been arguing about what the definition of DONE should be since Scrum became popular, and maybe even prior. As development teams begin to infuse DevOps practices, they need to rethink the definition of DONE. In the DevOps world, DONE doesn’t just mean it is coded and tested; it means it will work in production.
A few years back, at one of VersionOne’s AgilePalooza events, a tester asked a question that saddened me. She asked, “So what do you do when the story is done, but it hasn’t been tested?” I think a tear rolled down the cheek of each of the panelists as we had to explain, “it’s not done, if it hasn’t been tested.”
Fast forward a few years, and now we are in a world where most people recognize if code hasn’t been tested or the story is not done and stories are still missing the hooks for monitoring tools. There may be no way of saying, “It is not done until we know that it can be deployed safely and we can monitor its health while it is in deployment.”
In advocating change, I am suggesting the addition of DevOps requirements to your definition of DONE. I’m asking for you to agree that no story is done until the code has been written. And if you aren’t pair programming, then the peer review has happened, the tests are all passing, and the hooks for monitoring, performance evaluation and health checks are in as well. This is vital if you want to be successful with DevOps.
DevOps is all about moving quickly and deploying continuously. If you’re going to deploy continuously, you need to know that what you’re putting out is ready to go out. That means you have to be prepared for when the code meets the real world. You need to know right away if something bad happens when the code is deployed. You can’t wait until somebody calls and asks, “Why can’t I get onto your website anymore?” That is not good enough. If you deploy something, you have to find out before the customer does if something is not working right.
You have to make a few additions to stories to incorporate DevOps into the definition of DONE. The first step is adding the requirements to enable you to understand how the code is doing after deployment. Second, when you are planning a story, you’re going to need to estimate based on what it means to have the code in a state that will be successful post-deployment. Third, every single member of the team is a developer, and every single member of the team is a tester. Every single member of the team is now on the operations staff as well. That is where true success will happen in the DevOps world.
If you’re not fusing DevOps into your agile stories, you should start doing so right away. If you already are, make sure you’re including the hooks for monitoring, performance evaluation, and health checks as well.
What do you think about including DevOps into the definition of DONE? Are you going to start including post-deployment requirements in your definition of DONE?