我确信这是其他人之前已经解决的一个常见问题所以我正在寻求其他开发人员/项目经理的集体智慧，以寻求帮助。
我有很多项目：
所有的apps / utils都依赖于ORM：当ORM发生变化时，需要对其进行编译，并且需要针对它重新编译所有应用程序然后进行部署。现在我的VCS结构有点混乱：
理想情况下，我希望每个应用程序都有一个根文件夹（Application / WebApp / ORM等），每个应用程序都有自己的Trunk / Branches / Releases等，以便在逻辑上和物理上将它们分开。我的理由是，因为在应用程序上完成了大量的工作，并且它更频繁地被释放，每个发布分支具有相同的utils等的相同副本。同时检查Trunk以对其进行处理总是意味着所有其他项目来了。
然而，分离意味着将某些项目从解决方案中删除，并且同时修改任何项目是痛苦的 - 在2-3个IDE之间跳转（特别是在更改ORM时）。
我正在考虑这个问题，因为我很快就会把一台CI机器放在一起（准备好在一周左右的时间内就此问题做好准备）而且我正在试图找到一种方法来自动创建/部署。通常情况下，只需将应用程序部署，通过脚本副本部署到所有工作站在启动时从中提取的服务器，但正如我之前所说，如果ORM更改/发布，则所有其他应用程序都应重新构建和部署。 / p>
（今天我打破了我们的网站和3个实用程序，因为我更改了ORM并使用更新版本的应用程序部署了它，但忘记使用新的ORM重建/部署其他应用程序 - oops。）
答案 0 :(得分：2)
把自己放在开发人员的角度。这应该不难，因为它听起来像你是其中之一:-)从架构的角度看，你的版本控制布局，但从可用性的角度来看。问问自己：每天我们作为开发人员使用源代码做的最常见的事情是什么？特别考虑您与VCS系统的交互和项目布局。你想让常见的事情变得容易死脑筋。只要你有记录如何做到这一点，那么不太常见的用例就更难以达到，所以当人们忘记时（不是！），他们会知道在哪里去提醒自己
我已经看到很多VCS布局试图在架构上“完美”，但从日常使用的角度来看，最终导致麻烦和头痛。我不是说这两者不能重合并且很好地融合在一起，我只是说从用户的角度考虑它，让它成为你的指导。
从CI的角度来看，我仍然采用这种方法。即使您的设置最终在您选择的CI中定义变得更加复杂，您也只需要在那里进行一次设置。如果布局在开发过程中易于使用，那么大多数CI设置也应该相对容易。然后，您只需关注需要更多时间的最后几位。
答案 1 :(得分：1)
将代码库拆分为不同的“项目”可能非常困难。我们在每个单独的“可部署”边界上完成了这项工作。包括其他人共同/使用的“平台”层，作为单独的项目。但这也不是很完美。
我不能强调的一件事是，需要在签入之后和实际部署任何内容之前运行某种形式的连续回归/测试。此外，甚至可能涉及一些手动测试的“释放”过程可能会有所帮助，并且肯定会在面部情况下防止一些鸡蛋。 （最好在几天后释放它然后破坏。）
（很抱歉不能直接解决您的问题）