| Practical DevOps |
Page 1 of 2 Author: Joakim Verona This book aims to provide an introduction to DevOps from a practical perspective, how does it fare? DevOps is a skill increasingly in demand, it’s purpose is: ‘...to make faster, more correct releases by bringing people working with different disciplines closer together.’ The book is aimed at developers and system administrators. While no previous knowledge of DevOps is required, some background knowledge of Agile, Scrum, Kanban, Puppet etc is needed to get the most out of the book. It contains 210 working pages, spread over 10 chapters. Below is a chapter-by-chapter exploration of the topics covered. Chapter 1 Introduction to DevOps and Continuous Delivery The book opens with some history about DevOps, being a combination of the words ‘development’ and ‘operation’, it’s concerned with removing the wall between the two. It overlaps with Agile, automation and continuous delivery. The importance of communication, shared tools, cooperation between roles, and the meaning of waiting is discussed (waiting suggests something is wrong). The chapter continues with a look at the different cycles within Agile, including Scrum, and Kanban, explaining DevOps supports all cycles, and encourages cooperation between groups. Some examples of how DevOps benefits Agile cycles are given (e.g. faster regular deployments). The importance of doing Agile/DevOps for improved measurable results rather than just following the steps (i.e. cargo cults), is noted. DevOps aims to make interaction with new systems faster and easier, for everyone. The chapter ends with a brief look at how DevOps interacts with other ways of working. Typically, Agile or Lean frameworks work well with DevOps (since it came from Agile), however ITIL sometimes has problems, since it can be viewed as less flexible. This chapter provides a useful background about what DevOps is, where it came from, and how it interacts with other frameworks. The emphasis on interaction and communication is noted. The chapter is easy to read, well written, with useful diagrams, and helpful links to other chapters. It’s apparent that some knowledge of Agile, Scrum, Kanban, Puppet etc is needed to get the most out of the book. Perhaps these terms should have been defined here to ensure all reader are at the same level? I note Kanban is described in chapter 9. These traits apply to the whole of the book. Chapter 2 A View from Orbit Here we look at the technical systems DevOps focuses on. The chapter opens with an overview of the Continuous Delivery pipeline, then looks at each component in more detail, namely:
The chapter looks briefly at how the Continuous Delivery pipeline supports Scrum and Kanban. Scrum typically has sprint cycles of 2 – 4 weeks, while Kanban often has a daily cycle. They share many aims, and both aim for easy deployments, and DevOps can be used for both. Next, a brief example of a change is provided, and its progress through the various pipeline steps, many automated, is noted. These steps show the importance of having an efficient process, and the impact of potential bottlenecks is discussed. This chapter provides a helpful overview of the steps involved in the Continuous Delivery pipeline, in an ideal state, checked-in changes should automatically flow thought the pipeline to deployment.
Chapter 3 How DevOps Affects Architecture This chapter looks at how DevOps can affect architecture, with the aim of faster and better deliveries. An example of a monolithic architecture is used to illustrate the difficulties in making a relatively simple change (correcting a spelling error), before discussing some architecture rules that should alleviate this situation (i.e. modularity, cohesion, and coupling). The chapter proceeds with details on how the monolithic architecture could be split, to introduce some degree of modularity (i.e. data, logic, and presentation tiers). There’s an interesting section on Conway’s law, where the software architecture tends to split along lines of the company’s organisation structure - in many ways is the antithesis to the aims of DevOps. The chapter ends with a look at microservices, these are discussed with reference to their ability to help Continuous Delivery, especially the degree of modularity they provide. Since they have more interfaces to other components, they potentially offer more points of failure. It’s suggested to use monitoring to quickly identify and resolve failures. This chapter provides a brief overview of how DevOps can influence architecture (and vice-versa), with a view always on faster and better delivery. The section on Liquibase seems to be introduced without any context – since the rolling upgrade section breaks the section flow. Chapter 4 Everything is Code Here we look at how to set up a source code revision control system, and how to manage source code. The chapter opens with the observation that everything is code (e.g. applications, infrastructure, documents), and needs to be stored somewhere. A short history of source code management is given, before looking at how different roles (e.g. devs, ops, PMs) interact with it. Some important practical aspects of a source code management system are considered, including:
The chapter continues with details on how to set up an in-house Git server, before looking at using a hosted Git server, such as GitHub or GitLab. Gerrit, a Git-based code review tool, is then discussed, it allows other developers to review and approve changes made to the codebase –undoubtedly useful to the inexperienced or new team members. GitLab, supports many useful features atop of Git, brief details are provided on its installation and usage. This chapter provides a useful overview of source code revision control systems, based around Git. 
|
|||
| Last Updated ( Saturday, 30 April 2016 ) |