问题描述
我们正在开发一个基于Azure的分析平台，该平台由多个模块组成。其中使用了Azure函数、用于创建基础架构的脚本以及用于初始化数据库结构（包括存储过程的创建）的脚本。
目前，仓库结构有些混乱，我被要求整理它，并为部署和更新平台的各个部分开发一种策略（我们目前每次发布都重新部署整个平台）。
在仓库级别上，最佳实践是什么？例如，我为每个Azure函数和相关的流水线创建一个单独的仓库，还是将它们全部放在一个公共仓库中，并尝试通过为每个Azure函数创建单独的发布分支来解决这个问题？
还有其他最佳实践方法吗？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
通常情况下，将所有内容放在一个仓库中通常不是错误或困难的方式。将项目拆分成多个仓库通常并没有太多好处，但这将取决于你的CICD引擎以及所使用的应用程序类型和技术栈。
最近我有一个项目有3个仓库。一个用于CLI应用程序，一个用于由CLI部署的基础架构，一个用于CLI应用程序和其他工具使用的库。
这看起来很简单，也是一个不错的选择，但CICD非常痛苦。
通常，一个新功能会跨越3个仓库。在CICD中尝试使其工作是不可能的。我更希望将基础架构和CLI放在一起，因为大多数新功能都会影响这两个代码库。
然后，我可以在CICD流水线中获取更改文件的列表，并决定是否需要测试基础架构。
当你将项目拆分成多个仓库时，另一个问题是如何对这些不同部分进行版本控制，并理解哪些版本与其他版本兼容等等。
总结一下，如果各个部分彼此依赖，请将它们放在同一个仓库中，因为这样可以帮助CICD流程。考虑一个应用程序及其底层基础架构。那么，我会将一个REST API和其客户端合并吗？可能不会，过去我只要求分支名称相同。因此，在CICD中，我会检查其他仓库是否有一个名为X的分支，如果有，则使用它，如果没有，则使用主分支。如果各个部分大多是独立的，比如一个库和使用它的应用程序，那么将它们分开。
方案2
将仓库拆分成多个较小的仓库没有一个简单的答案，如果仓库太大，每个分支随着时间的推移都会变得很大，如果仓库太小，你将不得不做很多管理工作。
我更喜欢许多较小的仓库，但前提是要创建一些支持脚本来为你处理管理工作。
例如，要拉取所有仓库：
ls -d **/ | xargs -P12 -I{} git -C {} pull
此外，git内置了一个用于仓库的功能，即子模块。
当一个仓库引用另一个仓库但不需要对其进行源代码控制时，它非常有用。它带有自己的一组命令。值得研究一下。
参考链接：https://git-scm.com/book/nl/v2/Git-Tools-Submodules
当仓库之间相互依赖但不需要进行源代码控制时，子模块非常有用。它带有自己的一组命令。值得研究一下。