This message was deleted.

We’re using GitLab CI/CD managed registry, and then using their CD to perform the deployments onto Kubernetes as well. Worked like a charm!

I think it’s possible to use gitlab CI/CD with github right?

I would assume the GitHub CI to be of comparable level of usability, so try that out first

we already use github actions

i’ve used both flux and argo for this - my personal preference is flux

Oh wow, I wasn’t aware GitHub lacks in CD for Kubernetes.

github actions are kinda “hey look, we can do CD too.. right? right?”

@Rob Wilson yeah GitLab CI does not care where your repositories are

We built our own simply because the current way through AWS is not great.

@anttip one thing i ran into was because Argo does not use

helm install

but rather

helm template

some Sprig functions do not work

Got it, thanks. Thats a fair point

i’m also not a huge fan of

app of apps

@Audrey github actions are nice, I’ve used both gitlab and github within the last year to do the same set of things and prefer github. I’m not experienced with the CD aspects of gitlab though

@Rob Wilson re: flux/argo - these tools do the same things .. they’re just very different in how they go about it. i think the big thing that drives folks away from flux is the lack of GUI

I’ve built a push based system using github actions and kapp - similar situation where-by people don’t love a multi-step process (building an image, then updating a manifest to change the version which is deployed) - even less do they love having to do this to promote image versions between environments. We’re also interested in A/B and canary deployments. We’ve done a spike on argo with istio but argos support for A/B/canary is in beta currently

yeah, flux + flagger + istio works GREAT for ab/canary - argo will work using rollouts - but since it does not take over the virtual service like flagger does you’ll get out of sync between git and rollouts ( there should be ways around that now )

oh really?

its big .. slow.. pipelines are complex.. it breaks a lot

is it possible to configure with code, or impractical?

its more practical if you use the operator - but outside of that its big json blobs

so argo is still what everyone recommends then, basically?

I would be fine moving from argo to flux for the very same reasons as Audrey. However we have a lot of non-technical stakeholders who want that visibility and ”control” over releases. I support the autonomy part in that, just not a fan of the fact that we need a GUI for it. But this is a tune i just have to dance into

Personally I very much like Github Actions and Gitlab CI with self-hosted runners. I'm a bit unhappy about Github Actions not having manual approvals - just for public repos or pricey Github Enterprise accounts. But if that's not required it's my favorite one and has very nice configuration possibilities like running some specific steps after one step failed

i’m in the same boat @anttip PMs want a GUI

Hey @Rob Wilson we are going through the same process now. We looked into flux and flagger, I concur with @Audrey folks need to use the CLI and there is just very little interest in that. We use GitHub actions and are trying to find a simple way to do this. If we can't we will likely go with Argo rollouts as we need canary releases.

I’m not a massive fan of jenkins, but wondering if anyone has any experience with this: https://jenkins-x.io/blog/2021/06/28/argo/

This is what we are using internally for app and policy delivery: a combination of K8s + Flux + Shipa: FluxCD's Developer Portal

are you using the paid version of Shipa?

@Brandon Mesa are you affiliated with shipa in any way?

Nope - in the Splunk market here.