我们有三个环境:
- Development: Team City在这里进行Subversion提交。
- Staging:用户验收在这里完成，在发布候选版本上。
- 生产:当UAT通过时，通过的代码集部署在这里。
我们正在使用团队城市和只有持续集成设置与我们的开发环境。我不想为Team City所做的每个开发部署保存工件。我希望指定的人员能够触发构建配置，将某个成功的开发部署部署到我们的登台服务器。
然后，我希望每个阶段部署都保存工件。当阶段部署通过UAT时，我想将该包部署到生产环境。
我不确定如何在团队城市中设置这个。我使用6.5.4版本，我知道有一个"促进…"动作/触发器，但我认为这取决于保存的工件。我不希望每次都将开发部署保存为工件，但是我确实希望运行阶段部署的人能够指定将哪个成功的开发部署部署到阶段。
我知道可能有多种方法来做到这一点，有没有最佳实践?你的设置是什么?你为什么推荐它?
更新:
到目前为止，我有一个答案，这是我们内部考虑过的一个想法。我真的很想知道是否有人有一种通过Team City本身自动部署到阶段/生产环境的方法，只有具有特定角色/权限的人才可以将部署脚本运行到生产环境，而不必手动处理任何类型的工件包。有人知道吗?更新2
我还有1天的时间奖励赏金，我认为下面的答案没有回答我的问题，但重读后我发现我的问题不是我想的那样。
是否有任何方法可以使用Team City进行某种自动部署到登台/生产环境?
我想你实际上问了两个不同的问题;一个是关于控制访问TeamCity构建的权限，另一个是关于工件管理的物流。
关于权限，我认为你所说的"只有具有特定角色/权限的人才能将部署脚本运行到生产环境"的意思是，你对Julien的回应是，你可能不希望开发人员直接部署到生产环境，但你确实希望他们能够看到项目中的其他构建。这可能也类似于Julien的场景，当IT将流程从TeamCity"脱机"时(要么是这样，要么只是IT做IT做的事情，并坚持他们必须使用一个单独的，完全低效的流程，因为"这就是我们做它的方式"—不要让我开始!)
问题很简单，TeamCity中的所有权限都适用于项目，而不是构建，所以如果您有一个包含所有构建的项目，则无法将权限粒度应用于开发与生产构建。我以前用两种方式处理过这个问题:
- 社交化处理。每个人都知道自己的责任是什么，你不应该去做你不该做的事。如果你这样做了，它会被审计并追溯到你。当有成熟的，明确的责任概念和不禁止它的合规性要求时，工作就可以了。 创建单独的项目。我不喜欢这样做，但是确实解决了这个问题。你仍然可以使用来自另一个项目的工件，这意味着你只需要一个项目包含部署到所有开发人员都可以访问的环境中的构建，而另一个项目则需要部署到敏感的环境中。缺点是，如果生产构建失败，您可能希望获得支持的人将无法访问它!
关于工件管理，在开发构建中保留它们没有问题，如果您担心容量，只需定义一个清理策略，仅保留最后X构建中的工件。很多人都想确保他们在每个环境中部署相同的编译输出，这意味着一旦你构建了它，你就想保留它以供以后使用。
一旦您从开发部署中获得了这些构件，您就可以通过单独的构建将它们重新部署到其他环境中。你可能会遇到配置转换的问题(假设你正在使用它们)，但是请阅读这个由2部分组成的系列文章，了解如何解决这个问题(我还没有详细了解，但我相信他在正确的轨道上)。
这样回答你的问题了吗?还缺什么吗?
我们还使用TeamCity作为构建服务器，所以让我解释一下我们的设置。我们有4个环境
- Dev用于在服务器环境中验证提交的开发
- 用于测试的QA
- 用于部署检查和一些UAT的暂存 生产
我们只使用TeamCity部署到开发(夜间构建)和QA(按需)。Dev构建使用主干分支，QA构建使用用于RC的不同分支。
部署到阶段和产品是由IT团队管理的，因此不是自动化的。
我们所做的是使用TeamCity从QA构建中生成工件。构件是为登台/生产部署而发送的部署工具包。
也就是说，我不确定TeamCity是否会为您提供一个完全控制哪个构建可以提升到哪个环境的功能。我们基本上在SVN端通过分支来控制这个问题，并且对这些分支进行不同的构建。你完全可以(应该)用同样的方法处理这件事。因此，您可以确保正在部署的内容。
我知道你们的需求可能与我们的略有不同，但我希望这将帮助你找到最好的设置。
我想你可能想看看像Octopus Deploy或BuildMaster这样的东西。它们为您试图自动化的部署实践提供了一个很好的结构。这两个工具都可以很好地与TeamCity集成。
基本上，您将继续使用TeamCity进行CI，并且您也可以继续使用TeamCity部署到您的开发环境，但是您将使用其中一个部署工具来将(现有的)构建推广到阶段和生产。
编辑2014-02-05 -更新
BuildMaster的制造者有一个新的部署功能- ProGet部署-为他们的NuGet服务器工具，ProGet。它与Octopus Deploy非常相似，虽然我自己还没有使用过它，所以Octopus可能会更好地可视化哪些版本已部署到哪些环境;因为这个重要的特性，我仍然在使用BuildMaster。
而且，我目前同时使用TeamCity、BuildMaster和ProGet，我再也不想回到没有自动构建的状态。目前，我所有的应用程序都是通过BuildMaster构建和部署的。我所有的库项目都是在TeamCity中构建并部署到ProGet中的。能够通过NuGet基础设施管理我的内部依赖很好。