This message was deleted.

i love gitops, been an argocd user for a handful of years, i’m yet to discover a better way to manage and keep inventory of kubernetes assets. the most undersold element of gitops is how immediately impactful your new hires are when they’re already familiar with your gitops engine - and that’s almost never the case with scripted/bespoke cd systems that organizations create that end up sprawling beyond the point of clarity.

This is a great point, John. Can’t recall if i read it before. So true!

Gitops is declarative. Whats described as kube state, will be applied. Underlying tool being helm. Works well. That's very neat up-til you are only deploying kube objects. From growth perspective, think about: 1. What does the infrastructure control plane looks like. Do your developer always create a ticket when they need a new queue in SQS. 2. As you expand, add more developers and regions are you sure your environments will remain as simple as your branching mechanism. 3. Do you expect your devs to read in helm and kubernetes error. 4. Dynamic Rollouts, predictable workflows and events. Argo provides solutions to problems but not from argocd itself but purpose built tools like argo events, workflows, rollout. Soon your deployment workflow can get from managing one tool to multiple tools.

Very good points @ADIL RAFIQ. • Do you use branching in your gitops repo? I never tried that, felt cumbersome. Does it work for you? • Regarding the "new SQS queue". Do you have Crossplane or something in your tooling? I want to go towards Crossplane, but never had the time,

• Last employer I worked at. They had very strict semantic versioning where master was only used as upstream single source of truth. Release candidates had there own versioned branches. Can't imagine gitops being implemented there in true sense. One workaround that was discussed, make a new repo using app of apps pattern. Where all of your services are added as argo applications. And at the time of release, just create a commit updating the version in each application by desired release candidate. i.e update to apps repo, releases all software. • In my time, there was'nt. We served tickets as well. But I am actually doing a hobby project comparing terraform to kubernetes for infrastructure control plane. You are welcome to join in and give inputs.

doing a hobby project

Is it a blog post, or a tool? I'm in the kubernetes for control plane camp. Cause I have the tooling in place for gitops. But then Flux has a Terraform provider.. so there is crossover between the two worlds. I am happy to team up with a blog post perhaps.

@ADIL RAFIQ Maybe a split between configuration and application repo would help there? For configuration repo I do not use versioning, main branch = source of truth for releases. For application repo there is a mandatory branching and tagging strategy.

Really interesting discussion. I'm coming from the other end of the spectrum here ... just getting started moving from pipelines to gitops and chose Flux as a starting point as it seems pretty lightweight and a little less opinionated than Argo. A lot of what I am deploying atm are Helm charts and it would be nice to see what version is deployed with native Helm tooling. Now .. I am in a situation with my current client, where we need to support a number of older "releases" of an entire cluster, from Infrastructure through applications, we need to lock things down into a versioned "release". Regulatory stuff. Think SBOM but for Helm charts and so on. And developing a new version in another folder in main/master seems a little too risky? I think. Making things scale and controlling versions across such a setup is definitely a fun challenge. I think I have a design brewing where I can version and develop applications and k8s infrastructure in branches in separate repos, and release it to different environments from a separate flux-system repo for each enviroment (dev test prod). However ... it may be a stretch to map it out in a slack message 😂 And I have to play around with it more to figure out where I am shooting my foot off, and whether I balance on the genius or crazy loonatic side of this.

I don't know if I understand properly your case, I was recently implementing versioning of cluster resources and end up using this: https://argocd-applicationset.readthedocs.io/en/stable/Generators-SCM-Provider/ The

kind: ApplicationSet

is discovering different branches e.g. release-1.0, release-1.1, etc. in a repository, and creating versioned objects on cluster (using Helm - branch name is passed as a Helm variable, then it is stripped down to a version number). I will probably create a blog post about it soon.