11–20 of 51 posts
Serious question: How do organizations deal with having git on the critical path for deployment? Current employer actually prohibits this due to frequent outages in the git plant.
Serious question: How do organizations deal with having git on the critical path for deployment? Current employer actually prohibits this due to frequent outages in the git plant.
Everything you are referring to is the CI/CD pipeline. GitHub actions, Gitlab Runners, ArgoCD; they can all do some sort of gitops. Those dependencies existed before gitops anyway, so nothing new is being added.
ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments.
That only covers pull-based GitOps. Push-based GitOps doesn't require Kubernetes, let alone magical Kubernetes operators, only plain old CICD pipelines.
Earlier quoted context omitted.
Last I saw, ArgoCD was heavily reliant on Kubernetes. Has this changed? (also, it seems like the site is heavily supporting ArgoCD)
The whole premise of opengitops is heavily reliant on kubernetes.
There's indeed a fair degree of short-sightedness in some GitOps proponents, who conflate their own personal implementation with the one true GitOps.
Back in the real world, the bulk of cloud infrastructure covers resources that go well beyond applying changes to pre-baked Kubernetes cluster. Any service running on the likes of AWS/Google Cloud/Azure/etc require configuring plenty of cloud resources with whatever IaC platform they use, and Kubernetes operators neither cover those nor are a reasonable approach to the problem domain.
ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments.
> ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments. That only covers pull-based GitOps. Push-based GitOps doesn't require Kubernetes, let alone magical Kubernetes operators, only plain old CICD pipelines.
Serious question: How do organizations deal with having git on the critical path for deployment? Current employer actually prohibits this due to frequent outages in the git plant.
You mean like storing source code? CICD pipeline definitions? Container image specs? IaC manifests? Service configuration files?
I don't think that arbitrarily drawing the line on what package version is being deployed is a rational opinion to have. I mean, look at npm's package.json. Is it ok to specify which dependency versions you bundle with your software, but specifying which version you're deploying is unheard of?
The only drawback I see in GitOps is that CICD pipelines are still lagging way behind on providing adequate visualization strategies to monitor the current state of multi-environment deployments.
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
The problem with git ops only manifests after it’s become a standard within an org: 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
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.
The problem with git ops only manifests after it’s become a standard within an org: 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
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.
Serious question: How do organizations deal with having git on the critical path for deployment? Current employer actually prohibits this due to frequent outages in the git plant.
You can disable reconciliation and then manually apply a change if your git repo is unavailable.