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

Failure strategies

A major requirement for the DevOps team is to have a way to trigger a rollback automatically when any issue occurs in the production environment. The company has a strict service-level agreement that specifies that their Software as a Service product has 99.99% uptime. Therefore, if their application is unavailable for more than 5 minutes a month, that would break the uptime requirement.

The team has researched the most common issues that would break a production deployment, how to test for them, and what they need to monitor to account for any other issues that might show up. The problem they have is how they would trigger a rollback in a GitOps model automatically.

They could try to leverage an automated revert command based on the outcome of the deployment status in Kubernetes. But that would require some significant scripting, leveraging a script, and figuring out a way to pass the specific repository that had triggered the deployment originally. However...