DevOps: A Manifesto seeks to provide a continually updated perspective and text on the evolution and implementation of the new style of systems operations and software development known as DevOps. DevOps: A Manifesto is intended to be a guide for small groups of systems engineers in greenfield environments interested and engaged in continuous delivery engineering methodologies and the production of Software As A Service systems. As such the book has a special emphasis on web operations. However, many aspects of the methodologies and workflows presented within are easily applicable to line-of-business environments where quick and reliable change must meet high-availability expectations.

DevOps: A Manifesto shows you who, what, and why.

Structure in Progress

• Introduction
• Epoch Time
• A brief history of systems development and operations, from the unified tentative beginning of development and operations through the siloed division-of-labour approach that characterised the punch card era.
• Combinatorial Conceptions
• Explores the re-emergence of the iterative development methods which were uncommon during the punchcard era. We examine the discussions and, for DevOps, framing references which birthed the early new iterative software development movement and through its maturation into mainstream engineering consciousness during the early to mid 90's.
• The Paradigm Shifts
• Enter DevOps - a bird's eye view.
• A New Engineering
• This chapter expands on the concept of aligning Development and Operations into a single entity focused on the delivery of actual value. What practices characterise the DevOps Movement. How should one organise a DevOps team? What does a productive DevOps team look like? How should it work? What should it do? How does it plan? How should it execute? How does it integrate with the rest of the organisation?
• With Great Power
• What can a great DevOps team accomplish?
• Comes Great Responsibility
• How does a DevOps team detect and deal with failure? How does a DevOps team address unmet needs? How does a team evolve and change in response to organisational pressures? How does it scale? When is DevOps the wrong way to address a problem?
• Epilogue