即使当chart存储在服务仓库中，系统工程师仍然可以作为重要更改的把关人。例如，你可以使用GitHub CODEOWNERS文件来确保系统工程师在你的repo中的chart目录中的任何更改都会被添加为审核者。
如果系统工程师需要主动做一些与应用开发无关的改动，可以指导开发人员为他们做更改，并解释为什么这些改动是必须的。以下图片也许能反映这种情况：
开发者可以了解更多关于基础设施的内容以及这些更改如何影响他们的服务。
经验法则如果有简单的经验法则，那就是：先了解选项3。尝试为服务仓库中的每个服务维护一个Helm chart。或者至少考虑一下我之前描述的混合方法。
如果你有几十个服务都非常相似，那么共享chart是更好的选择。只是要记住，你必须把它维护在一个中心repo中。但是这增加了意外耦合的风险，可能会破坏一个服务部署。风险增加意味着你在部署的时候需要更加谨慎，这反过来又意味着你会减少部署的频率。
即使你有特定服务的chart，你可能也需要集中存储，因为你没有足够的人员或专业知识以分布式的方式来管理这些chart。或者，也许你的团队需要在“Deployer”和“应用开发者”之间明确划分责任。
无论你决定做什么，我希望我已经说明清楚了你在做最后决定时需要考虑的问题。做一个“Deployer”并不容易，尤其是当它不是你的日常工作时。
作者：Merlin Carter，专注于早期创业公司的风险投资家，擅长撰写开发人员创新和新技术的文章
原文链接：
https://insights.project-a.com/whats-the-best-way-to-manage-helm-charts-1cbf2614ec40