在git/visual studio解决方案中放置应用程序服务器的位置

我有一个VisualStudio解决方案，其中包含一些（大约20个）项目。用于此解决方案的源代码管理是git

这些项目是围绕现有的应用程序服务器构建的（封闭源代码，仅二进制）。应用服务器由大约300个文件/140 mb组成。应用服务器的版本一年可以更改6次（如果需要新功能/错误修复） 开发人员需要此应用程序服务器来测试（集成测试）开发

大多数项目都引用了此应用程序服务器的某些程序集（即，为了建立连接）。大约有15个文件，我们为其创建NuGet包，这些包由我们自己托管

一些项目可能会参考官方的nugget软件包

某些项目可能引用了第三方程序集，这些程序集位于“lib”文件夹中，并且是解决方案的一部分。lib文件夹也是git存储库的一部分

问题: 我们应该将应用程序服务器文件放在何处以及如何放置

第1版： 放入lib文件夹旁边的app文件夹，并将其添加到git存储库中

• 赞成：开发者只需git签出，就可以启动应用程序了 服务器。开发者可以离线工作
• 缺点：git中有很多二进制文件 存储库。将产生一个巨大的git存储库

第2版： 将robocopy脚本放入构建后事件，并在成功构建后从网络共享或internet复制应用程序服务器

• 赞成：开发人员只需git签出、构建解决方案，就可以 启动应用服务器。Git存储库将保持轻量级
• 缺点：开发者需要连接到网络/互联网， 否则，构建后事件将失败，因此整个 构建将失败。如果开发人员签出了很多代码，那么速度会很慢 不同的分支，因为它将下载应用程序服务器 每次结账

我们应该使用上述版本之一吗？

---

有没有其他的可能性/最佳实践来解决这种情况？

您应该使用工件存储库。这正是工件库的用途：“源代码控制”专门用于二进制工件

我没有使用NuGet工件的经验，但我从JFrog那里看到了这一点。关于这一点，有一个正反两方面的答案

---

虽然我通常更喜欢nexus而不是artifactory，但在这种情况下，这个问题中公认的答案为artifactory提供了一个令人信服的论据。

像@PaulHicks这样的工件库听起来很理想

但是，如果您没有时间、基础设施或专门知识来采取这种方法（开始），我谦恭地说，我认为您对140MB的容量有点过度考虑-您有点夸大了您注意到的缺点

缺点：git存储库中有很多二进制文件。将产生一个巨大的git存储库

…并且应该强烈地考虑只与版本1一起运行。

如果您已经在源代码库中使用引用的二进制文件维护了

Lib

，那么额外的140 MB对我来说似乎不是什么大不了的事情，特别是考虑到您注意到的巨大好处：

赞成：开发人员只需git签出，就可以启动应用服务器了。开发者可以离线工作

---

版本1的另一个好处（无可否认，通过采用工件库方法更新应用程序服务器包也会带来这一好处）是对解决方案使用的应用程序服务器版本有一个清晰的历史记录。

建议的版本1是可行的，这就是我想要的，稍加修改。我会将应用程序文件夹作为一个独立的repo进行管理，从而作为一个独立的repo进行管理

二进制文件的repo中的标记和版本控制既有将所有东西都准备好放在一个地方的优点，也可以自由轻松地切换到二进制文件的另一个版本进行测试

也就是说，如果我是一名在这种设置中工作的开发人员，我可能会忽略我自己关于子模块的建议，并按如下方式进行管理：

• git在我的机器上克隆二进制文件的应用程序repo 1
• git克隆dev repo并创建指向my app repo的（ignored2）符号链接

这样我就可以享受两个世界中最好的一个，代码和二进制文件分别进行版本控制，但我随时准备出发，因为两个repo的组合允许我离线工作，必要时拉和推

总之，我认为您应该只提供两个存储库。一个用于二进制人工制品，一个用于源代码，虽然您可以提供一个建议的“howto”蓝图，但您也应该让您的开发人员自由地用他们的创造力给您带来惊喜

---

1如果需要多个克隆或文件大小失控，我会使用
2

---

我已将此标记为答案，即使我必须首先评估这些产品。