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

Question

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

1. 我们在 Windows 上使用 VS 2005(和 C++ Builder 进行一些界面设计)在 C++ 上进行开发

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

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

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

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

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

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

8. 在从事同一项目的开发人员之间交换代码应该既简单又快速。

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

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

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

Answer 1

Git 本身非常适合拥有大量源代码分支。但是，这些分支的维护将始终由用户负责，不在给定版本控制系统的范围内。

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

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

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

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

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

好消息是，这都是独立于版本控制系统的，所以不会浪费时间。甚至可能是一个简单的近似值就足以在 <30 分钟内完成。这取决于。