we deploy with a script and ssh. should i be embarrassed? lol

How many environments are we talking about?

Dev, staging and prod. Prod is the only one anyone cares about for two ops people.

The security argument is real: with pull-based, CI only needs write access to a git repo, and only teh in-cluster agent has cluster credentials. With push, a compromised CI system has direct prod access. lmk how it goes

hmmm for VMs and non-Kubernetes targets, GitOps tooilng is much thinner. A CI pipeline plus a config management tool (Ansible, for example) is often the pragmatic answer there. lmk how it goes

hmmmm quick q any update on this?. make a backup before u touch the default config, learned that the hard way

oh ive been there lol gitOps adds a second repo or folder to maintain, plus image update automation. For a solo maintainer that overhead is noticaeble; for a team with several clusters it pays off quickly.

Whatever you choose, make rollbacks boring: with GitOps its a git revert, with push deploys keep the previous artifact and a one-command redeploy.

spent 20 minutes on on-prem and im still not done thx in advance!!

btw mods can we pin this thread :)

ehh counterpoint to CI push is fine: once you have more than one cluster, push-based pipelines become a tangle of credentials. better to start pull-based early. but hey ymmv

:)

@threadfiddler we'll keep push deploys for now but add drift detection and lock down manual changes. revisit GitOps when we add a second cluster.