I’m Mike. I work in DevOps. Since I work in DevOps for a living, I think about DevOps. I read about it. I listen to talks on it. Watch videos. I have an Ansible and Chef T-shirt. I know, cool. I give ad-hoc lectures to small audiences on the merits of my work. My wife, kids, and dog are the most common recipients of these. I also think I am funnier than I am.
I am working on some theories around the implementation of DevOps within the context of an enterprise. I am basing these theories largely on my experience at a large corporation during their Agile / DevOps transformation. But full disclosure, I am continuously learning and growing in this area. I do not have all the answers. My expectation for myself is to share an evolution of ideas and opinions as I gain insights from my personal journey. This is why I have titled this series “DevOps Notebook” – it is intended to capture the theories, opinions, observations, and general ideas I have, at the time of publishing, on DevOps. Some of it might be downright stupid, but I hope you find it, on average, helpful.
Here are a few thoughts I have today about what to consider before undergoing a DevOps Transformation.
Please don’t create a team and call it DevOps. Instead, create cross-functional teams which practice DevOps. A DevOps team (a team that does DevOps) should include both developers and operations people who work together to achieve common objectives.
Get the Development shop in order before the restructure. With regard to adopting DevOps, it does not matter if the team is Waterfall or Agile. However, if development is not leveraging test automation for unit testing, regression testing, security and performance testing, an investment should be made here before anything else.
The SCM strategy should be assessed for optimization. If non-code changes are not treated as code, if implementation of these items is not part of an automated, version controlled deployment/release process, these are good opportunities to shore up in advance, where possible.
Get the Operations shop in order before the restructure. Is there any antiquated infrastructure requiring remediation? Any data-center migrations on the horizon? What new tools will need to be adopted as part of the DevOps movement? What training is needed? What is the plan for retooling the workforce to support target state? What is the division of labor for “wheels on the bus” support vs. driving transformation? Clear the runway with respect to these item to make room for prioritization of new work.
Consider Agile. A well rounded DevOps team should include product owners, development, QA, IT Operations, and InfoSec specialists. If you see the resemblance to an Agile team in the above, this is one of the obvious strengths of utilizing DevOps within an Agile context. But again, you don’t have to be agile to adopt DevOps. A cross-functional dotted lined team comprised of the above can and should reap the benefits of DevOps within the Waterfall paradigm.
If you have comments or feedback on this entry, please consider leaving a comment. I would appreciate any feedback or questions.