与 Glennular 一样,我们使用它们来控制我们的架构和 s'procs 的版本。
虽然我们有一个相当先进的版本控制结构(CI、自动部署到 dev、单击部署到 stage 和 prod);我们不包括该结构中的任何数据库项目。我们只是还不相信它。
更新:(用于太空中)
我们针对公司的职能领域(销售、营销等)有单独的 TFS 项目。在每个 TFS 项目中,我们都有一个 Main 和 Production 文件夹。我们还有一个包含数据库项目的 TFS 项目和另一个包含通用程序集/Visual Studio 项目的 TFS 项目。
发布后,我们从 Main 分支到 Production。我们没有临时分支,因为我们行动太快而无法处理。对与错,我们的生产力部分是由我们每周发布的生产级别的数量来衡量的;错误修复、新功能等。
CI 设置在 Main 分支上,这样每次签入都会导致 Build 服务器部署到我们的 DEV 环境中。然后运行单元和 Web 测试,如果成功完成,构建质量会自动设置为“开发”。当有人将构建质量更改为“暂存”时,这会导致任何先前的“暂存”构建被设置为“拒绝”,并导致该构建被推送到我们的暂存服务器,同时更新配置文件以指向正确的服务器。 (为此我使用了 TFS Deployer 和 PowerShell 脚本)。
QA 会在我们的暂存服务器上进行测试。一旦他们满意,生产团队就会将构建质量更改为“生产”。这会导致构建被发送到生产区域,然后手动复制到正确的位置。完成后,生产会通知开发人员,然后开发人员将该版本分支到生产文件夹中。 QA 也会收到通知,然后谁会进行一系列生产测试,以验证一切确实按预期工作。
我们设置了报告,以向我们展示生产版本之间存在哪些更改,以便我们了解正在部署的每个签入。这可以防止出现未知数,例如数据库更改等或其他一些潜在的破坏代码。
此外,我们的 BA 正在通过 Team System Web Access 跟踪工作项目,并了解这些项目何时投入生产。
尽管我们的 DBA 使用的是 Database Edition (GDR),但他们对自动部署的控制水平并没有留下深刻印象。我希望 Rosario 能够为产品线带来更好的部署控制;但在那之前,我们有 TFS Deployer 和 powershell。