为Octopus Deploy中的多个项目定义角色和环境

Question

我们已经完成了对Octopus Deploy的评估，并对我们在单个项目上的经验感到非常满意。现在我们将Octopus Deploy的使用扩展到多个项目，这一步为我们的Octopus体验带来了新的层面。因此，我们必须确认以下断言：

1. 虽然这将是巨大的，有每个环境的一个实例（例如DEV，舞台，PROD），一个单一的环境使同时发行的约束：中释放给定的项目被部署到共享相同角色的所有机器上，所以如果我们的生产环境由多个机器组成，但我们其中一些必须运行不同的发行版本，那么我们不能只有Prod环境，我们需要将其分割成几个团体，例如PROD_OSLO和PROD_BERGEN，所以我们只能在奥斯陆发布新版本。

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

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

Answer 1

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

关于第一点，我们正是这样做的。我们已经定义了CI，QA，预生产和创建三个独立的生产部署：生产阿尔法，产生β-和全部生产。 Alpha和Beta包含完整产品的不同子集。

当涉及到将项目分隔到不同的物理服务器时，我们实现了多个角色。我们已经将标签计算机视为“IIS”或“SQL Server”，因为它听起来就像你一样。我们的角色更细化，并描述机器提供的特定功能。

例如，我们的一个数据库服务器可能被标记为“DB-Sales-Reports”，另一个可能被标记为“DB-Sales-Engine”。在功能上，这与你的建议是一样的，但我们在上强加了一些意义上的含义，即标签意味着什么。

理想情况下，我希望看到的是允许部署步骤将目标机器实现为“我部署了目标的所有M角色”，而不是“任何部署步骤目标中的M角色“