将多个项目部件集成到一个GIT仓库中

Question

我有一些问题，这是情景：

• 我有一个很大的Sitecore CMS网站（Proj A），它有大量原生dll以及我们为了增强网站功能而创建的自定义网站。

• 自定义dll由我们手动编译的各个VS项目（Proj B，C＆amp; D）生成，然后将成品（dll）移动到Proj A bin目录。

• 我们目前拥有PROJ，Integration，Public的Proj A存储库以及每个开发人员通常克隆PROD副本以使用功能/修复。

• Proj B，C＆amp; D还没有在版本控制下设置，因为我们还没有找到一种方法可以轻松地将它的版本集成到Proj A. 使用集成管理器工作流，我们让每个人都进行他们的功能/修复，然后我们将其合并到Integration存储库。在这一点上，我们准备好了以下内容：

  1. 重新编译Proj B，C和＆amp; d
  2. Robocopy将文件从每个项目发布到Proj A bin文件夹
  3. 重新编译/构建Proj A并部署到Integration服务器。

问题：

1. 你会包括Proj B，C和＆amp; D在Proj A的目录结构中？如果是这样，在编译每个项目时，您是否会将每个项目的发布目录设为Proj A Bin目录？

2. 如何/何时自动化包含Proj B，C和＆amp; D“dll”进入Proj A bin目录。

3. 您能推荐一种简化这些文件集成的方法吗？

注意：我已经研究了Reps和子模块中的Reps，但不确定我是否只需要两者的混合。

任何建议都将不胜感激。 谢谢，祝你好运。 foxtrotzulu

Answer 1

1. 如果您创建了解决方案，则可以将您的网站/ webproject和其他项目添加到此解决方案中。如果你然后将网站/ webproject中的引用添加到那些“自定义dll”，那么dll应该被复制（默认情况下，否则这个iirc有一个选项）。

2. 如果他们特定于Proj A，我会自动化它们，如果它们是所有项目使用的内部API，实用程序等，我不会将它们包含在Proj A解决方案中。

   < / LI>

3. 不确定我是否会推荐这种方式，但是如果您自动构建了自定义DLL（使用CruiseBuild等），然后将其提交到存储库，则可以添加外部“更新”。但是，如果新的变化经常打破Proj A，这可能很容易成为一个问题。

这绝不是一个完整的提议，但可能是对你的问题的部分答案。

Answer 2

我们对ASP.NET Web应用程序有类似的情况，这取决于其他项目。

我们的解决方案是在单独的存储库中创建Web应用程序和每个依赖项作为单独的VS解决方案，然后将B，C，D的存储库定义为A存储库中的子模块。

A的VS解决方案包括子模块提供的项目B，C和D的副本，这些项目是A项目中的项目引用。

这解决了1和2，因为你可以按正常方式构建项目A，B，C和D将自动从源构建，并将DLL复制到A的构建目录中。

Answer 3

不知道这是否有助于任何人，只是想跟进我自己的问题：

问题：

你会包括Proj B，C和＆amp; D在Proj A的目录结构中？如果是这样，在编译每个项目时，您是否会将每个项目的发布目录设为Proj A Bin目录？

我们决定将proj A（Sitecore web）保存为Sitecore rCS文件夹中的单独存储库。 此文件夹包含存储库和DLLs文件夹： dll文件 dev1_PUBLIC dev2_PUBLIC dev3_PUBLIC INTEGRATION_STAGING PRODUCTION_STAGING

1. 要启动功能/修复所有开发人员安装一个vanilla Sitecore并执行PULL以从PRODUCTION_STAGING更新本地主人
2. 签出本地功能分支，根据故障单/项目命名。运行本地updateDll.bat以下载更新的dll。
3. 经常工作，经常提交，测试和验证
4. PUSH当地主人
5. 推送到“xxxx_PUBLIC”。
6. 联系Integration Manager，以便他/她可以从公共场所提升到INTEGRATION_STAGING。
7. IM拉到Integration（QA），运行本地updateDll.bat，通知dev继续测试与Sitecore或其他项目的集成
8. 如果验证测试，IM将安排PULL到PRODUCTION并运行本地updateDll，bat。如果生产良好，IM会将更改返回到PRODUCTION_STAGING，以便准备好新的副本。

我们决定让proj B，C和D（C＃组件）在dotNetProjects文件夹中的每个项目都拥有自己的存储库。 每个项目文件夹都包含许多存储库：     dev1_PUBLIC     dev2_PUBLIC     dev3_PUBLIC     INTEGRATION_STAGING     PRODUCTION_STAGING

1. 要启动功能/修复所有开发人员CLONE，请将PRODUCTION_STAGING的副本复制到本地PC。
2. 签出本地功能分支，根据故障单/项目命名。
3. 将项目点的输出文件夹验证为dotNetProjects项目中的“releasedlls”文件夹。经常工作，经常提交，测试，验证和构建项目。验证dll datetime戳。
4. PUSH当地主人
5. 推送到“xxxx_PUBLIC”。
6. 联系Integration Manager，以便他/她可以从公共场所提升到INTEGRATION_STAGING。
7. IM拉到Integration（QA），运行本地updateDll.bat，通知dev继续测试与Sitecore或其他项目的集成
8. 如果验证测试，IM将安排PULL到PRODUCTION并运行本地updateDll，bat。如果生产良好，IM会将更改返回到PRODUCTION_STAGING，以便准备好新的副本。

如何/何时自动化包含Proj B，C和＆amp; D“dll”进入Proj A bin目录？ 每个项目的输出文件夹设置为dotNetProjects / releasells文件夹，该文件夹不是存储库，只是一个容纳与SItecore相关的dll的文件夹。 向sitecore添加功能/修复的开发人员必须在本地运行updateDll.bat以获取最新版本的dll。这是一个简单的脚本：

xcopy /E /Y "\\servername\dotNetProjects\ReleaseDlls\*.dll" C:\development\sitecore\WebSite\bin

注意：

• 上面的步骤4-8完全相同 编辑让我头疼，所以我 刚离开冗余。

• 所有涉及的dll，就Sitecore而言，我们仍然想要gitignore dll，因为它可能让我们的业务用户头疼。因此，为了将dll维护为被忽略的文件，我们的解决方法是上面的快速修复。这不是我们想要的，但如果它 适合你，使用它，如果没有，忽视。