相关疑难解决方法(0)

是否有“最佳实践”类型的过程供开发人员遵循以进行数据库更改?

将数据库更改从开发环境迁移到 QA 到生产环境的好方法是什么?目前我们:

  1. 在 SQL 文件中编写更改脚本并将其附加到 TFS 工作项。
  2. 工作经过同行评审
  3. 当工作准备好进行测试时,SQL 在 QA 上运行。
  4. 作品经过 QA 测试
  5. 当工作准备好进行生产时,SQL 将在生产数据库上运行。

问题在于它非常手动。如果开发人员忘记了,它依赖于开发人员记得附加 sql 或同行评审员捕获它。有时,最终发现问题的是测试人员或 QA 部署人员。

第二个问题是,如果两个单独的任务更改同一个数据库对象,您有时最终需要手动协调更改。这可能只是它的方式,但似乎仍然应该有一些“标记”这些问题或其他东西的自动方式。

我们的设置:我们的开发商店充满了具有丰富数据库经验的开发人员。我们的项目非常面向数据库。我们主要是一家 .NET 和 MS SQL 商店。目前我们正在使用 MS TFS 工作项来跟踪我们的工作。这对于代码更改非常方便,因为它将更改集链接到工作项,因此我可以准确地找出在迁移到 QA 和生产环境时需要包含哪些更改。我们目前没有使用 DB 项目,但将来可能会切换到该项目(也许这是答案的一部分)。

我非常习惯于我的源代码控制系统为我处理这样的事情,并希望我的 SQL 也有同样的事情。

sql-server-2008 process source-control

31
推荐指数
2
解决办法
1763
查看次数

标签 统计

process ×1

source-control ×1

sql-server-2008 ×1