Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

Hu Predrag, if those microservises are very similar, I would go with creation of one universal helmchart, with witch you are able to deploy each microsrvice, prividing specific values :slightly_smiling_face: 

hi Jaroslav! how do i do this exactly? how would I keep the versioning of services? I can provide values with -f … but didn’t find a way to provide the Chart.yaml to helm install command

Hi Predrag. It depends on your situation and requirements. If those microservices are internal ones and are part of one solution which is not OSS then you dont have to bother with helmchart versioning in chart.yaml because you version only microservices docker image. Helmchart can be generic. Lets imagine a situation you have 10 backend microservices - very similar in configuraiton and deplyment. Then you can have one helmchart called eg. &lt;company_name_for_instance&gt;_backend. and using this helmchart you do particular deployments/releases of individual microsevice where each release name reflect microservice name and consume its dedicated values-&lt;microservice_name&gt;.yaml from outside. (common default values could be integrated in generic values.yaml in the helm chart). In this situation you can omit Char.yaml versioning having dedicated for each microservice

<@U05K5CHJW9M> <https://timoni.sh/> You can also take a look at it as a potential helm replacement if your use case is complex, it's base on cue lang vs yaml, setting this up might be complex as this is a bit new, but using can extend it to advance use cases, also added a video here, describing when to consider over helm <https://www.youtube.com/watch?v=bbE1BFCs548>

<https://github.com/clouddrove/helmchart>
use this repo to deploy your application using helm chart.. these helm chart content all type of object deployment which doesn’t come up with default helm chart.

hey <@U051G45154Y>, not sure how this helps, this is a single chart if I understand it correctly

<@U05L0Q38ES1>thanks for the advice, this sounds great! Could you give me an example when helmchart versioning is important?

image.png

Hi <@U05K5CHJW9M>, Helm Chart version is required and important. you version your helm chart templates based on the changes in the helm chart following semantic versioning. But this `version` does not reflect any microservice/applications version, it has its own independent versioning cycle. Besides of this version you can have `appVersion` specified in the Chart.yaml. But this field is *optional* and you are free to use it whenever it makes sense to use it. For instance, when you develop some OSS application for which you provides helm chart for the deployments, then it is good practice to specify `version` and `appVersion`  in the Chart.yaml. Or when you have dedicated helm chart per application/microservice. But on the other hand when you create a generic helm chart for backend microservices then it  does not make sense to specify `appVersion` . Only `version` is required to reflect changes in the generic backend helm chart. Hopefully you will find this helpful.

thank you very much for the detailed explanation and taking the time! much clearer now :)