我想知道您关于掌舵图表版本管理的最佳实践（或仅仅是实践）。
我想知道处理应用程序版本控制，持续集成/交付和图表打包的最佳方法是什么。
今天，我有许多微服务可以生活。每个人都有自己的生命周期，并且在自己的git存储库中拥有自己的版本控制。
此外，我们选择为所有图表提供一个git存储库。
现在，我们还有很多选择：
--set image.tag=vx.x.x标志。从“操作”角度来看，第一种方法的好处是，我们随时可以知道集群上正在运行每个图表（和每个docker映像）的版本。缺点是，在某些时候，每个图表会有很多版本，只是docker标签版本发生了变化。
另一方面，第二种方法的好处是，唯一可以更改图表版本的是对图表代码本身的修改，而不是对应用程序的更改。它大大减少了每个图表的“无用的”高版本号。缺点是我们必须在安装/升级时覆盖docker标签，并且无法观察到集群上正在运行哪些版本（在灾难恢复计划中充分使用）。
那么，您的做法是什么？也许是混合方法？
谢谢您的帮助
答案 0 :(得分：2)
我认为这是一个取决于您项目需求的选择。一个有趣的比较是Kubernetes图表回购中公共图表的当前版本控制策略和Jenkins-X的当前默认版本控制策略。
仅当对图表进行更改时，公共图表才会被颠簸。这可能是更改它指向的默认图像标签的版本，但是每次它都是显式操作时，需要进行PR和审阅，并决定是主要版本，次要版本还是修订版本。
在Jenkins-X集群中，默认行为是，当您更改其中一个微服务的代码时，无论图表本身是否更改，其图表版本都会自动颠簸。源存储库中的图表引用了快照，但是它是在显式版本下自动部署的，并且该版本在通过管道部署到的环境中被引用。该图表引用了源中图像的草稿/ dev标签，并且在流程中也自动替换为显式版本。
我认为关键的区别在于，Jenkins-X朝着具有特定流程环境的高度自动化的CI / CD流程发展。它的方法对于处理变更的频繁部署是有意义的。公开图表旨在实现可重用性，并通过公众贡献在广泛的环境和情况中提供稳定的体验。因此，该策略的主要目的是使您希望通过比较发现不那么频繁的更改具有可见性并易于理解。