3

我们已完成对 Octopus Deploy 的评估，并对我们在单个项目中的体验感到非常满意。现在我们正在将 Octopus Deploy 的使用扩展到多个项目，这一步为我们的 Octopus 体验带来了新的维度。所以我们必须验证以下断言：

  1. 虽然每个环境只有一个实例（例如 DEV、STAGE、PROD）会很好，但单个环境会限制同时发布：给定项目的发布会部署到共享相同角色的所有机器上，所以如果我们的生产环境由多台机器组成，但是我们其中一些必须运行不同的发布版本，那么我们不能只有 Prod 环境，我们需要将它分成几个组，例如 PROD_OSLO 和 PROD_BERGEN 这样我们才能在生产中发布新版本在奥斯陆。

  2. 机器角色在所有项目之间共享，因此如果一台机器在 STAGE 环境中有一个角色 web-server，那么任何项目的任何版本的 web 应用程序都将部署在这台机器上。这意味着如果不同的项目应该为他们的 STAGE 环境使用不同的机器，那么这可以通过创建不同的角色（proj1-web-server 和 proj2-web-server）或通过将 STAGE 环境一分为二（STAGE_PROJ1 和 STAGE_PROJ2）来实现. 我想知道这些替代方案之一是否有任何优势。

如果我忽略或误解了某些内容并且上述结论不正确，请详细说明。

4

1 回答 1

3

我在我的公司使用 Octopus 实施了部署系统，您的大部分问题都与我们分享。

关于第一点，我们正是这样做的。我们定义了CI、QA、Pre-Production并创建了三个独立的生产部署：Production Alpha、Production Beta和Full Production。Alpha 和 beta 包含完全生产的不同子集。

在将项目隔离到不同的物理服务器时，我们实现了多个角色。我们已经不再将机器标记为“IIS”或“SQL Server”，这听起来就像您所做的那样。我们的角色更加细化，并描述了机器提供的特定功能。

例如，我们的一个数据库服务器可能被标记为“DB-Sales-Reports”，而另一个可能被标记为“DB-Sales-Engine”。从功能上讲，这与您的建议相同，但我们对标签的含义施加了一些语义含义。

理想情况下，我希望看到的是支持允许部署步骤以实现“部署步骤目标的所有 M 角色”的机器为目标，而不是“任何 M 角色的当前行为”部署步骤目标"

于 2014-01-28T21:02:32.797 回答