什么时候开始使用工具的下一次修订是合适的呢？

Question

具体来说，我正在开发一个集成DVCS和构建系统的工具，但我认为，对于任何开发“元”工具(编译器、VCS、构建系统、测试运行程序等)来说，我面临的挑战都会出现。他们希望通过“狗脚”进行开发。

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

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

• 经常使用该工具的develop版本:我发现随着变更的合并，我正在破坏自己的开发。
• 经常使用这个工具的master版本:我通过dogfooding发现的任何问题都已经发布了。

Answer 1

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

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

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

与团队协调这一点是很棘手的，但我认为这主要是允许任何人发起退步并交流原因的问题。在版本控制中，指定它的一种方法是使用类似于last_known_good分支的方法，在工作流中的develop和master之间。在你成功地完成一个构建之前，任何事情都不会被推到那里。

Answer 2

如果这个工具被用于生产高质量的软件(特别是如果它被递归地使用，即开发自己)，我会增加您的前期测试工作，并等待dogfooding，直到发行版足够稳定，您很有信心您不会通过使用它来破坏生产代码。

如果你必须等待主版本有这种程度的信心，那么就这样吧。

Answer 3

Git也是这样的工具，而且很明显，它也是做狗踢的。但在不同的环境中，它的作用是不同的。公共服务器只运行发行版，而开发人员通常使用next ( git项目的名称为“developers”)或pu (开发比开发还要多)。任何被某些问题阻止的开发人员都可以返回到next或master或最后一个版本，只要它们被某些东西阻塞，并且主存储库不受影响，那么就可以通过引用它来清除问题。

分支模型与上面的模型相似，名称略有不同。master是大版本所做的工作，maint是下一个发布版本的发布分支，next类似于开发，在下一个版本中而不是整个下一个版本被合并后，特性可以单独合并为掌握。

还有一个额外的分支，pu。这是通过将所有考虑集成到next的特性分支合并来创建的(每次都会丢弃该分支并重新创建)。IIRC只有通过测试套件才能发布。最后，我看了Junio，维护人员，运行脚本定期手工构建它，但这样的脚本可以通过持续集成夜间运行，我相信格瑞特甚至会自动创建它。

所以这就是答案。您在开发环境中拥有的开发版本最多，但是使用以前的版本来构建版本。