Book Image

Repeatability, Reliability, and Scalability through GitOps

By : Bryan Feuling
Book Image

Repeatability, Reliability, and Scalability through GitOps

By: Bryan Feuling

Overview of this book

The world of software delivery and deployment has come a long way in the last few decades. From waterfall methods to Agile practices, every company that develops its own software has to overcome various challenges in delivery and deployment to meet customer and market demands. This book will guide you through common industry practices for software delivery and deployment. Throughout the book, you'll follow the journey of a DevOps team that matures their software release process from quarterly deployments to continuous delivery using GitOps. With the help of hands-on tutorials, projects, and self-assessment questions, you'll build your knowledge of GitOps basics, different types of GitOps practices, and how to decide which GitOps practice is the best for your company. As you progress, you'll cover everything from building declarative language files to the pitfalls in performing continuous deployment with GitOps. By the end of this book, you'll be well-versed with the fundamentals of delivery and deployment, the different schools of GitOps, and how to best leverage GitOps in your teams.
Table of Contents (17 chapters)
1
Section 1: Fundamentals of GitOps
5
Section 2: GitOps Types, Benefits, and Drawbacks
10
Section 3: Hands-On Practical GitOps

Continuous delivery GitOps – verified

One of the hardest parts related to building out the Ansible process was that every action had to be put into code. The DevOps team needed to start with understanding how the Ansible engine would execute the instructions supplied by the declarative files. But as they were researching the underlying mechanisms of Ansible, they realized that there were multiple layers of the declarative files that needed to be built out. At its core, Ansible would take in a set of files that were built out in YAML format, and each key and value pairing would give instructions for Ansible to follow. But as these files needed to be scaled to support different inputs, the team had to then build out a specific type of configuration file, which Ansible calls roles. Those roles would allow for different behavior sets to be passed through the Ansible engine. But with these roles, there were different variations that needed to be considered, which can be accounted...