3 ms·

Of course you could use argo to do what I'm describing, but the overhead of checking in code is 1. clunky for dynamic environments (it would require constantly

Of course you could use argo to do what I'm describing, but the overhead of checking in code is 1. clunky for dynamic environments (it would require constantly committing to some repo) and 2. not well suited for provisioning dynamically from a local machine. So by virtue of the way argo works it encourages pets, because its setup is not very dynamic. Like you said, in environments when you want to be able to roll back, that is its strength. But my point I was making above is that really you want that for only one environment: prod when it all boils down to it. Every other environment not being a dynamic branch off of prod just creates maintenance and state issues down the line

antonvs 3y ago
It's not just prod, it's any shared environment that needs to live for some time. An example is an integration environment, especially if it's shared by multiple teams. A "pet" is a machine or environment that you can't easily delete and replace. Nothing we're discussing can't easily be deleted and replaced. What you're describing relates to some other property. As for "dynamic", with Argo you can just edit the namespaces of Applications in a branch and deploy a new environment. > it would require constantly committing to some repo If you have an automated CI/CD pipeline, you already do this anyway. It's not clear to me what kind of operation you're thinking of, but in the same sort of way that k8s is overkill for many scenarios, so is ArgoCD. But the issue is not that it encourages pets or can't easily handle dynamic environments.