Recommended workflow for promotion through clusters

[funkypenguin]

Hey guys!

flux beginner over here, just getting started, and I had a question re the recommended approach for moving changes through flux-managed clusters..

Situation is this: I have several clusters, let's call them "ci, dev, and prod". I want to deploy services into each cluster, but I want to "promote" my changes from ci -> dev -> prod, by means of git merges/PRs, and not duplication of files across 3 separate directories.

So my current plan is this:

Each cluster is synced to the same repo, but each in their own branch.

• ci -> myrepo:flux/flux-system (ci branch)
• dev -> myrepo:flux/flux-system (dev branch)
• prod -> myrepo:flux/flux-system (prod branch)

My plan is then to add the app manifests (for example, a helmrepository and helmrelease) to myrepo:flux/<app name> in the CI branch, work out the kinks, and then PR a merge from ci to dev, and ultimately dev to prod.

The only hiccup in my plan is this : in the repo, flux/flux-system/gotk-sync.yaml makes explicit reference to the branch to sync against, in GitRepository's .spec.ref.branch.

Even if I start by manually bootstrapping each cluster against their respective branch, as soon as I start merging from ci -> dev -> prod, I risk overwriting dev branch's flux/flux-system/gotk-sync.yaml with ci branch's flux/flux-system/gotk-sync.yaml, and causing my dev cluster to start syncing against the ci branch. Best-case, the merge fails on a merge conflict - worst case, gotk-sync.yaml gets silently overwritten during the merge, and end up syncing clusters against wrong branches.

Any ideas / suggestions re how to approach this?

Thanks!
D

[haraldatbmw]

I have similar requirements like you but I'm also new to GitOps. My environments are 1. dev, 2. test, 3. prod.
I'm trying to achieve the deployment to my clusters with one branch only and using tags with semantic-versioning to go from one cluster to the other. In the master branch I use different directories to distinguish between the clusters.

That means every commit in the git-ops repository master branch is deployed to dev-environment.
If I create a pre-release tag (1.2.0-beta1) on this commit it is deployed to test-environment.
If I create a release tag (1.2.0) on this commit it is deployed to prod-environment.

[jack-evans]

I also have similar requirements.... my concern is also that flux will add commits onto the branches which then puts them out of sync with each other and cause issues with git history.