我们有3个环境：
-
Development: Team City在这里部署Subversion在trunk上提交 .
-
Staging: 用户接受在此处完成，对于作为候选发布版本的构建 .
-
Production: 当UAT通过时，会在此处部署传递代码集 .
我们正在使用Team City，并且只对我们的开发环境进行持续集成设置 . 我不想为Team City所做的每个开发部署保存工件 . 我希望指定的人能够触发构建配置，将部署成功的开发部署到我们的登台服务器 .
然后，我希望每个登台部署都能保存工件 . 当暂存部署通过UAT时，我想将该包部署到Production .
我不确定如何在Team City中进行设置 . 我正在使用6.5.4版本，我知道有一个“推广...”动作/触发器，但我认为这取决于保存的工件 . 我不希望每次都将开发部署保存为工件，但我确实希望运行登台部署的人能够指定要部署到登台的成功开发部署 .
我知道可能有多种方法可以做到这一点，有最好的做法吗？您的设置是什么？为什么推荐它？
Update:
到目前为止我有一个答案，这是我们内部考虑的一个想法 . 我真的想知道是否有人通过Team City本身部署到临时/ 生产环境 环境的方式有点自动化，只有具有某些角色/权限的人才能运行部署脚本进行 生产环境 而不必手动处理任何一种神器包 . 任何人？
Update 2
我仍然有1天奖励赏金，我认为下面的答案没有回答我的问题，但重读后我发现我的问题不是我想的那样 .
有没有办法使用Team City进行某种自动部署到临时/ 生产环境 环境？
3 回答
我想你实际上在这里问两个不同的问题;一个是关于控制TeamCity构建的访问权限，另一个是关于工件管理的后勤 .
关于权限，我假设您的意思是"only people with certain role/permission can run a deploy script to production"，您对Julien的回应是您可能不希望开发人员直接部署到 生产环境 ，但您确实希望他们能够在项目中看到其他构建 . 这可能也类似于Julien 's scenario when IT then take the process 2723666 from TeamCity (either that or it'只是IT正在做IT所做的事情并且坚持要求他们必须使用一个单独的，完全低效的流程，因为"that's just the way we do it" - 不要让我开始这个！）
问题很简单，TeamCity中的所有权限都是针对项目而不是构建的，所以如果你没有能力将权限粒度应用于开发与生成构建 . 我以前用两种方式解决了这个问题：
处理社交问题 . 每个人都知道他们的责任是什么，你不应该跑 . 如果你这样做，那就是成熟，明确责任，而不是遵守要求，禁止它 .
创建单独的项目 . 我不喜欢这样做，但确实解决了这个问题 . 您仍然可以使用来自其他项目的工件，这意味着您最终会得到一个包含构建的项目，这些构建部署到您无法访问它的环境中！
关于工件管理，在开发构建中保留它们没有问题，只需定义一个清理策略，如果您担心容量，它只会保留最后X版本的工件 . 很多人都希望确定他们将相同的编译输出部署到每个环境中，这意味着一旦你构建它，你想保留它以供以后使用 .
一旦您从开发部署中获得了这些文物，您就可以通过单独的构建将它们重新部署到其他环境中 . 你'll have an issue with config transforms (assuming you'正在使用它们，但是有一些关于如何解决这个问题的想法this 2 part series（在正确的轨道上我是'm yet to absorb it in detail but I believe he'） .
这是否回答你的问题？还有什么遗失吗？
我们还使用TeamCity作为构建服务器，所以让我解释一下我们的设置 . 我们有4个环境
Dev用于验证服务器环境中的提交的开发
QA用于测试目的
用于部署检查的暂存和一些UAT
生产环境
我们只使用TeamCity部署到开发（夜间构建）和QA（按需） . Dev构建使用trunk分支和QA构建使用用于RC的不同分支 .
部署到分段和 生产环境 由IT团队管理，因此不是自动化的 .
我们所做的是我们使用TeamCity从QA构建中生成工件 . 工件是为临时/ 生产环境 部署发送的部署工具包 .
也就是说，我不确定TeamCity是否会为您提供完全控制哪些构建可以提升到哪个环境 . 我们基本上使用分支在SVN端控制它，并为这些分支具有不同的构建 . 你可以（应该）以同样的方式管理它 . 因此，您可以确保部署的内容 .
我知道您的需求可能与我们的需求略有不同，但我希望这有助于您找到最佳设置 .
我想你可能想看看像Octopus Deploy或BuildMaster这样的东西 . 它们为您尝试自动化的部署实践提供了一个很好的结构 . 这两个工具都很好地与TeamCity集成 .
基本上，您将继续使用TeamCity for CI，您也可以继续使用TeamCity部署到您的开发环境，但您可以使用其中一个部署工具将（现有）构建升级到分段和 生产环境 .
编辑2014-02-05 - 更新
BuildMaster的制造商为他们的NuGet服务器工具ProGet提供了新的部署功能 - ProGet Deploy . 它自己也玩过它，所以Octopus可以更好地可视化已经部署到哪些环境的版本;由于这一重要特性，我仍然使用BuildMaster .
此外，我目前正在使用TeamCity，BuildMaster和ProGet，我从不想回到没有自动构建 . 目前，我的所有应用程序都是通过BuildMaster构建和部署的 . 我的所有库项目都在TeamCity中构建并部署到ProGet . 能够通过NuGet基础设施管理我的内部依赖关系是很好的 .