Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tractusx-dev] Discussion / Suggestion: Alignment of Helm Chart Versions with App Versions

Hi Sigi,

 

sorry for the late response.

 

I’m all for making our endeavor more transparent and easier to understand and appreciate that you think about measures for that!

 

At the same time, I’m having my doubts that aligning chart and app version is an appropriate measure here.

I think that chart version and app version are specific concepts that are inherently tied to helm charts. It’s crucial that we utilize these concepts in their intended manner; otherwise, our attempts to simplify matters may inadvertently lead to additional confusion. Furthermore, there are instances where changes need to be made solely to the chart, without any changes to the underlying application itself and also the other way around.

 

I also think the topic of aligning chart version and app version has gotten a bit mixed up with the topic of having split repositories.

 

Kind regards,

Evelyn

 

Von: tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx> Im Auftrag von Kiermayer, Siegfried via tractusx-dev
Gesendet: Dienstag, 13. Juni 2023 14:22
An: tractusx-dev@xxxxxxxxxxx
Cc: Kiermayer, Siegfried <siegfried.kiermayer@xxxxxxx>
Betreff: Re: [tractusx-dev] Discussion / Suggestion: Alignment of Helm Chart Versions with App Versions

 

Sent from outside the BMW organization - be CAUTIOUS, particularly with links and attachments. 

Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen von Links und Anhängen. 

Hi everyone!

 

Holidays are probably over and I would like to “remind” you about this discussion, but I would also like to add the following screenshot to show you how it looks to people outside:

 

 

<see attachment>

 

Tx,

 

Sigi

 

 

 

From: Kiermayer, Siegfried <siegfried.kiermayer@xxxxxxx>
Date: Friday, 2. June 2023 at 16:20
To: tractusx-dev@xxxxxxxxxxx <tractusx-dev@xxxxxxxxxxx>
Subject: Discussion / Suggestion: Alignment of Helm Chart Versions with App Versions

Hi everyone!

 

We need to talk about Helm charts and versioning of them in connection with app versions:

 

You have probably seen that we have released 3.1 of Eclipse Tractus-X;

 

You might also have seen how this looks in our Changelog: https://github.com/eclipse-tractusx/tractus-x-release/blob/main/CHANGELOG.md . Confusing I would say. It’s a big wide table with different versions and a lot of potential for confusions, wrong versions etc.

 

I haven’t suggested any TRG like “Alignment of Helm chart version with App Version” regarding this alignment before because I did not had any practical experience with this particular issue. Also when you look at other Helm charts, especially the quite often used bitnami postgresql helm chart, they do diverge.

 

BUT! My current assumption is that bitnami Helm charts diverge primarily because those helm charts are build by bitnami and others for other products like postgresql.

 

I see following advantages and disadvantages:

 

Advantages:

  • Easier to understand what Helm Chart is responsible for which App version
  • Easier spotting of which App Version is used when using other tools like Kubeapps
  • Easier entry from people not having experience with Helm/Kubernetes
    • Business people
    • Beginners
    • Testmanagers
    • . . .

 

Disadvantages:

  • More effort when having split repositories to align the helm chart releases
    • Which got circumvented if you did not create an umbrella helm chart which references frontend and backend but combined it

 

Overall, I do personally think it would be much easier and more stable to combine your frontend/backend code in one repository and have your helm chart also in the same spot. This would guarantee that you release holistically. The complexity of combining multiply code projects is reduced on GitHub through path filters: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore with this you are easily able to do certain things like backend/frontend tests etc. only when your frontend or backend has changed.

 

Please bring up your points (upsides, downsides), your experience with it and everything else to make it easier for the Eclipse Project Leads to decide if this is something we should or should not make mandatory.

 

At the current point there is no TRG planed, if this is a controversial topic, a TRG might be introduced which is optional but suggests one specific strategy.

 

Thanks,

 

Sigi

 

 

 

Back to the top