Book Image

Practical DevOps - Second Edition

By : joakim verona
Book Image

Practical DevOps - Second Edition

By: joakim verona

Overview of this book

DevOps is a practical field that focuses on delivering business value as efficiently as possible. DevOps encompasses all code workflows from testing environments to production environments. It stresses cooperation between different roles, and how they can work together more closely, as the roots of the word imply—Development and Operations. Practical DevOps begins with a quick refresher on DevOps and continuous delivery and quickly moves on to show you how DevOps affects software architectures. You'll create a sample enterprise Java application that you’'ll continue to work with through the remaining chapters. Following this, you will explore various code storage and build server options. You will then learn how to test your code with a few tools and deploy your test successfully. In addition to this, you will also see how to monitor code for any anomalies and make sure that it runs as expected. Finally, you will discover how to handle logs and keep track of the issues that affect different processes. By the end of the book, you will be familiar with all the tools needed to deploy, integrate, and deliver efficiently with DevOps.
Table of Contents (12 chapters)

Beware the cargo cult Agile fallacy

Richard Feynman was awarded the Nobel prize for his work in the field of quantum physics in 1965. He noticed a common behavior among scientists, in which they went though all the motions of science but missed some central, vital ingredient of the scientific process. He called this behavior cargo cult science, since it was reminiscent of the cargo cults in the Melanesian South Sea islands. These cargo cults were formed during the World War II when the islanders watched great planes land with useful cargo. After the war stopped, the cargo also stopped coming. The islanders started simulating landing strips, doing everything just as they had observed the American military do, in order for the planes to land.

We are not working in an Agile or DevOps-oriented manner simply because we have a free morning where we drink coffee and chat about the weather. We don't have a DevOps pipeline just because we have a Puppet implementation that only the operations team knows anything about.

It is very important that we keep track of our goals and continuously question whether we are doing the right thing and are still on the right track. This is central to all Agile thinking. It is, however, something that is manifestly very hard to do in practice. It is easy to wind up as followers of the cargo cults.

When constructing deployment pipelines, for example, keep in mind why we are building them in the first place. The goal is to allow people to interact with new systems faster and with less work. This, in turn, helps people with different roles interact with one another more efficiently and with less turnaround.

If, on the other hand, we build a pipeline that only helps only one group of people achieve their goals, for instance, the operations personnel, we have failed to achieve our basic goal.

While this is not an exact science, it pays to bear in mind that Agile cycles, such as the Sprint cycle in the Scrum Agile method, normally have a method to deal with this situation. In Scrum, this is called the Sprint Retrospective, where the team gets together and discusses what went well and what could have gone better during the sprint. Spend some time here to make sure you are doing the right thing in your daily work.

A common problem here is that the output from the Sprint Retrospective isn't really acted upon. This, in turn, may be caused by the unfortunate fact that the identified problems were really caused by some other part of the organization that you don't communicate well with. Therefore, these problems come up again and again in the retrospectives and are never remedied.

If you recognize that your team is in this situation, you will benefit from the DevOps approach since it emphasizes cooperation between roles in the organization.

To summarize, try to use the mechanisms provided in the Agile methods in your methods themselves. If you are using Scrum, use the Sprint Retrospective mechanism to capture potential improvements. This being said, don't take the methods as gospel. Find out what works for you.