Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterate and improve release process #13

Open
f1ames opened this issue Oct 25, 2023 · 0 comments
Open

Iterate and improve release process #13

f1ames opened this issue Oct 25, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@f1ames
Copy link
Contributor

f1ames commented Oct 25, 2023

We had interesting brainstorm in context of release process and #9 PR with @murarustefaan and @WitoDelnat. There are multiple approaches and tools to handle this, but at this stage we don't have very clear vision - since we did 0 releases so far and it's difficult to say what will be needed or useful.

Still we know there is a place for improvement. It seems beneficial to decouple containers versioning from chart versioning as describe in #9 (comment) thread:

I'd keep the versions separated. There is little benefit to having them being the same. If you have problems with certificates it can even help to see if the init container changed (meaningfully).

As for the Helm Chart versioning I'm a bit more hesitant. Do we want to publish a new Chart for each Docker Image or leave the image as a variable in the values.yaml and default it to latest (...)

I have not seen a lot of projects linking the Chart and App Versions, they are separated for a reason.
Chart version should change only on Chart modifications, while App Version should change alongside the image version. Here I would link the App Version to the admission controller version (which should be configurable trough values, just in case) while leaving the init container set to latest.

Also decoupling image build/push from release process:

So the flow i had in my mind was more on the lines of:

  1. merges into main will build & push images with the corresponding package.json version, just like we do for the cloud application yet with image tags derived from package.json version.
  2. tag pushes will force chart deployments (or here we can even do both, we can have tags following a naming scheme like chart/v1.1.1 & server/v1.1.1 and do both builds & chart release, it is up to you)
  3. the image tag for the server we can either update manually before pushing a chart tag for releasing, create a pre-commit hook that will modify the images to the package.json version, or set to latest, i'm not yet sure how we could easily do it automatically yet

And:

Or another idea, if you want to keep them together is during build update the version of AppVersion, and during release check if there is already a release with that appVersion in the registry

@f1ames f1ames mentioned this issue Oct 25, 2023
4 tasks
@f1ames f1ames added the enhancement New feature or request label Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant