我想知道您的掌舵图版本管理的最佳实践（或仅仅是您的实践） .
我想知道什么是处理应用程序版本控制，持续集成/交付和图表打包的最佳方法 .
今天我有许多生活中的微服务 . 每个人都有自己的生命周期，并且在自己的git存储库中拥有自己的版本 .
此外，我们选择为所有图表提供一个git存储库 .
现在，我们有太多选择：
-
每次微服务更改时，都会构建一个新的docker镜像，并且还会创建一个新版本的图表（只有dock.yaml文件中更改的docker镜像的标记）
-
或者，即使微服务发生变化，我们也不会创建新版本的图表 . 图表中docker标记的默认值设置为"default"，当我们要升级图表时，我们必须使用
--set image.tag=vx.x.x标志 .
第一种方法对于“操作”观点的好处是，我们随时知道每个图表（以及每个泊坞窗图像）的哪个版本在群集上运行 . 缺点是在某个时间我们将有许多版本的每个图表只有一个改变的docker标签版本 .
另一方面，第二种方法的好处是，使图表版本更改的唯一方法是修改图表代码本身，而不是应用程序更改 . 它大大减少了每个图表的“无用”高版本号 . 缺点是我们必须在安装/升级时覆盖docker标记，并且我们失去了对集群上运行的版本的可观察性（在灾难恢复计划的情况下很有用） .
那么，你的做法是什么？也许是一种混合方式？
谢谢您的帮助
1 回答
我认为这是一个可以满足您项目需求的选择 . 一个有趣的比较是Kubernetes图表仓库中公共图表的当前版本控制策略以及Jenkins-X的当前默认版本控制策略 .
只有在对图表进行更改时，公共图表才会受到影响 . 这可能是为了碰撞它所指向的默认图像标记的版本，但每次它都是一个需要pr和审查的明确动作，并决定它是主要的，次要的还是修复版本 .
在Jenkins-X集群中，默认行为是当您对其中一个微服务的代码进行更改时，无论图表本身是否发生更改，它的图表版本都会自动发生 . 源repo中的图表是指快照，但它是在显式版本下自动部署的，并且该版本在通过管道部署到的环境中被引用 . 该图表引用了源中图像的草稿/ dev标记，并且在流程期间也会自动替换为显式版本 .
我认为关键的区别在于，Jenkins-X正朝着流量中特定环境的高度自动化CI / CD流方向发展 . 它的方法对于处理频繁的更改部署很有意义 . 公共图表旨在通过公共贡献，在广泛的环境和情况下提供可重用性和稳定体验 . 所以那里的策略更多的目标是通过比较，您可以减少频率的可见性和易于理解 .