If you are in the Enterprise, you likely know about ITIL. If you talk to your leadership or operations about DevOps concepts, they will eventually say that ITIL or Service Management will not let us do DevOps. How do you over come this thinking? You don't. ????
I recently heard the best justification for ITIL. John Willis made a statement on a podcast that ITIL was put in place to control operations that are human or manual based and by definition out of control. (paraphrased) This was a great statement that really hit home with some of the operations team I have seen. When people are doing all the work, you need to put in practices that moderate all impacting activities.
Now, if you understand DevOps and how most ITIL shops work, you should see the path to start working toward DevOps practices in an ITIL Enterprise. If you don't see it yet, then close this blog now and come back in a few hours after you think through it.
Here is my recommendation.
First: stop talking about DevOps. It scares traditional operations people, especially the ones that think you have enough issues to deal with already. Talk about automation and better communication.
Second: don't talk about doing 4,000 or even 10 deployments per day. Common Man!!! Think how crazy this is when you can't even do one change without issues. Talk about doing automated deployments to your Test or QA environments. "Hey Boss, it would be awesome if we could let QA do their own deployments so they don't have to open tickets and wait on operations and I know a way to do it." Don't do it. Do NOT say it. Just think it. ("DevOps") You can do this all with free tools. You could get some of the developers and ops together in a Skunk works project to implement it. If you have a really innovative project, you might be able to do it in one of your lighter feature sprints but I don't see that happening too often. Implement this and do it over and over until it works every time.
Third: After you do the second step very consistently, someone is going to notice. You just saved operations hours per week. You just decreased your cycle time by probably 24 or 48 hours, because QA is not waiting. You are now the man/women of the year and people will want more. CI is like blue meth from Breaking Bad. This is when you get everyone on board. Ops will want to do push button deployments to prod. Make sure the dev team is supporting this and it is working great in prod as you roll it out in production. Don't just throw CI over the fence to Ops, this is your Pipe Line. The Pipe Line requires love and feedback just like a new feature. Try it in a few schedule windows. Give your window enough time to resolve any unanticipated issues in production.
Fourth: At this point you should have a big back up of inventory waiting to go through CABs and approvals to get into prod. Your constraint is now ITIL. This is the point that most people miss with ITIL. Everyone wants to slap ITIL around but they really need to slap them self first. You have not resolved the issue that ITIL addresses first, go back and read paragraph two. You have a good case to do deployments during pre-approved night windows, as long as it follows the process. Now you are deploying once a day. That is progress.
Fifth: Here is where I throw you to the wolves. Be ready, because it will happen. Ops deploys night one, night two, night three and on night 4 it all blews up. The site would not work. Here is where all the skeptics will come out. "See we told you this would not work" They don't even realize you just deployed three times with no issues and you only deployed three times last quarter. It is likely that the environment changed. So if you can, fix the environment issue and redeploy.but don't blame it on ops. This is when you start talking about how important it is to keep our environments in sync. Don't talk about Chef and Puppet. They are not ready for that if they aren't already doing infra as code.
Six: You get a call the next morning, after one of the changes. "We have a serious issue. We have a bug in the order page." You have a chance to be a hero again. Embrace the bug not fight it. Get ops, QA and Dev together and find the cause. Show them the secret sauce and deploy through your pipe line and BOOM there is ITIL again. Let them be amazed. Just show how fast, through collaboration and automation, you went from identification, to fix, to QA approval. Then, ITIL is your road block to addressing the fix. BTW, don't forget to update your integration test, unit test or manual test scripts to address the bug. This may not really be as easy as I make it sound because if you have good testing practice, the bug is probably an edge case or unexpected.
Here is the detail that most miss the value. Unless this is a seldom used part of the application, you only have to go as far back as the last release (possibly 24 hours ago) to find what could have changed. You are not looking through months of changes, thousands of check ins or 30 different developers. This is a key point to advertise.
Lastly, you started the snowball rolling. Let it get bigger and bigger to Continuous Delivery. Let it come naturally. Don't push it. Look back and realize what you did. You have communication and team work between Dev and Ops. You have automation. You have frequent changes to produce more customer value and lower risk. Now you are leading DevOps but leading never stops. DevOps never stops. Both are continual improvement.
I recently heard the best justification for ITIL. John Willis made a statement on a podcast that ITIL was put in place to control operations that are human or manual based and by definition out of control. (paraphrased) This was a great statement that really hit home with some of the operations team I have seen. When people are doing all the work, you need to put in practices that moderate all impacting activities.
Now, if you understand DevOps and how most ITIL shops work, you should see the path to start working toward DevOps practices in an ITIL Enterprise. If you don't see it yet, then close this blog now and come back in a few hours after you think through it.
Here is my recommendation.
First: stop talking about DevOps. It scares traditional operations people, especially the ones that think you have enough issues to deal with already. Talk about automation and better communication.
Second: don't talk about doing 4,000 or even 10 deployments per day. Common Man!!! Think how crazy this is when you can't even do one change without issues. Talk about doing automated deployments to your Test or QA environments. "Hey Boss, it would be awesome if we could let QA do their own deployments so they don't have to open tickets and wait on operations and I know a way to do it." Don't do it. Do NOT say it. Just think it. ("DevOps") You can do this all with free tools. You could get some of the developers and ops together in a Skunk works project to implement it. If you have a really innovative project, you might be able to do it in one of your lighter feature sprints but I don't see that happening too often. Implement this and do it over and over until it works every time.
Third: After you do the second step very consistently, someone is going to notice. You just saved operations hours per week. You just decreased your cycle time by probably 24 or 48 hours, because QA is not waiting. You are now the man/women of the year and people will want more. CI is like blue meth from Breaking Bad. This is when you get everyone on board. Ops will want to do push button deployments to prod. Make sure the dev team is supporting this and it is working great in prod as you roll it out in production. Don't just throw CI over the fence to Ops, this is your Pipe Line. The Pipe Line requires love and feedback just like a new feature. Try it in a few schedule windows. Give your window enough time to resolve any unanticipated issues in production.
Fourth: At this point you should have a big back up of inventory waiting to go through CABs and approvals to get into prod. Your constraint is now ITIL. This is the point that most people miss with ITIL. Everyone wants to slap ITIL around but they really need to slap them self first. You have not resolved the issue that ITIL addresses first, go back and read paragraph two. You have a good case to do deployments during pre-approved night windows, as long as it follows the process. Now you are deploying once a day. That is progress.
Fifth: Here is where I throw you to the wolves. Be ready, because it will happen. Ops deploys night one, night two, night three and on night 4 it all blews up. The site would not work. Here is where all the skeptics will come out. "See we told you this would not work" They don't even realize you just deployed three times with no issues and you only deployed three times last quarter. It is likely that the environment changed. So if you can, fix the environment issue and redeploy.but don't blame it on ops. This is when you start talking about how important it is to keep our environments in sync. Don't talk about Chef and Puppet. They are not ready for that if they aren't already doing infra as code.
Six: You get a call the next morning, after one of the changes. "We have a serious issue. We have a bug in the order page." You have a chance to be a hero again. Embrace the bug not fight it. Get ops, QA and Dev together and find the cause. Show them the secret sauce and deploy through your pipe line and BOOM there is ITIL again. Let them be amazed. Just show how fast, through collaboration and automation, you went from identification, to fix, to QA approval. Then, ITIL is your road block to addressing the fix. BTW, don't forget to update your integration test, unit test or manual test scripts to address the bug. This may not really be as easy as I make it sound because if you have good testing practice, the bug is probably an edge case or unexpected.
Here is the detail that most miss the value. Unless this is a seldom used part of the application, you only have to go as far back as the last release (possibly 24 hours ago) to find what could have changed. You are not looking through months of changes, thousands of check ins or 30 different developers. This is a key point to advertise.
Lastly, you started the snowball rolling. Let it get bigger and bigger to Continuous Delivery. Let it come naturally. Don't push it. Look back and realize what you did. You have communication and team work between Dev and Ops. You have automation. You have frequent changes to produce more customer value and lower risk. Now you are leading DevOps but leading never stops. DevOps never stops. Both are continual improvement.
Comments