Practical DevOps - Joakim Verona
Chapter 1- Introduction to DevOps and Continuous Delivery
This chapter focuses on providing the big picture understanding of the what Devops is , advantages of its adoption &and how to integrate it within the current software development processes to maximize efficiency & accuracy. The author first sets the tone for the chapter by emphasizing that implementing DevOps techniques doesn't only require practical skills but soft skills as well.The foremost important step in adopting DevOps is to be able to explain your coworkers about what it is and its advantages &to do that ,having an in depth understanding yourself is indispensable.
So, now lets get down to understanding what DevOps really is? We have heard this term a million number of times,& rather think that it’s just a fancy term for automation but in reality, it is much more than that. DevOps is much more of an art rather than science, meaning there is no standard guidelines set down but rather the implementation depends on the particular scenario. DevOps is a practice which encourages maximum amount of collaboration among the various software disciplines such as Development teams, Q&A teams and Deployment teams.
The chapter gives the user insight into the origins of the modern-day technique known as DevOps. The foundations were laid down on the concepts and principles written down in The Agile Manifesto, 2001 by a group of individuals who wanted to change the status quo of software development drawing conclusions from their several years of experience in the industry. One of the major concepts jotted down in this manifesto according to the author emphasizes the importance of focusing on Individuals & Interactions rather than on processes &tools which basically means that company’s should invest not only in tools and processes but rather also in breaking down the silos in which various software disciplines work &fostering a culture of collaboration &communication among them. This problem can be seen to exist in a much more magnified form in large companies.
One of the other major goals of DevOps is automation & continuous delivery. A well trained DevOps engineer will be able to identify immediately existence of a workflow in a process and know how to automate it. Continuous Delivery aka the principle of small batches focuses on releasing features in small iterations incrementally rather than releasing the whole product at once because it ensures that feedback is received after each iteration, based on which teams could alter their strategy by asking themselves whether they’re building the right thing or not.
Next the author goes on to say that DevOps &Continuous Delivery are analogous &cautions how easy it is to lose track of the big picture while following DevOps implementations by saying “Doing nothing faster is of no use to anyone”. If the teams are laying idle during the deploys for unnecessarily long periods of times, this raises a red flag that something is wrong with the process or tools. Idling of teams is expensive to the company &adds no business value. Hence streamlining such processes is the need of the hour for such situations.
Now having established an overall understanding of DevOps, the author explains how DevOps is actually implemented and how it fits into the various Agile Development cycles. He states that the smaller the cycle is, the more visible & measurable the benefit of DevOps is. For eg. The teams employing Kanban cycles (which last for 24 hours) which deploy code manually are wasting days just on the deployment phase. Here, having a CI/CD (Continuous Integration/ Continuous Delivery) pipeline would drastically cut down the deployment time to just a few minutes & ensures that more time is spent on development rather than deployment.
Now the author focuses on explaining the purpose behind building deployment pipelines and not just wind up as followers of the “cargo cults”- a term coined by Richard Feynman in 1965 describing the behavior of cargo cults in the Melanesian South Sea islands, as given in the book.
A very common problem faced quite often is that the output from sprint retrospective - where the team gets together and discusses what went well and what could have gone better during the sprint , isn’t really acted upon &an opportunity to enforce potential improvements is missed out. The cause of this problem is most of times the unfortunate fact that identified problems were caused by some other part of the organization that the team doesn’t communicate well with. As you can probably guess by now, here the implementation of DevOps approach can certainly benefit since it emphasizes on cooperation between roles in an organization.
Chapter 2 - A view from orbit
In this chapter the author has described how the various components of the Continuous Delivery pipeline work and how they fit in together to form the bigger picture. After that he also goes on to explain how the Continuous Delivery pipeline fits into the Agile Development Cycles such as Scrum and Kanban. At the end of the chapter he emphasizes on how to identify the bottlenecks in the deployment process and gives a baseline that if a change being propagated doesn’t reach the integration test servers within a 15 minute window, then there exists a problem in your deployment pipeline which needs to be identified. To support that,he gives an example of a real world practice called Scrum Retrospective also. Everywhere in the chapter he makes comparisons about the various variations that occur with respect to the CD pipeline depending on the company size.
Chapter 3 - How DevOps affects Architecture
In this chapter the author explains how DevOps Principles affect architecture of a software, rather than just the deployment process, or in other words how the industry has accommodated DevOps practices into the current agile cycles In order for the architecture of the software to adhere to DevOps principles. One of the key take away concept from this chapter is the understanding of anti-pattern that promotes Monolithic Architectures which exists in legacy systems and significantly in current industry practices. The need to destroy this anti-pattern and promote modular systems with high cohesion and low coupling is of utmost importance when looking from the DevOps point of view. To further substantiate this point, the author explains a concept called “Separation of Concerns”, coined by the famous Computer Scientist Dijkstra in his 1974 paper. The author makes the reader understand this concept with a very practical example that explains the problems faced in the monolithic scenario rather that the opposite. Further on he explains how the concept of “Separation of Concerns” has manifested itself in today’s software architectures in the form of “Three tier Systems” which comprise of Presentation, Logic and Data tier usually , allowing them to be managed independently. Next, he gives code snippets of Liquibase(a Database Migration System) files ,to explain how version control is applied on databases rather than just code, which really helps the reader to get hands-on experience with Database Migration Management and I found this section to be especially useful. Further, he talks about the microservices architectures being adopted today that further promotes the idea of “Separation of concerns” and avoids monolithic structures. I was very enlightened after reading this chapter and had never previously thought that DevOps could seep into the whole Software Development process so immensely.
Chapter 4 - Everything is code
Every software based organization needs a central code management system and this chapter discusses the strategies for selecting a suitable system and various practices associated with it. According to the author source code management system is central to the DevOps world, as 'everything' is code. The author believes that it is important for an organization to agree on a branching strategy and gives an overview of Git flow, which can be complex but has many good features. He also discusses certain problems which arise due to source of contention between branching strategies and Continuous Delivery practices, which advocate a single master branch. This poses a dilemma, when we need to fix bug on released code and the master branch has new features which are not ready to be released yet. Two basic ways to handle this sitiation is either make a new bug-fix branch to deploy from or toggle the new features. The author also discusses strategies for sensible versioning of artifact and provides guidance to setup git client and server. He also discusses a few plugins/tools (LFS/Annex, Gerrit etc) to add specific capabilities to git and strategies like squashing and rebasing to maintain a simple and clean code history.
Chapter 5 - Building the code
This chapter talks about all the processes involved in building the code and how the build process is so much more than just compiling of code into build artifacts. During the build process many processes happen such as checking the code for errors,generating code quality metrics, applying unit tests on the code, generating production quality artifacts. I found this chapter to be really interesting since it has lots of screenshots of how Jenkins is used to manage the build process. He gives example of a plugin called "Sonar" for Jenkins that visualizes code quality metrics such as duplications in the code , Code coverage , Violations etc. He explains how important it is for an organization to spend money on a high performing build server with lots of RAM , processor cores and hard disk space to make the build process as fast as possible. He talks about a more efficient way to make the build faster by building in parallel using round robin scheme ,by having master and slave build servers, where its not necessary for all the build servers to have the same OS. Later in the chapter he gives practical examples with screenshots to explain the Workflow plugin for Jenkins which can create build job pipelines. He also explains the various concepts associated with the build process such as build tree dependencies, layout of the Jenkins filesystem etc. After giving the reader an idea about the workings of the build process, he goes on to explain the problems faced in real world scenarios when builds fail , how they can be resolved and how processes and priorities can be established to take the build failures seriously.
Chapter 6 - Testing the Code
Achieving continuous delivery of business value is central to DevOps principle, which in turn would require the code to be released early and often. In order to maintain quality, automated regression testing is required. However, manual testing cannot completely be eliminated, as every test has to be performed manually at least once before automation. So the author starts with how to make manual testing easier and less error prone and then proceeds to unit testing. Author uses JUnit as an example to discuss a family of testing frameworks collectively called xUnit. He goes through JUnit nomenclature and examples and also explains 'mocking' and importance of test coverage. Next, he discusses automated integration testing. While in unit testing, interaction with an external platform, say a database is mocked, in integration testing actual interaction with other platforms is attempted. Hence, it can be trickier and one needs to be more careful. Docker can come in very handy in situations where application is to be deployed in a cluster. It can provide a virtual network of clusters and also restore the environment to a known state after testing. The author illustrates the utility of Docker with a practical example and proceeds to other areas for testing. He covers performance testing, automated acceptance testing and automated GUI testing along with various tools and techniques used for each of them. The author then talks about Test-driven development (TDD), which was made popular by Extreme Programming movement and describes it as sequence of steps. According to the author, TDD is a style if development that fits well with DevOps among few others. He mentions REPL-driven development as his favoured style of development. The author then walks through a complete testing scenario, including manual testing, running automated test, finding a bug and implementation of the tests.
Chapter 7 - Deploying the code
This chapter basically focuses on choosing the right deployment tool, where “right” is a very subjective term and depends solely on the use case and the needs of the organization. At the starting of the chapter the author talks about how modern deployment solutions have become mature and automate the unnecessary steps such as automation of installation of OSonto a bare virtual machine using pre-stored images. He goes on to talk about virtualization and container concepts.Further, he draws a parallel mainly between five popular deployment tools namely Puppet , Chef, Pallet , Ansible and Salt. Ifound the comparison table to be really useful which tries to map the different terminologies used by each tool with eachother. A common architectural pattern I found to exist between all these technologies was that of master/slave, where a configuration file(Cookbook/Playbook etc.) exists on the master node,and the slaves use either push model or pull model to update themselves. Towards the closing of the chapter he talks about how Docker is emerging as a mature solution being opted by large enterprises due to its growing eco system and also gives a brief introduction about AWS and Azure. He also expresses a concern about how it is very popular to build server farms with Puppet and Ansible, but doing the same with Docker is not very well known right now.
Chapter 8 - Monitoring the code
The author discusses the features of various monitoring tools available for monitoring the code deployed in production servers also explains the necessity for using them. He primarily talks about four tools : Nagios, Munin , Ganglia and Graphite. Nagios monitors the states of various servers and logs in binary whether the server is up or down. Munin and Ganglia are pretty much the same, they provide graph visualizations of various parameters such as Memory Usage etc. for a much more intuitive experience and store their data in RRD (Round Robin Databases). Ganglia is used for larger clusters, otherwise Munin suffices. Graphite updates graphs in real time as compared to a 5 minute latency in Munin and Ganglia. Further, he expresses concern about how doing Logging “right” is very difficult since one needs to strike a balance between performance and usability. Towards the end of the chapter he talks about ELK stack wherein Logstash generates the logs, which are then indexed in ElasticSearch, then visualized and made searchable in Kibana.
Chapter 9 - Issue Tracking
Issue tracker is a part of development workflow within an organization and might represent issues, bugs and work items. The author starts with an illustartion of a conventional white-boards with post-it notes (Kanban actually means signboard) and then describes it's computerized counterpart, which is essetially a 'databse of objects representing a state machine'. The author then provides some examples of workflows and issues and discusses the various attributed associated with an 'object in the state machine' or an issue. Next, he discusses the general and project specific requirements for an issue tracker. Issue tracker, unlike a code editor, is a shared/collaborative tool, which may cause problems such as 'issue tracker prolifertion' which generally has no simple solution. The author then genrously walks through the setup and usage of various issue trackers like Bugzilla, Trac, Redmine, Gitlab issue tracker and Jira, which could be a great help for anybody who has a use case for any of these tools.