我们已完成对Octopus Deploy的评估，并对我们在单个项目中的经验非常满意。现在我们正在将Octopus Deploy扩展到多个项目，这一步为我们的Octopus体验带来了新的层面。所以我们必须验证以下断言：
虽然每个环境只有一个实例（例如DEV，STAGE，PROD）会很棒，但是单个环境会产生同时发布约束：给定项目的发布部署到共享的所有机器上相同的角色，所以如果我们的生产环境由多台机器组成，但我们其中一些必须运行不同的发布版本，那么我们不能只有Prod环境，我们需要将它分成几组，例如PROD_OSLO和PROD_BERGEN因此我们只能在奥斯陆发布新版本。
机器角色在所有项目中共享，因此如果计算机在STAGE环境中具有角色Web服务器，则任何项目的任何版本的Web应用程序都将部署在此计算机上。这意味着如果不同的项目应该为他们的STAGE环境使用不同的机器，那么这可以通过创建不同的角色（proj1-web-server和proj2-web-server）或将STAGE环境分成两部分来实现（STAGE_PROJ1和STAGE_PROJ2） 。我想知道其中一种替代品是否有任何优势。
如果我忽略或误解了某些内容并且上述结论不正确，请详细说明。
答案 0 :(得分：3)
我使用Octopus在我的公司实施了部署系统，您和我们分享了您的大多数问题。
关于第一点，我们正是这样做的。我们定义了 CI ， QA ，预生产并创建了三个单独的生产部署：生产Alpha ，< strong>生产测试版和完整生产。 Alpha和beta包含完整制作的不同子集。
在将项目分离到不同的物理服务器时，我们实现了多个角色。我们已经远离标记机器，因为它们是“IIS＆＃34;或者＆＃34; SQL Server＆＃34;，听起来像你有。我们的角色更精细，并描述了机器提供的特定功能。
例如，我们的一个数据库服务器可能被标记为＆＃34; DB-Sales-Reports＆＃34;另一个可以被标记为＆＃34; DB-Sales-Engine＆＃34;。从功能上讲，这与你提出的建议相同，但我们在标签的含义上强加了一些语义含义。
理想情况下，我希望看到的是支持允许部署步骤定位一台机器，该机器满足部署步骤所针对的所有M个角色＆＃34;我标记了它，而不是＆＃34;部署步骤所针对的任何M角色的当前行为＃34;