并行工作和“分解变化”的分支策略
提问于 2015-01-21 01:12:53
我们有一个应用程序，历史上遭受了许多分支机构的攻击。
现在已经批准了这些协议，但是现在已经出现了这样一种情况:我们有两个开发流(理想情况下是一个)，其中一个流需要进行一些更改，实现它们将产生无法作为单个故事(或者可能是一个sprint)的一部分而固定的撞击效应。
例如，：是一个高数量的数据库模式更改，需要大量的查询逻辑更改。
这些更改不容易标记，因为它们会系统地破坏现有功能，直到工作完成为止。理论上，我们可以将系统恢复到“构建”状态，但这将阻止客户使用现有的功能。
为了解决这个问题，我们建议创建一个新的分支，用于“破坏更改”，这样其他的开发流就不会中断，并且可以间歇性地释放。
虽然我讨厌创建新的分支，但我现在找不到更好的方法来做到这一点。
是否有一种建议的实践，或者是管理分支策略，或者是架构保护，阻止并行开发中的变化？
编辑:我唯一想到的另一件事就是“复制粘贴”现有的功能(包括表/网页等)，将其重命名，并在同一分支中，在功能标志后面工作。这显然是相当混乱，有许多原因！
有没有人对他们过去如何处理这件事有任何建议？
回答 1
Stack Overflow用户
发布于 2015-01-21 09:02:14
您应该以增量的方式交付数据库模式(和其他更改)。不要一蹴而就，而是把它分解成你可以交付的东西。
如果您当前的应用程序体系结构不支持此模型，那么这是需要解决的第一个问题。
永远满足你的DoD为每一个斯普林特。所有的工作集成在一起，不需要更多的工作来装运.
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/28063355
复制相关文章
腾讯云开发者
