在连续部署中，最好是立即部署到所有生产服务器还是仅部署到子集？

Question

我们在项目中使用CD，并且由于应用程序在全球范围内使用，我们使用多个数据中心（每个区域一个）。每个数据中心都托管一个独立的应用程序实例（每个区域部署使用自己的数据库，应用程序服务器等）。数据中心之间不共享数据。

我们可以采取两种不同的方法：

1. 部署到集成服务器（I），然后运行所有测试 部署到第一个数据中心A然后（一旦部署到A 已完成）到数据中心B。

2. 区域A的用户群较小，可以防止A中断 和B引起的软件错误没有被捕获 集成服务器（I），另一种方法是部署到集成服务器，然后“烘焙”代码 区域A 24小时，并将应用程序部署到数据中心B. 只有在生产中测试24小时后才能使用。做这个 因为没有，所以选择反对CI最佳实践 在这种情况下“连续”部署？

Answer 1

持续集成和持续部署之间存在很大差异。 CI适用于多个用户在相同代码库上工作并且针对多个签入重复运行集成测试的情况，以便快速和编程地处理集成故障。持续部署是一种范例，它快速部署并以编程方式接受您的验收测试，以便您尽可能快地部署（而不是大多数IT组织中存在的通常的票务延迟）。你问的问题是两者的混合

根据您的具体问题，您的做法确实违反了最佳做法。如果您有2个不同的数据中心，则可能会在不同的数据中心遇到单独的问题。

我宁愿设计您的数据中心，以便能够灵活地在当前版本和下一版本之间切换。这样，您就可以将代码部署到＆＃34; next＆＃34;环境，在那里运行你的测试。一旦您的测试确认您的新环境不错，您就可以将环境从当前切换到下一个环境。

Answer 2

正如Paul Hicks评论的那样，最佳做法可能是将部署与功能交付与feature flags分离。也就是说，拥有许多生产服务器的组织通常通过部署到服务器子集（“canary部署”）和部署到所有服务器之前进行监控或使用blue-green deployment来保护其正常运行时间。一旦部署了代码，就可以通过仅为一部分用户翻转功能标记来进一步对冲一个人的赌注，并在将该功能公开给所有用户之前再次进行监控。