不久前，我们正好遇到了这个问题。Chart维护者用一个新的条件块更新了共享chart。该语句检查了一个新的变量“foo”是否被设置为“启用”。然而，变量“foo”还没有在所有服务的值文件中定义。对于缺少该变量的服务，部署中断了。不幸的是，当时chart中没有定义默认的回滚行为。
如果chart和代码位于同一个仓库中，并且可以在同一个分支中进行测试，则针对这些问题的测试将更加容易。
即使一开始似乎是矫枉过正，我们也会这样做。我们的工作对象是很少有依赖项的服务。对于每个服务，Helm chart只部署一个带有特定Docker标签的主容器。chart的名称和docker标签是通过变量传递进来的。尽管如此，我们仍然避免了使用共享chart，而是选择在每个服务仓库中放置单独的chart。
这主要是因为我们只处理了四个服务。但我们的开发人员也更喜欢掌控所有能够影响CI/CD的配置。然而情况并非总是如此，所以现在是研究另一个维度的好时机。
团队结构Chart维护的问题同时也取决于谁管理部署流程。
这里推荐另一篇文章，由Helm维护者Matt Farina撰写的，在文章中他阐述了关于Helm正在尝试解决复杂性的话题。文章链接：
https://codeengineered.com/blog/2018/helm-kustomize-complexity/
他阐明了必须处理Kubernetes复杂性的三个主要角色。为了清楚起见，我将对其内容进行一些解释，并将角色描述如下：
App开发人员——这个角色主要构建服务、添加特性以及修复bug
Deployer——这个角色负责将应用程序推向世界。理想情况下，有一个不错的自动化程序可以为他们部署应用程序，但是他们知道它的工作方式，可以根据需要进行修改。
系统工程师——这一角色负责维护deployer部署的Kubernetes环境。他们是管理计算机资源的专家，并且可以尽量减少任何服务的停机时间。
第一个和第三个角色你都能在公司里找到与其负责内容相符的职位，而Deployer这个角色则有些模糊，这个角色所负责的内容常常会被其他两个角色的人接管——这会影响你如何管理你的Helm chart。
尚在早期阶段的初创公司的DevOps如前所述，我们的业务是为初创企业提供运维支持，这些企业往往需要快速扩大规模。我们见过很多“非常规”的设置和分工。在早期阶段，App开发者可能会负责各种事情，有些人甚至会帮忙完成系统管理员的任务，比如设置打印机或配置办公室网络等。他们会尽力去了解其他两个角色所需要负责的内容，因为没有人可以帮助他们（直到我们参与进来）。
一旦他们想了解Helm，大多数应用开发者会把他们的chart放在最容易处理的地方——也就是他们维护的同一个repo。
在大型企业中的DevOps你可能在一个更大的、架构更分明的团队中工作，
在这种情况下，你可能有自己的DevOps工程师甚至是整个DevOps部门。而这个人或团队经常会觉得自己也要负责 “Deployer”的角色。很有可能，他们会倾向于采用更集中的方法，比如将所有的chart存储在ChartMuseum这样的chart仓库中。更不愿意让应用开发者过多地参与到Helm chart中来（往往是有合理缘由的）。
例如，我最近看了一个经典的技术讲座，叫《从头开始构建Helm chart》，由VMWare系统工程师Amy Chen主讲。在她的开场白中，她说：
在基础设施方面，你的主要目标是时刻准备着应对故障，没有信任——在这个意义上说，就像我不太愿意信任我的APP开发者，并且我也不太需要信任我的APP开发者。
这是可以理解的。你不想让应用开发者去搞乱设置，比如CPU和内存限制，或者是pod中断预算。但整个 “DevOps文化”的概念是专门为了改善基础设施维护者和开发者之间有时会出现的疏离关系而演化出来的。
实践DveOps文化Atlassian（JIRA和Trello的所有者）出版了一本“团队手册”，其中定义了DevOps文化：
DevOps文化是关于开发者和运维之间的共同理解，并为他们所构建的软件分担责任。这意味着增加透明度、沟通和协作，并在开发、IT/运维和 “业务”之间进行合作。
如果将其实际应用到Helm chart维护和一般的基础架构配置中，就会把大部分的责任放在应用开发者的手中。他们也会承担起“Deployer”的角色，并改变他们拥有的仓库中的配置。
系统工程师仍然可以把他们专门维护的设置集中起来。例如，一些团队也会维护一个中央基础架构repo，该repo中保存着Terraform配置或Helm文件等常用资源，这些资源是启动新项目所需要的（例如，用于设置ingress controller和cert manager）。Helm 3还支持所谓的 “library chart”，它只能作为另一个chart的一部分进行部署。这让我们更容易区分常见的和服务特定的变更责任。