I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath.

Ps. when I first saw Argo, I thought this is it. The solution to all my problems.

    cat <<EOF | kubectl apply -f -
    apiVersion: kargo.akuity.io/v1alpha1
    kind: Promotion
    metadata:
      name: prod-to-${FREIGHT_ID}
      namespace: kargo-demo
    spec:
      stage: prod
      freight: ${FREIGHT_ID}
    EOF

I dont blame the author(s) but things are getting more specialized and more terms are created. (which usually maps to an existing term which also maps to an existed term which also maps an existing term and so on.

I have though about trying to create a "terminator"(hah) where you can paste in something from a new product and it will map the terms to existing terms as a sort of translator or term machine.

"" We are thrilled to announce Kargo, a multi-stage application lifecycle orchestrator for continuously delivering and promoting changes through environments. Kargo, brought to you by the creators of the Argo Project, is a reimagining of CD pipelines for the cloud-native era, with first-class GitOps support, progressive delivery features, and is 100% open source. ""

This way each environment is in its own directory which can have its own patches such as using a private load balancer instead of public for a staging environment or setting whatever environment variables that need to be different.

Then at the Argo CD level, Argo CD running in prod will look for an Application in the prod/ directory and Argo CD running in staging will look for an Application in the staging/ directory.

All in all you end up deploying the same artifact across environments and all of this is managed and exposed by Argo CD. For example you might want AutoSync enabled for staging so developers can auto-deploy their code but prod requires a tech lead or manager to push the sync button to deploy it.

The above works well in practice and isn't too complicated to pull off.

I didn't see an explanation of how Stages are different than jobs. Every single usage of Stage could have been replaced with job and the meaning would stay the same.

The data and DevOps marketing people really need to drop the buzzwordism.

We disallow writing back to GitHub to avoid this issue, and manage stages through branches, combined with directories for overlays. Things can get out of sync, but comparing branches is easily automated.

In my experience it gets pretty hairy to build automated conditional promotion in a GitOps pipeline, especially if you don’t go all the way to continuous delivery and might have different versions at different stages between environments.

Can’t say I’m a fan of “we call it freight” though. Artefact is a perfectly fine word.

> Something like this is definitely needed in the GitOps space...always felt like something was missing between promoting things and rolling them out

> Interesting. Will share with my team and try it out.

> There is a webinar tomorrow with Kelsey Hightower! Here is the link if you want to join https:...

> Looks promising, I'm definitely going to take it for a spin!

Something tells me this isn't organically gaining traction...

Tighter integration with other Argo products? Why is this not simple a new component of Argo CI/CD? How much is "thought-leadership" a part of it, it is Kubernetes-adjacent, after all.

So far even the answers in this thread leaving me asking these questions even more strongly? If Argo CD is a "continuous deployment" tool, why isn't the priority making staged-rollouts a first class feature in Argo CD itself?

This is coming from a place of curiosity, not simply being a miser, I promise.

So in your example, suppose you changed something in your Kustomize `base/` directory. With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment.

With Kargo, it looks like it lets you define your preferred promotion process, and then lets you release each promotion with a single click. I think the part that is the most interesting to me though is that it writes the changes it is making directly to the git repo.