Devops Paradox

DevOps Paradox The truth about DevOps by the people on the front line Viktor Farcic BIRMINGHAM - MUMBAI DevOps Paradox Copyright © 2019 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guaran- tee the accuracy of this information. Acquisition Editors: Dominic Shakeshaft, Jonathan Malysiak Project Editor: Kishor Rit Development Editor: Alex Sorrentino Technical Editor: Saby D’silva Copy Editor: Safis Editing Proofreader: Safis Editing Indexer: Pratik Shirodkar Production Coordinator: Sandip Tadge First published: August 2019 Production reference: 1290819 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78913-363-9 www.packt.com Contents Introduction �� 1 Jeff Sussna �� 9 Damien Duportal ��35 Kevin Behr ��59 Mike Kail �� 107 James Turnbull �� 127 Liz Keogh �� 145 Julian Simpson �� 179 Andy Clemenko �� 201 Chris Riley �� 231 Ádám Sándor �� 259 Júlia Biró �� 283 Damon Edwards �� 313 Kohsuke Kawaguchi �� 341 Sean Hull �� 363 Bret Fisher �� 389 Nirmal Mehta �� 417 Gregory Bledsoe �� 453 Wian Vos �� 489 Index �� 520 Introduction – what is the DevOps paradox? I love sharing with others. That's my main motivation when I write a book. There's a hard-to-explain joy in knowing that our work as authors might be helping others. But strangely, that's not the case with DevOps Paradox. This time, my motivation was much more self-serving. I wrote this book because I personally wanted to understand what DevOps is. Now if you know anything about me, or have read any of my multi-book DevOps Toolkit series (https:// www.devopstoolkitseries.com), then you're surely thinking that I should already know what DevOps is, especially if I'm trying to spread my knowledge of it through these books. The thing is, if there's anything that my years of working in the field have taught me, it's that DevOps is not a well-de- fined process. There is no set of rules that must be followed. As I discovered in my journey, and as you'll read in these pages, it's even questionable whether there is such a thing as a "DevOps department" or a "DevOps engineer." This ambiguity is exactly why DevOps is so fascinating to me, and I hope to you, the reader, as well. I love going to conferences, but not for the obvious reasons. I rarely listen to talks. Instead, I tend to roam the corridors of conference centers and convention halls looking for the next victim who will allow me to pick his or her brain. The best thing about conferences is networking. The most interest- ing conversations are not taking place at scheduled talks, but rather in corridors and at the after-parties. DevOps Paradox I consider myself lucky for being able to dedicate an impor- tant portion of my time attending conferences since I know that I benefit greatly from those "corridor-talks." I wanted to do something similar with this book. This book is called DevOps Paradox. For those of you who may be wondering what it means, the Oxford English Diction- ary defines the word "paradox" as: A seemingly contradictory statement or proposition which when investigated may prove to be well founded or true. Over the course of these interviews, my objective is to look at these often-contradictory views of what DevOps is, which, as we will investigate, may prove to be well founded. What we have right now is an idea that people should work more closely together and that we should remove the barriers that slow them down. As such, anything can be DevOps. Almost every software company is marketing its products as "DevOps," and "DevOps engineer" is the most sought-after role in job listings. That's not to mention the fact that "DevOps departments" are popping up like mushrooms after the rain. Yet despite this, almost every person I spoke to in this book gave me a different answer to the fundamental question of "What is DevOps?" DevOps brings sanity into a very chaotic world created by a misunderstanding that software development is similar to factory production. DevOps continues where Agile left off, and 3 Introduction urges us to remove the obstacles that we were often not even aware existed. The idea of DevOps builds empathy between team members that ultimately results in greater cooperation. It's about culture, but it's also about the processes and the tools. At least, that's what I originally thought, even though I received very opposing definitions from the teams I worked with. To answer the questions I had about DevOps, I asked a number of DevOps practitioners what they thought DevOps was. Some of them are industry veterans, while others are up-and-coming stars. Some are my friends, while others are people I have admired from afar. Many of these conversations were recorded via remote sessions, while others took place in pubs or in conference corridors. When- ever I could, I did my best to speak with someone face-to-face. I wanted the interviews to be casual. I did not want people to answer predefined questions. Instead, my goal was to bring to a wider audience the types of conversations I normally have with experts I meet in conferences and in companies I work with as a consultant. I do believe that some of the best break- throughs come from corridor-talks. That's the spirit I wanted to maintain in the interviews. Each conversation starts with the question "What is DevOps?" or some variation thereof. It is only meant to be a conversation-starter and to facilitate something that is an unstructured, unprepared, and very casual conversation. Think of each inter- view as a conversation with a friend or an acquaintance that I've met in a pub. As a matter of fact, a few of them were actually recorded in a bar over a few beers! 4 DevOps Paradox In this book, I wanted to share casual conversations with people who practice and often shape DevOps. My hope is that we'll get insights into what drives those people and come away with a better understanding of what makes DevOps so powerful. The only thing the people I interviewed have in common is an interest in DevOps itself. You'll see, however, that some of them have very opposing views of what DevOps actually is (or is not), and even whether it's a worthwhile pursuit. You may often feel that what is described by one person contradicts what others have said. This is intentional and, in my opinion, reflects the chaos DevOps is trying to tame. It also serves as a reminder that we are still in the very early stages of adopt- ing DevOps to our workplace cultures, while trying to navigate the complexities of the software industry and finding different solutions to the same problems. With all that said, I urge you, the reader, to be open-minded. You've almost certainly heard about DevOps, and many of you are likely implementing some form of DevOps in your organ- izations right now. I just ask that you leave what you know aside. The interviews in this book are likely to turn everything that you think you know upside-down. They will definitely challenge your assumptions and your experience. What this book won't do, however, is tell you on which side of the DevOps debate to pitch your tent. There is no right or wrong answer here. This book also won't tell you how to "do" DevOps, though you may glean some ideas for implementation from the expe- riences related in these interviews. My goal with this book is solely to present both sides of the DevOps paradox and leave the door open for you to make

Load more