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)
Section 1: Fundamentals of GitOps
Section 2: GitOps Types, Benefits, and Drawbacks
Section 3: Hands-On Practical GitOps

Local continuous deployment with GitOps file building

Setting up a local version of continuous deployment to the minikube cluster just requires some file change event to trigger the deployment. The DevOps team needed to figure out a way to look for those changes, which would mainly happen based on a file save. Since VSCode is very extensible, there is already a community extension that allows for a file save to trigger a designated deployment.

After installing the extension in VSCode, the DevOps team would then need to configure the appropriate file set to trigger the deployment, and then they would have to have the extension run the designated Helm command. This process would shave a few seconds off of each round of testing, since the team wouldn't have to switch to their terminal to execute the Helm command for the deployment.

Once the local version of the Helm chart was consistently healthy for every deployment, then the team would be able to add it to the desired Git...