问题描述
想知道在一个状态文件中同时维护基础设施（基础设施即代码）和应用/服务（使用Terraform的helm_release提供程序进行helm chart部署）是否有任何优势。
用户不喜欢在一个状态文件中同时维护基础设施和应用的想法，因为由于只有一个状态文件，可能会检测到其他与基础设施相关的更改，并进行部署，这可能会对基础设施产生意外的影响。
然而，用户希望保持开放并听取建议，看看维护一个状态文件是否提供了任何优势。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
我倾向于将基础设施代码与应用部署代码分开。这样做有多个原因：
– 您希望基础设施团队负责基础设施更改，而应用团队负责应用更改（包括应用配置）。将它们分开可以为它们指定不同的限制条件（例如，只有基础设施团队被允许向基础设施仓库推送更改）。
– 如果进行基础设施更改，您不一定希望触发应用重新部署，而如果触发新的应用构建，您也很少希望触发基础设施的重新部署。
– 您不希望应用的错误构建阻止您进行任何基础设施更改，反之亦然。
将应用部署代码（即Helm chart）放在应用仓库本身中实际上是有道理的。
然后，您可以将应用配置更改与相应的应用发布一起打包。这也使开发人员能够自行完成，而不会增加破坏生产环境的风险。
这还将使您的CI/CD工具能够同时部署两者。
由于每个GitHub分支中都有应用IaC和应用本身的严格映射，这实际上使您非常容易创建功能分支环境（即开发人员创建一个新分支，您的CI/CD工具会接收到并自动部署到kube环境）。
方案2
将它们分别应用并由不同的状态/角色管理，还可以更好地实施安全性和控制，例如限制谁可以创建VPC、NAT网关，因为您可能不希望应用开发人员具有对您的账户的那种访问权限。
另一种方法是将基础设施和应用分别应用并由不同的状态/角色管理。这样做还可以更好地实施安全性和控制，例如限制谁可以创建VPC、NAT网关，因为您可能不希望应用开发人员具有对您的账户的那种访问权限。
方案3
如果您的基础设施和应用之间有强依赖关系，并且它们的更改通常是同时进行的，那么将它们放在一个状态文件中可能是有意义的。这样可以确保基础设施和应用的一致性，并简化管理过程。但是，您需要非常小心，确保在进行更改时仔细检查和测试，以避免意外的影响。
如果您的基础设施和应用之间有强依赖关系，并且它们的更改通常是同时进行的，那么将它们放在一个状态文件中可能是有意义的。这样可以确保基础设施和应用的一致性，并简化管理过程。但是，您需要非常小心，确保在进行更改时仔细检查和测试，以避免意外的影响。
以上是维护一个状态文件提供的一些优势和注意事项。根据您的具体情况和需求，选择适合您团队和项目的最佳方法。