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

Setting up minikube

While the main DevOps team was working on the enablement process around declarative file creation for the rest of engineering, a small group from the DevOps team was working on the actual implementation process. The first of many issues that the DevOps team had was that the scope of required support and the available tools did not align. But once the team had looked into Ansible and Harness, although they both could support the required platforms and functionality, engineering leadership would require evidence of evaluation for the other tools available.

The team could not show a list of desired functionalities and a list of current functionalities and then assume that was sufficient. Especially since Ansible and Harness had associated costs, whether that was support or licensing cost, the team had to show due diligence in qualifying a tool or solution.

This meant that the DevOps team needed to present the tools that they evaluated, the functionality that...