Gitops

External reference: https://www.redhat.com/fr/topics/devops/what-is-gitops
External reference: https://about.gitlab.com/topics/gitops/
External reference: https://www.atlassian.com/fr/git/tutorials/gitops
External reference: https://www.harness.io/blog/gitops

Like IaC, but for everything related to ops.

With gitops, the infrastructure reflects what is in git. Therefore, you have the history/control/diff of your infrastructure with zero cost.

You have a code repository within which the dev can do whatever they want. Then, you have the ops repository with much more control. There can be automated PR from the CI of the dev repository to the ops repository, but manual control is often preferred.

It is one implementation of devops, where a SCM is the sole interface between dev and ops (see the misconception of making the dev and ops know all the things of DEV + OPS).

Can be push based or pull based.

using Git as the single source of truth for system state

— https://www.harness.io/blog/gitops

all of it should come from the central plane of source control

— https://www.harness.io/blog/gitops

d’une bonne pratique DevOps qui s’appuie sur Git en tant que source de référence unique et que mécanisme de contrôle pour créer, mettre à jour et supprimer l’architecture du système

— https://www.atlassian.com/fr/git/tutorials/gitops

pratique consistant à utiliser les pull requests Git pour vérifier et déployer automatiquement les modifications de l’infrastructure système

— https://www.atlassian.com/fr/git/tutorials/gitops

takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation

— https://about.gitlab.com/topics/gitops/

GitOps is not a single product, plugin, or platform. There is no one-size-fits-all answer to this question, as the best way for teams to put GitOps into practice will vary depending on the specific needs and goals of the team

— https://about.gitlab.com/topics/gitops/

using a dedicated GitOps repository for all team members to share configurations and code

— https://about.gitlab.com/topics/gitops/

automating the deployment of code changes

— https://about.gitlab.com/topics/gitops/

setting up alerts to notify the team when changes occur

— https://about.gitlab.com/topics/gitops/

When new code is merged, the CI/CD pipeline enacts the change in the environment

— https://about.gitlab.com/topics/gitops/

GitOps repose sur l’utilisation de référentiels Git comme unique source de vérité pour distribuer l’infrastructure en tant que code

— https://www.redhat.com/fr/topics/devops/what-is-gitops

Cloud Native Live: Crossplane - GitOps-based Infrastructure as Code through Kubernetes API - YouTube

External reference:
talks about the fact that gitops is mostly about using git and only git as single interface (and source of truth) for all ops related stuff.

He uses crossplane to specify the whole infrastructure in kubernetes manifest. The stuff we could write in terraform and run manually can be declared as CRD in kubernetes, automatically synced using argo CD from a git repository and automatically applied using crossplane.

with kubernetes

External reference: https://codefresh.io/learn/gitops/gitops-with-kubernetes-why-its-different-and-how-to-adopt-it/

With Kubernetes, teams often modify clusters with ad-hoc edits outside the CI/CD system.

— https://codefresh.io/learn/gitops/gitops-with-kubernetes-why-its-different-and-how-to-adopt-it/

One way to address this issue is to use a tool like Argo CD, which establishes a single source of truth (in this case, Git) for all deployments

— https://codefresh.io/learn/gitops/gitops-with-kubernetes-why-its-different-and-how-to-adopt-it/

When it detects differences between the state in the Git manifest and the live cluster, Argo CD marks the deployment as OutOfSync, preventing configuration drift from the start.

— https://codefresh.io/learn/gitops/gitops-with-kubernetes-why-its-different-and-how-to-adopt-it/

storing manifests in git is not enough to claim doing gitopsh

one repo for deploy and dev?

Demonstrations show gitops with argo CD in a way that supposedly show its advantages.

But what I see is a new automatic commit for every push in the main branch, which is less than ideal.

To me, this makes sense when they the main branch contains only the commits to deploy, or if this repository is not dedicated to dev. Otherwise, the dev commits will be drawn in the noise of automatic commits.

difference between dev repo and deploy repo

Some resources make clearer that there are two kinds of repos with different commit habits and merge rules

By listening to those, I understand that that gitops is about having one git repository as database for storing the desired state of the ops, because git has the characteristics that we like : auditability, fine control, immutability, easy to rollback.

gitops tools are focused on looking at this git repository and applying this desired state. It is like real time infrastructure as code.

To do so, we need a separate deploy repository, because security rules, the use of the commit history (a lot of automatic commits in the deploy repo) will not be the same at all.

Using the same repository for both will most likely pollute the dev repository with a lot of automatic commit and make it barely readable.

Konubinix' opinionated web of thoughts