我们在项目中使用 CD，由于该应用程序在全球范围内使用，我们使用多个数据中心（每个区域一个）。每个数据中心托管一个隔离的应用程序实例（每个区域部署都使用自己的数据库、应用程序服务器等）。数据中心之间不共享数据。
我们可以采取两种不同的方法：
部署到运行所有测试的集成服务器 (I)，然后部署到第一个数据中心 A，然后（一旦部署到 A 完成）到数据中心 B。
区域 A 的用户群较小，为了防止集成服务器 (I) 上未捕获的软件错误导致 A 和 B 中断，另一种方法是部署到集成服务器，然后将代码“烘焙”到区域 A 24 小时，只有在生产环境测试 24 小时后才能将应用程序部署到数据中心 B。由于在这种情况下没有“持续”部署，这种替代方案是否违反 CI 最佳实践？
正如 Paul Hicks 评论的那样，最佳实践可能是使用功能标志将部署与功能交付分离。也就是说，拥有许多生产服务器的组织通常通过部署到服务器子集（“金丝雀部署”）并在部署到所有服务器之前进行监控，或者使用蓝绿部署来保护其正常运行时间。部署代码后，人们可以通过仅为一部分用户翻转功能标志来进一步对冲赌注，并且再次在向所有人公开该功能之前进行监控。
持续集成和持续部署之间有很大的区别。CI 适用于多个用户在同一个代码库上工作并且集成测试重复运行以进行多次签入的情况，以便以编程方式快速处理集成失败。持续部署是一种封装快速部署并以编程方式接受验收测试的实践，以便您尽可能快地进行部署（而不是大多数 IT 组织中通常存在的票务延迟）。你问的问题是两者的混合
根据您的具体问题，您的做法确实违背了最佳做法。如果您有 2 个不同的数据中心，您就有可能在不同的数据中心遇到不同的问题。
我宁愿设计您的数据中心，使其能够灵活地在当前版本和下一个版本之间切换。这样，您可以将代码部署到“下一个”环境，在那里运行您的测试。一旦您的测试确认您的新环境可以运行，您就可以将您的环境从当前切换到下一个。