The Chef Community is full of excellent people with cool insights, experiences, and knowledge to share. From #ChefConf to the Developer Summit to Meetups, exchanging ideas is inherent to what our Community is all about. This principle extends to our blog, where we like to feature voices from the Community from time to time.
Michael Hüttermann is one of those voices. He’s a freelance delivery engineer with a ton of experience in creating and executing DevOps strategies, CD pipelines, and ALM. He’s also written a number of books, including “Agile ALM” and “DevOps for Developers”, which you can learn more about here: http://huettermann.net.
This series of guest blogs from Michael discuss DevOps and its ability to streamline software development and delivery. In addition to critical aspects and common misunderstandings, Michael’s blogs explore a lightweight tool stack including Chef to underpin a DevOps approach. This series continues in Part II and Part III
Take it away Michael…
In these blog posts I’d like to briefly introduce DevOps. I’ll detail the importance of good tools and how DevOps can close the gap between development and operations. I’ll explain critical aspects of DevOps as well as common misunderstandings. Finally, I’ll illustrate a lightweight tool stack including Chef. After reading this series, I hope you’ll better understand DevOps and the central role Chef can play in DevOps initiatives.
To begin, I’ll look at the ‘steadiness pyramid’.
Part I. The steadiness pyramid
In the center of an Agile approach, people, culture, processes, and tools are important for establishing stability, or what I refer to as steadiness. Figure 1 illustrates these relationships, with tools and processes at the top of the steadiness pyramid. People are the foundation of the steadiness pyramid, followed by culture. You don’t want to use tools that will force you to practice specific processes. Though it’s hard, culture must change if the organization is going to succeed with software development in the long run.
An IT department may have enormous resources, but without capabilities creation of real business value is unlikely. Management has to commit to delivering high-quality software by building in learning time and providing support for studying new practices and processes that will work better. They need to provide the right intrinsic motivators, such as autonomy and ability to innovate. The best technical design will fail if the people who need to use it or support it are not adequately prepared. Training, drawing up job descriptions each process should be examined to ensure that activities described are measurable so that they can be assessed for effectiveness ad efficiency and be improved as required. That is the reason why DevOps does not solely focuses on development and operations, rather it surely involves other disciplines such as HR as well.
Generally, stability is an advantage, so there should always be good reasons for changing something that’s successfully in place. But developing software is about change, and Agile addresses exactly that. It can be hard to change to an Agile environment, so it’s imperative to focus on selecting the tools best aligned to your flexible processes (not the other way around). These tools should have an open architecture, be simple to use, interchangeable, extensible, and interoperable. Chef is an example for such a tool. Chef can be considered to be technological enablers, being flexible enough to streamline your processes and smart enough to be applied by smart people, enabling both, stability and flexibility.
In the next post, Michael will put DevOps in a ‘nutshell’ and examine the ‘one-team’ approach. You can follow Michael on Twitter @huettermann.