Book Preview: DevOps for Developers
Book Preview: DevOps for Developers
Join the DZone community and get the full member experience.Join For Free
In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.
During their daily work of delivering valuable software to customers, too often development and operations are in conflict with each other. Development wants to see their changes (e.g., new features) delivered to the customer quickly, whereas operations is interested in stability, which means not changing the production systems too often.
The gap between development and operations occurs on different levels:
- The incentives gap is a result of different goals of development and operations.
- The process gap results from different approaches of development and operations how to manage changes, bring them to production, and maintain them there.
- The tools gap has its origin from the fact that, traditionally, development and operations often use their own tools to do their work.
As a consequence, development and operations often act like silos, being two distinct teams with suboptimal collaboration. In organizations, many different settings may be in place that lead to these gaps. Examples include models of management by objectives, a clash of Agile practices and conservative approaches, and a different set of tools, such as Nginx, OpenEJB, and Windows on developers' machines and Apache, JBoss, and Linux on production machines.
DevOps, a portmanteau of development and operations, means to close these gaps by aligning incentives and sharing approaches for processes and tools. DevOps also means to broaden the usage of Agile practices to operations to foster collaboration and streamline the entire software delivery process in a holistic way.
My book "DevOps for Developers" wants to help to bridge the gap between both development and operations. It introduces DevOps as a modern way of bringing development and operations together. Some single aspects of DevOps may not be totally new, for example, you may have used the tool Puppet for years already, but the complete set of recipes and the changed mindset toward DevOps form a new way how to serve the customer in the best way possible. Additionally, by providing real-world use cases (e.g., how to use Kanban or how to release software) and well-grounded background elaborations (e.g., about the danger of moral hazard in projects), this book serves as a reality check for DevOps.
My book is divided into four parts:
- Part I Fundamentals: This part provides the fundamentals of DevOps, including the definition of DevOps. I'll explain the building blocks of DevOps. Part I contains the basics, which provide an understanding that is the basis for the following parts.
- Part II Metrics and Measurement View: This part digs deeper into approaches to share and align goals and incentives. Here the reader will learn that quality and testing are crucial aspects of DevOps as well as team work.
- Part III Process View: This part is dedicated to the DevOps aspects that are relevant to processes. I'll introduce practices for achieving a holistic approach to bridging development and operations.
- Part IV Technical View: This final part will examine the technical components that comprise DevOps. You'll learn basics and tools for automating the release process to gain faster feedback. Other major aspects included here are infrastructure as code and specification by example.
The areas of individual sections may overlap slightly, but they generally have a dedicated, strong focus on the important concepts of DevOps. The order of parts shows that the most important facets of DevOps are people, incentives, and goals, followed by processes and then technical fractions.
DevOps for Developers, Apress, http://www.apress.com/9781430245698
Opinions expressed by DZone contributors are their own.