Team City针对多阶段部署的最佳实践是什么？

Question

我们有3个环境:

• 开发: Team City在这里部署Subversion在trunk上的提交.
• 暂存:用户接受在此处完成,对于作为候选版本的构建.
• 生产:当UAT通过时,会在此处部署传递代码集.

我们正在使用Team City,并且只对我们的开发环境进行持续集成设置.我不想为Team City所做的每个开发部署保存工件.我希望指定的人能够触发构建配置,将部署成功的开发部署到我们的登台服务器.

然后,我希望每个登台部署都能保存工件.当暂存部署通过UAT时,我想将该包部署到Production.

我不确定如何在Team City中进行设置.我正在使用6.5.4版本,我知道有一个"推广..."动作/触发器,但我认为这取决于保存的工件.我不希望每次都将开发部署保存为工件,但我确实希望运行登台部署的人能够指定要部署到登台的成功开发部署.

我知道可能有多种方法可以做到这一点,有最好的做法吗？您的设置是什么？为什么推荐它？

更新:

到目前为止我有一个答案,这是我们内部考虑的一个想法.我真的很想知道,如果任何人有部署到通过团队市本身,暂存/生产environemnt其中只有某些角色/许可人可以运行部署脚本来生产,而不必手动处理任何一个有点自动化的方式一种神器包.任何人？

更新2

我仍然有1天奖励赏金,我认为下面的答案没有回答我的问题,但重读后我发现我的问题不是我想的那样.

有没有办法使用Team City进行某种自动部署到临时/生产环境？

Answer 1

我想你实际上在这里问两个不同的问题; 一个是关于控制TeamCity构建的访问权限,另一个是关于工件管理的后勤.

关于权限,我假设您的意思是"只有具有特定角色/权限的人才能将部署脚本运行到生产",而您对Julien的回复是您可能不希望开发人员直接部署到生产但您确实希望他们成为能够看到项目中的其他构建.这可能也类似于Julien的情景,当时IT部门将这个过程从TeamCity"脱机"(或者只是IT正在做IT所做的事情并坚持他们必须使用一个单独的,完全低效的流程,因为"这就是我们这样做的方式" " - 不要让我开始吧!)

问题很简单,TeamCity中的所有权限都是针对项目而不是构建的,所以如果你有一个包含所有构建的项目,就没有能力将权限粒度应用于开发与生成构建.我以前用两种方式解决了这个问题:

1. 处理社交.每个人都知道他们的责任是什么,而且你没有运行你不应该运行的东西.如果你这样做,它会被审核并追溯到你.成熟时工作正常,责任明确,禁止遵守要求.
2. 创建单独的项目.我不喜欢这样做,但确实解决了这个问题.您仍然可以使用来自另一个项目的工件,这意味着您最终会得到一个包含构建的项目,这些构建部署到您希望所有开发人员访问的环境以及另一个项目到敏感环境的环境中.缺点是,如果生产构建失败,那么您可能需要支持的人将无法访问它!

关于工件管理,在开发构建中保留它们没有问题,只需定义一个清理策略,如果您担心容量,它只会保留最后X版本的工件.很多人都希望确定他们将相同的编译输出部署到每个环境中,这意味着一旦你构建它,你想保留它以供以后使用.

一旦您从开发部署中获得了这些文物,您就可以通过单独的构建将它们重新部署到其他环境中.你会遇到配置转换的问题(假设你正在使用它们),但是请阅读这个2部分系列文章,了解如何解决这个问题(我还没有详细介绍它,但我相信他已经开始了正确的轨道).

这是否回答你的问题？还有什么遗失吗？

Answer 2

我们还使用TeamCity作为构建服务器,所以让我解释一下我们的设置.我们有4个环境

• Dev用于验证服务器环境中的提交的开发
• QA用于测试目的
• 部署检查的暂存和一些UAT
• 生产

我们只使用TeamCity部署到开发(夜间构建)和QA(按需).Dev构建使用trunk分支,QA构建使用用于RC的不同分支.

部署到分段和生产由IT团队管理,因此不是自动化的.

我们所做的是我们使用TeamCity从QA构建中生成工件.工件是为临时/生产部署发送的部署工具包.

也就是说,我不确定TeamCity是否会为您提供完全控制哪些构建可以提升到哪个环境.我们基本上使用分支在SVN端控制它,并为这些分支具有不同的构建.你可以(应该)以同样的方式管理它.因此,您可以确保部署的内容.

我知道您的需求可能与我们的需求略有不同,但我希望这有助于您找到最佳设置.