您是否应该将所有工件保存在同一个存储库中?

我很惊讶地在最近的在线讨论中读到一些帖子，其中一些主要来自软件测试背景的人开始考虑将他们的测试脚本保存在与生产应用程序代码相同的源代码存储库中。讨论的灵感来自一篇文章由测试自动化专家安吉琼斯．

我了解到测试人员和测试自动化专家长期以来一直分别维护测试脚本，这是基于测试脚本和应用程序代码是两个不同的东西的想法。他们中的大多数人从来没有想到在同一个存储库中维护测试脚本和应用程序代码。

在同一个讨论线程中，主要来自于编程背景的人反复地表示，基于产品是正常的，并且更可取的是将所有产品工件放在一起一个的事情。他们大多数人从来没有想到过不将测试脚本和应用程序代码保存在同一个存储库中。

事实上，将产品工件放在一起的想法并没有结束于测试脚本。每一个与产品相关的工件类型应该一起维护和版本管理。检查与应用程序代码的给定版本配套的服务器供应脚本的版本、最终用户文档的相应版本以及测试用例的相应版本，难道没有意义吗?为什么不会你这样做呢?

运动

圣徒之一精益废物是运动．它指的是工人更换工具或执行任务时的动作。在一个精益生产单元中，最常用的工具就在手边，通常放在一个阴影盒中，这样每当工人需要工具时，每个工具都能在完全相同的地方找到。类似地，单元格所消耗的任何部件或组件都在附近，以最小化运动找到东西并把它们放到合适的位置去工作是必要的。

软件交付的类似原则是将所有必要的电子工件组织起来，并以一种方式存储，使需要它们的团队成员能够随时使用它们。从版本控制中检出一个项目应该是可能的，而不必担心随后必须追踪多个数据存储中的各种工件，比如wiki、SharePoint站点、共享网络驱动器、测试工具，或者从生产服务器复制它们。当您将项目从版本控制中签出时，您就拥有了对其进行工作所需的一切。

但仍…

也就是说，“为什么?不会你这样做呢?“不是修辞。一些解决方案可能有实际的限制，排除它。另一方面，在很多情况下，当人们说这是不可行的，那是因为他们没有跳出框框思考。

例如,考虑一个解决方案,对iOS和Android移动组件,为物联网设备嵌入代码,编写的web前端,说,React.js甚至像Java或c#更传统的堆栈,一块中间层托管在一个应用服务器(如IBM WebSphere或jBoss,和一个后端运行在IBM环球或惠普不间断。

它甚至是可能的要在单个版本控制存储库中维护所有这些组件的源代码，以及测试套件、配置和配置脚本、文档?它可能是可能的，但这肯定不是人们习惯做的事。除此之外，也可能不是最优如果涉及多个开发团队，他们往往在大多数时间内彼此独立地工作，他们可能位于彼此之间的远程位置。

结论

为什么不能在单个存储库中管理所有工件，存在潜在的、真实的和可感知的原因。然而，在大多数情况下，这样做是相当可行和有益的。这是值得通过你的情况的细节努力推理并尽量减少运动对于您的开发团队。你可能会发现它在很多情况下比你想象的更可行。