Kargo - Multi-Stage Deployment Pipelines using GitOps - Jesse Suen / Kent Rancourt

Kargo is the next step in your Kubernetes application delivery evolution aimed to provide stage-to-stage promotion using GitOps without bespoke automation and CI pipelines.
Whilst GitOps excels at fast, seamless application delivery to single environments, it often lacks the features required to accommodate multi-stage, wide-reaching deployment pipelines that involve extensive verification. This shortfall in resources pushes GitOps practitioners towards CI platforms and custom automation, leading to complex and potentially brittle deployment systems. This is a prevalent challenge for platform engineers establishing a GitOps-centered self-service platform.
This talk will focus on alternative patterns that effectively address these challenges without compromising core GitOps principles. Emerging open-source solution, Kargo, straightforwardly tackles these challenges while harmoniously working with preferred tools of GitOps users such as Kustomize, Helm, Argo CD, and Flux.
👀See more: platformcon.co...
📙Platform Engineering Courses: platformengine...
🤘Join the community: platformengine...

[@AFPinerosG]

CD implies CI, CI is part of CD, CD can't exist without CI. Without CI, CD is just... D. It isn't continuous.
The "CI Kung Fu" is not a problem of Jenkins or any other automation tool, it is a problem with GitOps and the async nature of Argo/K8s. Synchronous GitOps tools don't require those web hooks to talk back to Jenkins.
I really like Kargo but it feels like it is trying to blame everything else instead of saying "Hey, look, we improved the Argocd experience, now we can have environment promotion mechanisms".

[@dso-x9z]

Great approach, got the same feeling as you concluded by watching this talk. Nonetheless, will give it a try, seems promising and will streamline my org CD process.

[@signorUBO]

he did not say that CI has no reason to exist, he said that the tools made for the CI have been bent to perform CD and it was not their role, it has always been a shortcut (less dev and ramp up to learn new tools).
CD is a multi phase (stage) flow by definition, either fully automatic (continuous deployment) or with manual sign-offs (less continuous, but still with its advantages).
Here they offer a rule based approach that offers a better UX for anyone (where the rules are defined principally by the flows design, for instance, what is the order of the phases is a rule), same with harness by the way, at some points these 2 companies realized the struggles with "chains" of scripts triggered via webhooks in term of traceability, troubleshooting, monitoring.
The fact that gitops works in pull mode (ArgoCD pulling the desired state and applying it) it's a detail, the interface for the tools that request a deployment is always a push action (commit pushed to the gitops repo), I don't see much difference in triggering a deployment with a synchronous gitops tool as you called it or just committing a new desired state and polling ArgoCD APIs to get the state, both should work, and in both cases you would like to have a release flow view on top of the deployment to follow your app promotion cycle