解决我们的版本控制和构建问题

Question

在我工作的地方，我们需要重新思考我们开发软件的方式并跟踪每个发布的版本。您对解决我们的问题有什么建议吗？

1. 我们在 Windows 上使用 VS 2005（和 C++ Builder 用于一些接口的东西）在 C++ 中开发

2. 我们使用 GIT，但可以想象到的更糟糕的方式。我们对迁移到另一个源代码管理持一定的开放态度。

3. 我们有 40 多个内部开发的 DLL。其中许多可以经常更新。

4. 我们有几个完全不同的项目依赖于这些 DLL。

5. 我们每年交付 100 多个系统，每个系统都需要自定义配置。大多数还需要自定义补丁。我们尽我们所能将这些补丁带回主干，但分叉是不可避免的。

6. 如果几年后我们必须更新客户的系统，我们应该能够取回用于该版本的代码和所有环境参数。我们需要一种方法来验证此代码是否与客户端系统上的二进制文件匹配。取回代码应该尽可能简单，也许除了编译器之外，我们应该通过一些简单的操作来获得编译所需的一切。

7. 无论补丁位于哪个项目 (DLL) 中，程序员都应该能够为客户端系统发布更新，而无需依赖任何其他程序员。他应该能够快速完成（不到 30 分钟）。这使得单一官方发布的概念几乎是不可能的。

8. 在同一项目上工作的开发人员之间交换代码应该简单快捷。

9. 考虑到我们庞大的代码库，我们希望限制开发人员在获得补丁时必须重新编译的次数（必须共享二进制文件）。

10. 开发人员应该能够轻松地从一个客户端的系统版本切换或分支到另一个（通常必须同时处理多个版本）。

编辑： - 到目前为止，我们还没有使用 makefile，但这是我们愿意考虑的。一切都是使用 VS 解决方案构建的。

Answer 1

Git 本身非常适合拥有大量源代码分支。但是，这些分支的维护将始终由用户进行，并且超出了给定版本控制系统的范围。

Git 的唯一问题是它不能很好地扩展以跟踪编译的二进制数据。二进制数据大多是一次性使用的，对于源代码很重要的差异/补丁方面对于编译的二进制数据并不重要。相反，只需为 Git 中的每个源代码版本创建一个 .zip 文件，其中包含每个 DLL 的预编译版本，然后将这些 .zip 文件放在网络共享上。

如果您已经这样做了，听起来您应该在构建系统上投入时间以提高效率。版本系统在这里可以提供帮助，但无论如何你可能会遇到构建问题：

• 您的构建系统应该仅在源代码已更改或它所依赖的 DLL 的接口已更改时编译 DLL。这有多棘手取决于所使用的语言：C# DLL 有一个非常严格的接口，这使得这很容易，而 C 没有接口可言（只需在源文件中添加一个#define，一切都可能需要编译)
• 您的构建系统应重用应存储在某处的预编译 DLL。最好不要采用与源代码相同的方式，因为 Git 并未为此进行优化。
• 您的构建系统应该可以应对分支更改正常。例如，Visual Studio 会留下一些文件，并且在必须完成完全重建时并不总是能正确检测到。
• 您的构建系统可能必须使用固定位置的编译器，而不是安装在开发人员 PC 上的当前编译器。您可能还希望将其置于版本控制之下，或者至少明确此依赖关系。

最后，我们推出了自己的构建系统，该系统的速度受到时间的限制，在没有任何更改的情况下对所有涉及的文件执行 stat()。然而，这需要一些时间来构建。构建自己的系统时要考虑的事项：

• 首先构造一个依赖图：DLL 依赖于它的源文件和其他 DLL。
• 将文件的修改时间 (mtime) 用作文件的一种“版本”。保留这些 mtime 的缓存，并将 mtime 的更改视为更新缓存的原因。
• 当文件的一个 mtime 发生变化时，您必须重建它所属的 DLL。重新构建DLL后，检查接口是否发生变化。如果接口发生了变化，请重建所有依赖于此的 DLL。这需要一个图遍历来只处理一次 DLL。
• 使编译并行运行的好处。由于您了解依赖关系图，因此您也知道哪些 DLL 可以并行构建。

好在这完全独立于版本控制系统，所以不会浪费时间。甚至可能一个简单的近似值就足以在 30 分钟内完成。视情况而定。