Feature branch workflow

[jshearer]

I'm trying to figure out how to fit my current ability to deploy arbitrary feature branches to my staging cluster into Flux. Currently, whenever I push a commit to a branch matching the pattern feature/*, my CI builds that commit and deploys it to the staging cluster, where I can test it out before merging into staging. Does Flux support a workflow like this? I thought of maybe deploying images tagged with feature/something but it doesn't seem like Flux supports deploying N workloads from a single helm chart or set of assets. What is the recommended workflow here?

[nabadger]

I've been thinking about this too.

I think the publishing of images is not an issue - CI can tag feature-branch images to suit your needs

The problem (at least that I see) is how you deal with the manifests - at this point it will depend what templating (if any) tooling you are using.

In my use-case, we have manifests for local, staging and prod. I was thinking we could have our CI pipeline copy (and commit) manifests from a template, for each feature branch (would happen via a git push on a feature-branch). At that point, Flux is just monitoring them as it does your staging/prod. Plus, your CI layer can set the image (or image-tag) in the manifests.

This obviously puts a lot of work on the CI layer to

• Create the feature-branch manifests and commit them back
• Cleanup (delete the feature-branch manifests and remove the deployment).

With Helm, this probably follows a similar pattern. but you are dynamically creating FluxHelmRelease instances.

[masterkain]

I'm interested in setting up this. For now the only half resource I found, no config files, is this: https://medium.com/rackner-engineering/fully-automated-gitops-on-kubernetes-with-weave-flux-part-1-4b0bf7d185a7

if someone can share their method that would be great.

also similar but by PR: https://github.com/stevenpall/github-actions/blob/master/flux-pull-request/README.md

[nabadger]

Both are similar, and both seem to be dependent on HelmRelease, which I think makes the task quite easy.

I think it's a bigger problem if you have a monorepo (like we do), and don't use HelmRelease (like we do).

Essentially I think the following is what needs to be solved.

1. Isolate the yaml (or Helmrelease) required for your application. If you have a monorepo, then you need a way to automatically find the path of these components (i.e. some structure to determine where some 'base' template lives).

2. Add the updated yaml (or HelmRelease)in the merge-request. This could involve copying the 'base' template and updating values.

3. Have flux pick up the new yaml

4. Remove the yaml when merge request closed

---

Because flux is fairly flexible, I think there could be a number of solutions to this, based on the setup people use:

• raw yaml vs kustomize vs helm-releases
• multiple repos vs monorepo

[kingdonb]

This is still a hotly requested feature for Flux v2. Please check out the developments there.

• Flux v1 is in maintenance mode #3320

so this development is not likely to happen in Flux v1.