问IaC在web/API开发项目中属于哪里？

EN

拥有一个单独的IaC存储库

这么做的最迫切的原因是将IaC的CI/CD与应用程序回购分离开来。例如，如果应用程序代码库没有连续地交付，并且IaC与代码库被提交到相同的repo中，那么您将在这样一个场景中结束: IaC与代码一起进行版本化。如果您部署了一个旧版本或一个分支，那么该版本或分支是否从回购协议中获得与代码本身相同的引用？如果是这样的话，您将不得不跨分支合并IaC更改以使其可部署，这是一个非常令人头痛的问题。

到2022年，大多数开发团队都希望不断地交付他们的代码并“失败前进”，而不是回滚回旧版本。在这个场景中，这并不重要，因为代码的main分支也是基础结构的main分支。但在这种情况下，回滚到旧版本的代码本质上意味着回滚到基础结构的匹配版本，所以如果不仔细研究两个版本之间进行了哪些基础结构更改，以及是否安全地回滚底层更改，您就无法做到这一点。

另一方面，如果IaC回购与代码回购是分开的，则可以使IaC适应多个版本的代码。依赖关系仍然存在--随着代码的变化，应用程序中需要新基础设施的新功能本质上依赖于Infra，而且您没有共享回购以确保在应用程序之前部署这些依赖项。

这通常归结为所有权问题。如果基础设施主要由一个不同的组管理，那么将其放在一个单独的存储库中是很有意义的，因为将基础结构更改与代码更改混合在一起会使这些组很难独立操作。从另一种回购方式推动基础设施改革，本质上是一个孤立的步骤。要从相同的回购中推出基础设施更改，需要将一个PR合并到代码库中并进行部署。如果水下变化是唯一被部署的东西，那是非常直接的。但是，如果代码库的CI分支处于混乱状态，那么基础结构就变得不可部署，因为代码是不可部署的。如果基础设施是由团队拥有的，而团队的任务是保持代码回购干净和可部署，那么将repos拆分并不会有多大好处。

在过去12年左右的时间里，我一直在做DevOps，我非常喜欢将IaC放在一个单独的回购系统中，用于处理混乱的应用程序，这些应用程序的团队难以持续交付。这样，当我想要进行基础设施更改时，我可以相对隔离地考虑它们，并且可以将它们部署到所有环境中，而不管部署在那里的是哪个版本的代码。尝试迁移数据库托管非常糟糕，例如，如果您需要与产品团队合作，将您的IaC放到部署到每个环境中的每个代码版本中。但这不是免费的午餐-当然，我仍然必须确保协调下位代码和代码之间的依赖关系。

服务越小，开发团队处理IaC的次数就越多，开发团队对CICD的处理方法越严格，就越不重要。如果同样的代码被发送到dev/prod，并且代码合并和部署是一件频繁而舒适的事情，那么IaC可能也会出现在应用程序代码库中。但是，您必须做好准备，将其局限于一种失败的、持续集成的方法，并接受基础设施和代码部署是在回购层耦合的。

大多数微服务开发团队倾向于拥有他们自己的IaC，不断地交付他们的应用程序，并将他们的IaC与他们的代码放在同一个回购中。