Azure DevOps的最佳实践-管理相关举措的回购

Question

我在我的组织内创建了一个开发团队，我们在一个单一的Azure DevOps项目下管理我们的所有计划。为了澄清，我试图避免在这里使用“项目”一词，以防止与ADO项目术语混淆，所以我在这篇文章中使用了“倡议”。

随着时间的推移，我们希望保持大量的计划(可能是数百个随着时间的推移)，因为我们迎合整个公司的许多集团。我们的一些计划将彼此高度相关，但在提交历史方面应该独立管理。对于相关的倡议，我们更愿意管理他们在一个单一的回购，但分开到不同的文件夹。例如，我们可能有一个dll，它将被许多类似插件的应用程序大量利用。如果可能的话，dll和插件应用程序最好保持在与子回购相同的Repo中。此外，还将有许多类别的相关举措，将由其他回购办公室主办。

我的问题是，在Azure Repos中，维护大量计划的最佳实践是什么，有些是相关的，有些是无关的？我读过一些关于Git子模块的内容，但我很难弄清楚如何在Azure Repos中制作/管理杰出的子模块。这是最好的方法，还是在ADO中是可能的？或者，更好的做法是为每个计划使用独立的repos，并尝试通过预定的命名约定对其进行分组，只需调用管道中的多个存储库？

提前感谢！我对ADO比较陌生。

Answer 1

我同意mason的观点，子模块可能很复杂，值得付出努力。

假设您正在开发web应用程序。

存储库"AwesomeApp“包含需要编译成生产代码的代码。

您可以创建实用程序"UtilitiesRepo“的回购。

这种回购永远不会公开，只为您的方便而存在。

在"UtilitiesRepo“下，您将有一些类似于以下结构的结构：

scripts/
development_build/AwesomeApp/
.gitmodules
azure_pipelines.yml

目录"development_build“将成为使用子模块的"AwesomeApp”的顶层副本。

在"UtilitiesRepo“的顶层，.gitmodules将拥有所有的信息来提取"AwesomeApp”的副本，以供构建/测试之用。

[submodule "AwesomeApp"]
    path = "development_build/AwesomeApp"
    url = https://dev.azure.com/AwesomeApp
    branch = CurrentDevBranch

使用命令填充development_build/AwesomeApp：

git submodule update --init
Submodule path 'development_build/AwesomeApp': checked out 'CurrentDevBranch'

现在，所有文件的副本将处于development_build/AwesomeApp/

如果"AwesomeApp“需要库，您可以将其作为子模块添加，因为development_build目录只是其他repos副本的占位符。

只需将其添加为子模块，您的“脚本”就可以访问和构建/测试这两个模块：

development_build/AppLibrary/
development_build/AwesomeApp/