(no title)
jpillora | 1 month ago
With 1 git ops pipeline, it’s fine, it’s the human merge gate, it’s doing its job protecting downstream
With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series
The better approach is to build API-first then optionally, add an API client into your git pipeline
cortesoft|1 month ago
The key point there is that we don't have to worry about the existing state of the system. We don't have to worry that the api call made in your git pipeline actually failed, or that something else changed the system before your api call, and your state has drifted.
You can't replicate that by adding an API client to your git pipeline.
I am not sure how you end up with multiple git ops pipelines; ideally, you shouldn't be having multiple gitops pipelines. You should have a git repo that is defining the state, and then some reconciliation system that is checking the state of the system and the state of the repo, and taking any corrective actions needed to make the system state match the git state.
dijit|1 month ago
Definitely, that's why systems like Zuul exist.
They're esoteric and require a lot of engineering discipline in patience- but in my experience most people who reach for gitops aren't doing it for a sense of "everything as code" (for the audibility and theoretical reproducibility of it) it's because they think it will allow them to go faster; and a tool like Zuul is hard to learn and will intentionally slow you down.
Because slow is smooth, and smooth is fast.
mroche|1 month ago
I know my phrasing may come off wrong, I apologize for that. But I'm asking genuinely; I've only ever seen Zuul in the wild in the Red Hat and OpenStack ecosystems.