Niek Bartholomeus recently finished composing a four post DevOps focused blog series about leading the implementation of configuration management and release management in a traditional enterprise. Niek covers the theory of DevOps, then an analysis of the problems with software delivery within a traditional enterprise, and finally the application of specific DevOps practices to solve the problems. Niek created the series after reading The Phoenix Project by Gene Kim, he expressed his motivation as follows:
an attempt to fill the hole between's Gene's fairy tale and the IT Skeptic's reality.
Niek explains the theory of DevOps as the introduction of efficient processes that are supported by tooling built for automation while building a culture of collaboration and end-to-end understanding. Niek analyzed the forces opposing the introduction of DevOps: teams protecting opposing interests, the seemingly inherent conflict between change vs. stability, and just plain old human resistance to change. In spite of these challenges the DevOps practices in his story are specifically targeted at overcoming the complexity of software delivery, which in its worst state is a non-scalable, manual, and labor intensive process.
Niek documents the introduction of configuration management in his third blog post. He discusses the necessity to accurately manage the relationships between business applications, change requests, software components, deployment requests, and releases. In his final post, Niek documents the introduction of release management and the integration with the previously introduced configuration management tooling. Leading to a final conceptual diagram from his post:
Niek acknowledged that the more advanced DevOps practices of continuous delivery and zero downtime deployments require a progressive conversion of an enterprise and that the traditional enterprise in his story was not prepared yet. However, the initial steps he took lead in that direction. He stated it as follows:
if we can gradually bring our conventional software delivery process under control, automating where possible and gradually increasing the release frequency, maybe one day the leap towards continuous deployment may be less daunting
Niek concluded by saying that the work done to introduce DevOps practices contributed to solving multiple real world problems. He noted that the resulting environment was automated, consistent, controlled, and properly regulated. However he acknowledge there was more to be done and specifically in the area of testing.