您是否将构建存储在源代码存储库中？

Question

我想得到一些关于这个想法的反馈，因为我可以看到每种方法的优缺点。 作为Java开发人员，这将是关于将jar文件存储在代码存储库中，但它可以很容易地扩展到其他编译语言。

优点：

• 可以轻松检索以前的发行版，而无需依赖（基本上不再可用）过时的工具来重新编译。

缺点：

• 可能会迅速“膨胀”代码存储库，具体取决于构建的频率。

Answer 1

我们将版本存档到目录结构，并在源代码管理中标记相应的版本。这使我们可以访问构建的版本以及生成它们的源。

使用构建脚本可以轻松完成此操作，以自动标记和存档发布版本。

Answer 2

妥协：在存储库和标记构建中存储工具和源代码。这样，您始终可以重新创建产品的任何构建。

您可以随时为编译的工件提供单独的存储库。

Answer 3

如果你可以创建一个足够好的构建系统，只需要一个代码检查来重建一个精确的构建是微不足道的，我不相信有任何需要将你的构建存储在存储库中。

对于我的大多数东西，我没有存储我的代码的特定版本，但我存储了我的代码所依赖的库的特定版本。我在几个月前付出了很多努力，使得加载一个标签并输入“ant”变得微不足道，所有东西都在不依赖树外的任何东西的情况下正确构建。 （不包括正确的javac和蚂蚁）

不幸的是，我们的一些代码库没有那么好的构建系统（即，需要手动设置sdks并获取各种外部库和戳环境变量）并且很难重新创建特定版本的构建基于存储库（我们不断前进而不是真正支持旧代码，因此开发人员的工作站设置得足够紧密，以至于我们还没有被烧掉，因为我们必须在当前版本之前回到旧分支）并且在这种情况下，我们会存储我们发布的版本（对于不可避免的胖手指“哦不，我在错误的服务器上进行一些测试”或者同样阴险的东西）。

Answer 4

我将构建存储在服务器中的文件夹中，并且它们会定期备份。但是我标记了代表该构建的修订版。在build文件夹中，我不仅存储可执行文件，二进制文件或页面（我们的例子是ASP.Net），还存储我们从SQL Delta获得的更改脚本。

使用与字段相同的标识符命名标记，因此如果您具有构建“System_2009-07-30-01”，则您将拥有具有该名称的标记。因此，如果您需要修复某些内容，只需查看构建名称，查看标记，然后查看您需要的修订版本以查看可能发生的情况。

Answer 5

我认为没有充分理由对实际版本进行版本控制。标记源版本并使其成为只有受控组才有权更改标记。构建标记永远不应该对其进行检查，因此重建构建应该是微不足道的。

Answer 6

我们会为任何构建标记存储库，以便我们可以获得任何构建版本的实际源代码。然后我们压缩并上传实际部署的实际发布的构建文件 - 只是为了确保在部署期间没有偷偷摸摸的最后一分钟配置调整等不会反映在主干本身。

Answer 7

将特定客户版本放入存储库中 从理论上讲，这不是必需的，因为我们总是可以重现那个版本，但能够获得在某个特定日期发送给某个客户的确切.msi是很好的 - 然后我们在干净的vm中测试它。

一个原因是它可以保护您免受构建环境之外的任何更改，例如Windows或Visual Studio更新。如果msi本身已更新，您可能无法重现msi的位位构建！

Answer 8

我认为在版本控制系统中存储构建输出是合适的。既可用于测试某些特定版本的构建，也可用于简化某些开发任务。

但是，您应确保在存储库中保留所有内容，以便在需要时重新创建该确切的构建。您应该使用consitent标记/标签来促进这一点。您可能需要使用不同版本的各种组件测试错误修复，并且根据整个系统的复杂程度，您可能需要尝试不同的组合。

Answer 9

有时。大多数情况下答案是 no ，但仍有一些情况，如果它有意义，那就去做吧。

顺便说一句，我很惊讶这仍然是开放的。这些讨论类型的问题通常在不到5分钟的时间内被投票结束。

Answer 10

为了减轻旧构建工具可能无法在较新环境中运行的担忧，我们将主要版本的构建机器映像存档。这对我们来说很容易，因为我们的构建机器是虚拟化的。如果其他方法不起作用，则为B计划。

Answer 11

我认为源代码，依赖项，二进制文件和构建工具应该在一起进行版本控制......这是跟踪最终版本来自许多源项目的大项目的唯一方法...