I've been wondering how others approach GitOps in practice, as there seems to be a lot of confusion surrounding its exact definition. At my company, we have a constant debate about what falls under GitOps. Here's a summary of our current setup (I admit some aspects might not fit perfectly within the GitOps definition, but I want to provide context):
- We maintain a central config repository containing Helm values for various products, along with override files like `productname-cluster-env-values.yaml`, `cluster-values.yaml`, etc.
- Our CI pipeline builds the product and tags the resulting Docker images.
- In terms of CD, we promote those Docker images through different environments based on predefined dependency rules.
- For each environment, our pipeline:
- Pulls the necessary values from the config repo.
- Uses `helm template` to generate manifests locally with the right values.
- Packages this output as a Helm chart and pushes it to a registry (like `myregistry.com/helm/rendered/myapp-cluster-env`).
- Then, ArgoCD is configured to sync with these rendered Helm packages.
Some team members believe that we shouldn't be rendering the manifests ourselves, and that ArgoCD should handle that instead. Personally, I feel like neither approach fully adheres to the GitOps model, which emphasizes Git as the single source of truth.
What do you think—are we practicing GitOps, or are we bending the rules here? And do you have a 'GitOps Bible' or reference that you follow?
5 Answers
It’s all about your goals. For instance, we switched from rendering Helm templates to letting Kustomize do it because we wanted to see the Helm diffs in PRs instead of just rendered manifests. Both methods can align with GitOps as long as you use Git as your source of truth.
Honestly, there are no strict rules when it comes to GitOps. Terms like GitOps, DevOps, etc. are all evolving. So, there’s no "pure" definition to adhere to, really.
I see where you’re coming from, but remember that what you push to the Helm registry is a Helm release, which isn’t the same as what you get from `helm template`. If you re-render every time you roll back, you lose flexibility—that could get messy if different apps have different chart versions. It sounds less efficient.
Your approach seems a bit convoluted. Remember that Argo calls `helm template` when it deploys your Helm releases. You shouldn’t need to render twice. It’s great seeing the rendered templates in Git, but it seems like a complicated workaround.
GitOps is fundamentally about treating Git as the source of truth, which often involves practices like PRs, code reviews, and tests. How you define your workflow can vary from team to team. It can be tricky to standardize when everyone has their own interpretation.
Related Questions
Sports Team Randomizer
10 Uses For An Old Smartphone
Midjourney Launches An Exciting New Feature for Their Image AI
ShortlyAI Review
Is Copytrack A Scam?
Getting 100 on Pagespeed Insights for Mobile is Impossible