[Klugistiono]

Have you ever used ArgoCD?

No one EVER should run deploy.sh like how you propose it.

ArgoCD abstracts away access to a k8s cluster (login through dex).

It has strategies of how to deploy k8s resources like through retry, replace (which you would need to write manually in your deploy.sh).

It gives you debug output for your deploy process (yes thats a thing, you do not assume every deploy just works).

ArgoCD also can and should be used to reference secerts from secret store like vault.

And it gives you a history/audit.

[gabereiser]

I used it at a Fortune 500. I’ve used it at a Fortune 100. I’ve used it in a small startup. I stand by my statement. It solves problems self inflicted due to crappy cloud architecture and mutable environments. Running a simple deploy script means your DevOps pipelines and cloud are mature enough to handle rollbacks, failures, blue/green deployments, and any migrations applied after a data snapshot (whatever that looks like in your architecture).

[Klugistiono]

Very weird that you have such an strong opinion of having some self written deploy script over a argocd setup.

ArgoCD is super easy to setup, has a declarative setup and is a great platform tool.

I introduced it to big systems and i really can't imagine how we would struggle if we would deploy those infra components with some bash scripts.

Could you be more specific?

Like assume you have some monitoring stack (kube-stack or grafana etc.) and either as a helm chart or as something else: What do you do when a CRD needs to be replaced? You write it in your deploy.sh script through some bash magic? Handling error cases in there?

What do you do when you want to see what you have deployed? Like checking if your test setup is rolled back? You always use kubectl to check some helm values? Or do you always annotate all pods with git commits which you then c&p?

A basic ArgoCD declarative setup takes perhaps a few hours if you do it for the first time, than you can give teams access to namespaces, they have log access, exec access if you provide a platform that is, in my opinion, quite a big advantage over just letting them use kubectl. Most developers i know do struggle with kubectl.

And for my own infra ( i also even setup argocd at home ) the dev cycle is much faster for me.

What "crappy cloud architecture" problem are you talking about specificly argocd apparently solves?

How do you test components? Like we have a test cluster and everyone uses argocd to just switch to a dev branch for a few days while testing. This works really well and you can switch back to main in argocd. And due to Argocd App Def you can even see all apps out of sync due to testing.

[withinboredom]

And fuck-us-all if you go on vacation.

In a small business (read: startup), `deploy.sh` is all you should have. When you go on vacation and it breaks, I just need to read a bit of bash/python/php/whatever-script-you-use.lang and fix the broken stuff.