version-control - 如何构建具有多个依赖项目的 VCS

Question

我确信这是其他人以前解决过的常见问题，所以我呼吁其他开发人员/项目经理的集体智慧寻求帮助。

我有很多项目:

申请

WebApp

服务端

开发工具

ORM

所有的应用程序/实用程序都依赖于 ORM:当 ORM 更改时，需要对其进行编译，并且需要针对它重新编译所有应用程序，然后进行部署。现在我的 VCS 结构有点困惑:

应用名称

树干

申请

WebApp

服务端

Dev Utils(目前大约有 4 个文件夹，但还在增加)

ORM

释放

项目名称(无论是应用程序还是 WebApp)版本号

分行

实验名称_开发名称

理想情况下，我希望每个应用程序(Application/WebApp/ORM 等)都有一个根文件夹，每个文件夹都有自己的 Trunk/Branches/Releases 等，以便在逻辑和物理上将它们分开。我的理由是，因为在应用程序上完成了大量工作，并且发布的频率更高，所以每个发布分支都有相同实用程序等的相同副本。同时检查主干来处理它总是意味着所有其他项目随之而来。

然而，分离意味着将某些项目从解决方案中剥离出来，并使同时修改任何项目变得痛苦——在 2-3 个 IDE 之间跳跃(尤其是在对 ORM 进行更改时)。

我正在考虑这个，因为很快我就会组装一台 CI 机器(准备好在一周左右的时间内回答有关问题的问题)并且我正在尝试找出一种方法来自动创建/部署版本。通常，通过脚本复制到所有工作站在启动时拉取的服务器，只需部署应用程序，但正如我之前所说，如果 ORM 更改/发布，所有其他应用程序都应该重新构建和部署。

(今天我破坏了我们的网站和 3 个实用程序，因为我更改了 ORM 并使用应用程序的更新版本部署了它，但忘记使用新的 ORM 重建/部署其他应用程序 - 哎呀。)

Answer 1

把自己放在开发人员的角度。这应该不难，因为听起来您就是其中之一 :-) 不是从架构的角度，而是从可用性的角度来看您的版本控制布局。问问自己:作为开发人员，我们每天对源代码所做的最常见的事情是什么？特别考虑您与 VCS 系统和项目布局的交互。你想让常见的事情变得容易脑死亡。不太常见的用例更难掌握是可以的，只要你有如何做的记录，这样当(不是如果!)人们忘记时，他们就会知道去哪里提醒自己如何.

我见过很多试图在架构上“完美”的 VCS 布局，但从日常使用的角度来看，最终导致了无穷无尽的麻烦和头痛。我并不是说两者不能重合和很好地融合在一起，我只是说从用户的角度考虑它，并让其成为您的指南。

从 CI 的角度来看，我仍然会采用这种方法。即使您的设置最终在您选择的 CI 中定义变得更加复杂，您也只需在那里进行一次设置。如果布局在开发过程中易于使用，您的大部分 CI 设置也应该相对容易。然后，您只需专注于需要更多时间的最后一点。