Question

我有一个名为“populateProcessTypes”的存储过程，看起来像这样

Insert Into ProcessTypes(processTypeId, processCode, processName)
Select processTypeId, processCode, processName
From
(
Select 1 processTypeId, 'L_EMP' processCode, 'Load Employees' processName UNION
Select 2 processTypeId, 'L_CC' processCode, 'Load Cost Centres' processName UNION
Select 3 processTypeId, 'L_SUP' processCode, 'Load Supervisors' processName UNION
Select 4 processTypeId, 'R_CHK' processCode, 'Run Validation Checks' processName UNION
Select 5 processTypeId, 'R_CLN' processCode, 'Run Data Checks' processName
)

由于在自己的开发环境中创建新进程的开发人员数量增加，我们在合并到存储库时经常会遇到冲突或重写的重大更改。例如，一位开发人员将添加

Select 6 processTypeId, 'R_NEW' processCode, 'Run New Process 1' processName

另一个将添加

Select 6 processTypeId, 'R_OTH' processCode, 'Run Other Process' processName

，另一个可能会重命名一个进程：

Select 2 processTypeId, 'L_CC' processCode, 'Load Cost Centre Hierarchy' processName

我从未对数据加载到ProcessTypes表中的方式感到满意，但是当我们只有一个开发人员对此负责时，没有任何问题。使用当前的方法，开发人员最终花费太长时间与对方检查数据库中应该包含哪些内容以及不应该使用什么，或者他们只是粗心大意而且会被覆盖。

是否有更好的方法将所需的记录插入到ProcessTypes表中，以便在较少的冲突和覆盖中解决？

我能想到的一件事是为每个只插入一条记录的Process类型设置一个程序，但我确信那里有更好的解决方案。

我们使用SSDT来管理数据库架构

Answer 1

我们有一个类似的问题，我们有一个表，我们需要更改很多，其他开发人员的更改不兼容。关键是要尽快更改主开发分支 - 我不知道你的分支策略是什么，但我们有这个过程：

1 - 从dev
2 - 做好工作，在分支机构办理登机手续
2a - 从dev
3 - 合并到开发（代码审查等）
4 - 合并发布（测试后等）

当我们保持1到3之间的时间尽可能短时，我们告诉其他开发人员我们正在修改表格，我们没有看到任何问题。

2a很有意思，你的分支越长，你就越有可能发生冲突，但是如果你经常从dev合并到你自己的分支，那么合并更改就越容易。

我们在post deploy build上使用merge语句代替proc，但代码不是问题，它是工作方式：）

如果由于某种原因你不能轻易合并你的变化，我已经看到一些事情，比如给每个开发人员一个他们可以使用的数字范围，所以dev有1-1000,2有2000-2999等但这不能扩展很多开发人员。

版

减少存储过程中发生重大变化的冲突

1 个答案: