Delphi 构建自动化的最小代理安装足迹是多少？答案

【问题标题】：What is the minimal agent install footprint for Delphi build automation?Delphi 构建自动化的最小代理安装足迹是多少？
【发布时间】：2012-12-17 14:35:30
【问题描述】：

当创建一个构建服务器来执行干净的版本控制检出和完整系统构建给定源存储库或项目中的所有内容时，XE3 Win32/Win64 项目所需的最低 Delphi 安装空间是多少？（核心系统 - 不是第 3 方组件）

我宁愿拥有可以包含在存储库中的一小部分文件，而不是完整的 Delphi 安装。

【问题讨论】：

您到底在寻找什么？完整的文件列表？那么注册表和 Delphi 安装的所有其他部分呢？
在干净的构建服务器上构建 HelloWorld 类型 32|64 位 Delphi 项目所需的一切（文件/注册表）。
到目前为止你尝试过什么？您是否进行了最低限度的安装并捕获了对您机器的更改？就我个人而言，我什至不会开始考虑你在问什么。只需从那里创建一个具有必要安装和引导程序的 VM。
答案——“最小”——几乎完全取决于你在代码中是什么，不使用/不做什么。我建议只安装 Delphi 并保留它。顺便说一句，许可证允许您安装副本以进行构建。

标签： delphi continuous-integration delphi-xe3 build-server

【解决方案1】：

使用命令行编译器，您无需在远程代理计算机上安装 IDE。从正在运行的安装中，将 \Bin 和 \Lib 子文件夹内容复制到远程代理中。

然后运行 DCC32.exe 命令行编译器，将 DCC32.CFG 文件内容更改为指向所有需要的源代码路径。不要忘记为所有 .dcu 生成的文件设置一个临时文件夹，并指定一个 .exe 目标文件夹。

见

更新：是的，我知道，MSBuild 是“官方方式”。但是对于构建代理，我发现使用命令行编译器是多么容易。这里的问题是关于构建 Delphi 应用程序的“最小足迹”。

使用 DCC32，无需安装，无需复制与 IDE 中相同的布局。构建环境不应该与 IDE 配置绑定，并且应该从我的实验中的任何开发人员特性“干净”。它应该从头开始构建，从源代码构建您的所有应用程序，运行单元测试并准备发布。我看到一些 .dcu 或 .bpl 污染了构建过程，花了几个小时才发现为什么没有考虑到代码修改！

如果您需要一些复杂的构建过程，我总是喜欢编写一些 Delphi（或 python）代码，从文本文件中读取配置，而不管构建代理运行在什么计算机上。在计算机上安装 Delphi 只是为了构建（尤其是最新版本）是一个 PITA，即使许可证允许您这样做，而命令行编译器可以安全且快速地安装/设置。只需复制文件，然后运行它们。如果您的构建代理是一个虚拟服务器（现在应该是这样），您的 IT 将很高兴不污染注册表。如果只是您的公司 IT 更喜欢 Delphi，因为它相对于其他框架的简洁性，那么它总是值得的。

【讨论】：

您假设 dcc32 是所需的构建机制。在现代 Delphi 中，这样做是个坏主意。您应该使用 msbuild 以确保 IDE 和命令行之间的构建一致性。
是的，我还是上个世纪的人。 ;) 我只是不喜欢 MSBuild，当涉及到一些复杂的构建序列时，一个小的 Delphi 工具是完美的：例如一个月前，我制作了一个工具，能够构建涉及大量输入文件夹和复杂 COM/.Net 对象注册的大量应用程序：文本文件中的一些行足以让应用程序构建，包括源代码检索.我只是不喜欢 MSBuild XML 语法。你如何解析容易定制的配置文件？如何创建一些过程，包括变量和循环？在 Delphi 中很容易，在 XML 中不可读。
我同意所有这些，但 IDE 会构建 msbuild 输入文件。由于我在 IDE 和命令行中都构建，我想要一致性。
@DavidHeffernan 查看我的答案更新。对我来说，与 IDE 保持一致是一个好主意，但也可能是混乱的根源。我曾在一些环境 (IEC 62304) 中工作，在该环境中，构建过程应该从头开始、可追溯和记录（包括所有标识为 SOUP 的第三方）。 IDE 环境可能不一样，特别是如果您为组件使用 .bpl，或者有一些“调试”可定制模式（如开发数据库或日志）。
MSBuild 在我的项目中比 DCC32 慢 3 倍

【解决方案2】：

找到了 D2006+D2007 的来源：

https://delphi.fandom.com/wiki/Setting_up_a_Delphi_Build_Machine

【讨论】：