fluxctl feature Parity in Flux v2

[funkymcb]

We are currently evaluating the migration to flux v2.
However our current CD-Pipeline depends heavily on fluxctl, since we deploy our workloads through dev, test and prod via a script which runs "fluxctl release". The script is called in Azure Release Pipelines which allows you to deploy with a single click.

I couldn't find information about whether there is feature Parity with fluxctl in Flux v2.
Or does Flux v2 maybe have a better approach on releasing workloads with an api maybe?

[kingdonb]

The API that Flux v2 provides for releasing workloads is the ImagePolicy CRD. If you want to release a specific tag, then you can set a tag filter with a regex that matches one specific tag only, or if you're using semver image tags, you can set a tag filter with a semver range equal to that one version only.

Releasing a specific version is a pretty common use case that could maybe still be streamlined a bit in Flux v2. The most streamlined thing at the moment is to write your change (to the image policy, for example) into git; since it is GitOps, it has to be written into git somehow. It may seem strange to suggest writing a change to git (ImagePolicy with an exact range), so that Flux can write the change to the deployment into Git, but it is actually an important logical separation for a policy concern.

Anyway, you're mostly not meant to use automation with an exact version because it defeats the purpose of automation. What difference does it make if I write the ImagePolicy in git or if I write my change directly to the deployment? (It might be an important difference for some, maybe you have organized the resources in such a way that devs can set image policies without a review, but they cannot edit deployment manifests directly without a review... but for others it's really just writing to git, all the same either way!)

The point of image automation is to save you from writing every update to git manually. Calling an API to write the update to git is still making an imperative update eg. "manually" even when it is done with automation. Use policies to drive your automation instead.

If you use a semver range, or alphabetic/numeric timestamp or build number as described in the Sortable Image Tags guide, then Flux will monitor for new images and always be releasing the newest one. Set up an image tagging policy to match for each of your environment/pipeline stages, and use Flux in the way it was made to be used, with Git as the source of truth.