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

Question

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

1. 我们使用VS 2005在C ++上开发（以及用于某些界面的C ++ Builder）

2. 我们使用GIT，但可能的方式更糟糕。我们有点愿意转向另一个源代码控制。

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

4. 我们有一些显着不同的项目依赖于这些DLL。

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

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

7. 程序员应该能够在不依赖任何其他程序员的情况下发布客户端系统的更新，无论补丁是什么项目（DLL）。他应该能够快速完成（不到30分钟）。这使得单一正式发布的概念几乎不可能。

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

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

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

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

Answer 1

Git本身非常适合拥有众多源代码分支。但是，这些分支的维护将始终驻留在用户处，并且不在给定版本控制系统的范围之内。

Git的唯一问题是，随着时间的推移，它无法很好地跟踪编译的二进制数据。二进制数据主要是一次性使用，而对源代码很重要的diff / patch方面对于编译的二进制数据并不重要。相反，只需为Git中的每个源代码版本创建一个.zip文件，其中包含每个DLL的预编译版本，并将这些.zip文件放在网络共享上。

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

• 您的构建系统应该只在源已更改或其所依赖的DLL的接口发生更改时编译DLL。这有多难取决于使用的语言：C＃DLL具有相当严格的接口，这使得这很容易，而C没有可以说的接口（只需将一个#define添加到源文件，所有内容都可能必须编译）
• 您的构建系统应该重用应该存储在某处的预编译DLL。最好不要与源代码相同，因为Git没有针对此进行优化。
• 你的构建系统应该应对分支改变好了。例如，Visual Studio会遗留一些文件，并且在完成重建时无法始终正确检测到文件。
• 您的构建系统可能必须使用固定位置的编译器，而不是在您的开发者PC上安装的每日编译器。您可能还希望将其置于版本控制之下，或者至少使此依赖项显式化。

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

• 首先构造一个依赖图：DLL取决于它的源文件和其他DLL。
• 使用文件的修改时间（mtime）作为文件的“版本”。保留这些mtimes的缓存，并考虑将mtime更改为更新缓存的原因。
• 当文件的一个mtime发生更改时，您必须重建它所属的DLL。在重新生成DLL之后，检查接口是否已更改。如果接口已更改，请重建所有依赖于此接口的DLL。这需要一次图遍历才能只处理一次DLL。
• 使编译并行运行的好处。既然你知道你的依赖图，你也知道可以并行构建哪些DLL。

好的是，这是所有版本控制系统独立的，所以不浪费时间。它甚至可能是一个简单的近似就足以能够做到<30分钟。这取决于。