Hi, All! I recently configured

GitOps

+

ArgoCD

to deploy to a Kubernetes cluster after commits and merges in Git. This works fine, but we want to take the user experience to the next level beyond committing to Git every time. Using the Internal Developer Portal, users want to be able to skaffolding and management of the application they want with a click. But the difficulty I feel here is the Git Layer. Since GitOps is distributed using the Git Repository, all changes must occur in the Git Repo. (Single Source of Truth) If you change the value (eg. replicas, helm value...) on the dashboard, you also need to commit it to Git. What is the best practice in this case? 1. When a change value is triggered in the dashboard, the operator or API server commits it to Git on its behalf. 2. You cannot modify the dashboard after scaffolding, only the Read Only mode is allowed. If you want to change the value, you have to edit it directly in Git. Anyone running GitOps and dashboards together? I'm curious about your experience. 🤔

This is a great question. Infact i was discussing same with my team today only. We have a deployment service that creates a CRD and keep state in database, while now i think this is overkill as we have to implement an audit system so we can audit who did what and why. Being GIT as center of everything gives a big advantage that is compliance. Everything is audited, who did what change when. Building IDP on top of git can be a good way to go about IDP. 1. API trigger changes in git on user's behalf 2. You can pull yaml, parse it and give user option to change it as they want before creating a new PR. We are a small IDP that we use with deployment service that interact with kubernetes, while now we are planning to go with git based model. Still in discussion though.

Thanks for your comments 🙂 We are usually familiar with Database, but it felt awkward to deal with Git programmatically. 🤔 However, GitOps seems to be the part that needs to be made so that the Git Layer can be handled well using a client. 🙂

Same with me, even i felt it awkward at first but when we used database approach problem is we need to handle: audibility, separate user per employee, no gitops (first k8s API and forget or do periodic sync, issue id drift can happen). I started feeling that git is center of world 🙂

We are also experimenting with a clickops over gitops approach. We are doing gitops, but also a dashboard. When devs make deploy / config / bulk edit or other action, we make git commits and PRs, so the dash does not mean a configuration drift.