产品发布标签的最佳实践

Question

我们有一个(历史上成长的)存储库结构(在我们的例子中使用Subversion)，如下所示：

trunk/
  Product1/
  Product2/
  Product3/
  Product4/
  CommonDependencyOfProduct1and2/
  SomeStructuringFolder/
    CommonDependencyOfProduct1and3/
    CommonDependencyOfProduct2and3/
  ...

当为没有共享依赖关系(Product4)的产品标记发布时，一切看起来都很直接，我们只需从主干/产品4创建一个标记，并完成它。

但是，当我们发布其他产品之一时，我们还必须标记共享的依赖项。我认为有以下几种选择：

1. 创建整个存储库的标记
   • 支持:易于自动化，标签遵循主干结构。
   • CON:将包括(不一定是明显的)不相关的产品，使之不清楚什么实际上属于发行版，哪些不属于(对于QA文档来说很难看)。

​

1. 创建整个存储库的标记，然后删除所有不相关的文件夹
   • 支持:没有包含无关的代码，标记仍然遵循主干结构。
   • CON: Afaik，修改标签仍然被认为是非常糟糕的做法。同时，也很难实现自动化(需要维护需要保存或删除的产品列表)。

​

1. 在标记/部分中预先创建一个新的、空的发布顶层文件夹，然后将已发布的项目及其所有依赖项创建为子文件夹 。
   • 支持:不包括不相关的代码，仍然相对容易自动化。
   • 标签不再反映主干结构。另外，将不同的部分复制到新文件夹中仍然可以算作标记的修改。

​

第四种选择是将每个组件转移到一个单独的存储库中，但是会对我们的基础设施造成很大的干扰，所以我想先权衡一下备选方案。

同样的问题在某种程度上也适用于工作分支的创建。只有在那里，我们通常不太关心修改或包含不相关的代码，所以选项1或2通常是可以接受的。

Answer 1

这个怎么样：

1. 创建特定于产品的分支，例如/分支/产品1、/分支/产品2等等
2. 在这些分支上进行开发。每当特定产品的发布准备就绪时，从分支创建产品发行版的标记，然后将该分支合并到/trunk。这样，您的主干将始终有发布就绪的代码，没有不必要的代码。此外，产品发布特定的标签将在未来的方便。
3. 发布合并，创建整个/trunk的特定于发行版的标记。

这可行吗？尽管它会增加分支间频繁合并的开销。同样，正如您已经提到的，对于有不同版本的产品，总是有不同的回复。这将是容易的规模和自动化。