我的组织正在组建一个自动化团队,我们仍在研究结构和过程。有些人觉得我们应该将所有自动化代码放在一个存储库中,而另一些人则认为我们应该将代码分成多个存储库。它用于任务关键型第三方软件,其动作可能会诱使某些内部设计的流程执行某些操作。其中大多数是各种第三方应用程序之间的集成层。整个软件生态系统非常庞大,具有多种多样且大多是第三方应用程序。结果,每个应用程序的框架之间几乎没有共享代码。 。但是,在任何情况下,我们都无法一次运行所有测试。 。

另外,将有6个自动化开发人员,大多数时候,对于小型应用程序,每个开发人员都是唯一的一个在特定应用程序上工作的开发人员。但是对于较大的应用程序,可能需要进行两个或多个操作。

我同意我有单独的存储库的说法吗?你能给我优点和缺点吗?

#1 楼

一次运行所有测试是Continuous Integration服务器应该为您执行的操作,而不是您手动执行的操作,因为它会让您等待很长时间。让服务器来做工作和报告。

多个仓库具有以下优点:


更容易在CI中安排并行运行。会更快。 (在技术上也可以使用单个存储库,但难度更大)
更小,因此可以更快地与大多数IDE一起使用(因为它们经常扫描所有文件)这需要更多解释。如果更新公共共享代码,则只有一个存储库需要更新所有应用程序。例如,如果您测试了一个不再需要更新的应用程序,则可以使用旧版本的共享代码,但是如果您有一个存储库,则需要更新所有代码以对公共共享代码进行新更改。 。 (我认为这一点对您可能很重要,因为从长远来看,这会减少维护工作)。



测试人员可能需要保持数十个甚至更多的仓库都可以一直更新。好像是一个单一的结构。您还可以使用git创建子模块或子树,就好像它是单个存储库一样,也许值得研究。
增加了共享代码库和版本控制的复杂性。带有子文件夹的文件夹。

YAGNI:您可以在以后确实有实际需要时再分离代码。

中性:


由于git非常适合分支机构,因此只要您每天与master合并,多个测试人员就不会互相影响太多。

我的看法:

就我个人而言,我希望为每个应用程序提供一个仓库,因为我想使用该应用程序对测试进行版本控制。使该应用程序的代码库保持简单,我知道我只有我需要的代码,这使得清理和删除已过时的代码变得更加容易。

但是我始终主张使用YAGNI方法,该方法建议从可能首先起作用的最简单的事物开始,因为它可能已经足够好了。仅在确实需要时才增加复杂性。我会尝试其中一种,并定期进行评估并根据需要进行调整。不是一个阻止另一个。您始终可以在以后的阶段中进行拆分或合并,只需对此更改保持开放,并稍加添加即可。

评论


我喜欢您在这里布置的专家,尽管我们最终只完成了一个回购协议,但我认为他们对我们来说是规范性的,至少现在是这样。

–基思·泰勒(Keith Tyler)
17年6月19日在19:16

#2 楼

这取决于。

现在,您可能看不到对单个存储库设计的太多需求。稍后,您可能会发现自己的观点有所改变。

如果需要保持不同项目的同步,则可能要使用单个存储库。与单个存储库相比,保持单独的存储库同步更加困难。
您的团队成员将需要在项目之间进行切换,尤其是如果他们必须定期进行切换时。切换项目的成本非常可观,无需增加确保遵循正确的源绑定的需求。
您需要能够快速查看所有项目的分支。当您拥有一个存储库时,这比需要为多个存储库获取最新版本要容易得多。
您需要保持分支同步。在管理多个存储库时,保持一致的分支策略要复杂得多。

如果您不使用


,则可能要使用多个存储库并且不再需要重复使用来自不同存储库中一个存储库中的代码。
每个团队成员将大部分时间都花在一个存储库中
,您无需使用集中式连续构建/连续部署过程(并且您没有预见到这一过程),或者您可以为每个项目创建一个单独的连续构建/部署环境。 >您可以完全沙盒化并隔离每个项目。

可能归结为大多数团队成员可以采用的策略。从一个单一的存储库开始并根据需要拆分新的存储库可能比在另一个方向上移动要容易得多,但是在任何一个方向上确实没有很多重大问题。我列出的所有因素主要是为了方便。

#3 楼

添加到真棒和非常详细的现有答案。有一个使用单个大型存储库(Facebook和Google)的成功案例。截至2014年,Facebook的主存储库大小为54 GB。截至2016年,Google的主要存储库已拥有3500万次提交。如果功能包含对多个项目所做的更改,则可以通过一次提交来完成。

其他一些优点: >统一的版本控制和依赖性管理
团队之间更大的协作,代码共享和重用

由于规模大,这两家公司当然都是特例,但我们可以从中吸取一些教训他们如何组织,维护和存储代码。

有关单个大型存储库的后续阅读:Git中的Monorepos

Google Is 2数十亿行代码-一站式全部处理
单片版本控制的优点

在Facebook上扩展Mercurial(多年来对mercurial进行了很多改进)


#4 楼

我会应用KISS和YAGNI的原则:保持简单,您将不需要它。

从一个开始,当您看到业务需要它和好处时,将其拆分为单独的存储库。

我同意@KatePaulk的优缺点,但是如果没有明显的好处,我会采用更简单的解决方案:单一存储库。