狗食时何时开始使用该工具的下一个修订版？

具体来说，我正在开发一个将DVCS和构建系统集成在一起的工具，但是我想像一下，如果开发任何“元”工具（编译器，VCS，构建系统，测试运行器等）的人都将面临挑战。希望通过“狗食”发展。

我的问题是：在使用分支工作流的Scrum风格发布过程中，从什么时候开始在工具的开发周期中使用该工具的较新版本？

我正在寻找一种在以下两者之间建立平衡的过程：

• 不断使用该develop工具的版本：随着变更的合并，我正在打破自己的开发。

• 不断使用该master工具的版本：我通过狗食发现的所有问题都是已经发布的问题。

首先要做的是进行非常全面的自动化离线回归测试。使通过这些测试成为您正式使用的最低要求。

其次，您需要一种简单的方法来回退到以前的工作版本，以解决自动测试无法发现的问题。

例如，我的Linux内核进行了一段时间的自定义修补。我会在打算使用内核的同一台计算机上对内核进行修补和编译，这意味着如果我创建了一个错误的内核，我可能会失去开发环境。因此，我确保始终在GRUB菜单中保留一个已知的良好内核，因此，如果我犯了一个错误，则只需重新启动即可回到良好的开发环境。

与团队进行协调很棘手，但我想这主要是让任何人发起后备并传达原因的问题。在版本控制中，一种指定方法是在工作流last_known_good之间develop和master工作流中的某个位置（例如分支）。在成功完成构建之前，什么都不会推到那里。

如果使用此工具来生产具有生产质量的软件（尤其是如果以递归方式使用（即自行开发）），那么我会加大您的前期测试工作，然后等待测试，直到发布足够稳定为止非常有信心您不会通过使用它破坏生产代码。

如果您必须等待主版本具有该置信度，那就这样。

Git也是这样的工具，显然也可以进行狗食。但是它在不同环境中的影响程度不同。公共服务器只在运行发行版，而开发人员通常使用next（即git项目的名称为“ develop”）或pu（甚至比development还要多的开发）工作。受某些问题阻止的任何开发人员都可以在遇到某种问题并且主存储库不受影响时返回到next或master发布最后一个版本，因此可以通过引用它来清除问题。

分支模型与上面的类似，只是名称略有不同。master是大型发布的基础，maint是下一版本的发布分支，next类似于开发中的功能，只是功能已被合并到下一个而不是整个下一个被合并而稍有不同。

有一个额外的分支pu。这是通过将考虑集成的所有要素分支合并在一起next创建的（每次都丢弃并重新创建该分支）。IIRC仅在通过测试套件时才发布。最后，我看到维护者Junio正在运行脚本以手动进行定期构建，但是此类脚本可以通过每晚进行连续集成来运行，我相信Gerrit甚至可以自动创建它。

答案就是这样。您可以选择开发环境中拥有的大多数开发版本，但是可以使用以前的版本来构建发行版。

根据公认的答案，我将扩展分支工作流程以维护类似于以下内容的分支：

• master：release-*在关闭时合并
• dogfood分支机构master; 包括在狗食期间识别出的修复程序；从develop软件被认为“稳定”以供内部使用时开始合并；如果需要，可以将该分支的头部及时移回
• develop分支机构master; 包括正在进行的更改，错误修正dogfood以及feature-*分支与分支的合并
• feature-*分支机构develop; 包括对特定新功能的更改
• release-*：从dogfood软件被视为“稳定”供外部使用时分支；与合并之前包括文档更新和较小的错误修正master