减少变化很大的存储过程的冲突答案

【问题标题】：Reducing conflicts on stored procedure that changes a lot减少变化很大的存储过程的冲突
【发布时间】：2016-11-24 06:24:05
【问题描述】：

我有一个名为“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 来管理数据库架构

【问题讨论】：

标签： database stored-procedures sql-server-data-tools merge-conflict-resolution

【解决方案1】：

我们有一个类似的问题，我们有一个表需要进行大量更改，而其他开发人员的更改不兼容。关键是尽快将更改引入主开发分支 - 我不知道您的分支策略是什么，但我们有这个过程：

1 - 从 dev 创建一个分支
2 - 工作，到分公司签到
2a - 从开发者合并
3 - 合并到开发（在代码审查等之后）
4 - 合并到发布（测试后等）

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

2a 很有趣，你的分支越长，就越有可能发生冲突，但是如果你定期从 dev 合并到你自己的分支，合并更改就越容易。

我们在部署后构建中使用合并语句而不是 proc，但代码不是问题，而是工作方式:)

如果由于某种原因您无法轻松合并更改给很多开发者。

埃德

【讨论】：