有哪些技巧可以让我的项目每次都在全新的结帐时进行编译？

Question

很多次我都不愿意承认，我曾多次让刚接触项目的人进行检查，却发现他们缺少各种资源、dll 和设置。 我想养成正确的习惯，让我的项目编译顺利，就像重新结帐一样。

关于如何构建我的项目，以便它们在从版本控制中重新签出时不会出现编译问题，有哪些提示或建议？

我开始在我的项目中保留一个“Resources”文件夹，其中包含源代码管理中所有需要的 dll 引用。 其他人可以提出一些建议吗？

Answer 1

假设您在 Visual Studio 环境中，这里有一些您可能会发现有用的东西，YMMV 当然，请注意我们使用 Subversion，但任何 VCS 工具都应该这样做...

• 将所有（或尽可能多的）依赖项放在下面版本控制并在您的项目中引用它们。 我们使用 Subversion 外部来管理它。
• 不对标准输出目录（bin、obj）进行版本控制，即使用 svn:ignore
• 同样，忽略版本控制用户项（*.user、*.suo）
• 也不对配置文件（App|Web.config）进行版本控制相反，创建一个 App.default.config 并在您的项目 BeforeBuild 任务中将此文件复制到 App.config。 这允许您通过使用 RegEx 和令牌来设置每个开发人员或构建服务器的编译，它还允许您删除 CI 构建上的任何现有 App.config 文件，以确保每次都是原始构建。 这也使得开发人员可以随意修改配置，而不必打扰其他人，直到他们准备好为止，即更新 App.default.config。
• 对其他一切进行版本控制:)
• 如果您需要对编译后的二进制文件（MSI、DLL 输出等）进行版本控制，请在 AfterBuild 目标项目（wixproj 等）中将输出复制到受版本控制的另一个目录。 使用 Subversion 的一个技巧是，您可以添加/提交到 svn:externals 目录，该目录允许您将库等推送到引用它们的项目中。

最后提示 - 在完成彻底检查并成功编译后，检查工作副本中是否有任何修改，例如 TortoiseSVN -> 检查是否有修改。 如果检测到更改，则可能需要忽略这些文件。

Answer 2

找到一台未使用的旧计算机并将其设置为自动“滚动构建”：

1. 等待有人签入更改
2. 更新到所有文件的最新版本。
3. 清理所有非源代码控制文件（make clean 还不够 - 扫描碎片并将其删除）
4. 。
5. 运行单元测试。
6. 每天一次，保存成功运行的二进制文件。 称其为当天的“官方版本”。

如果构建或测试失败，请发送包含错误的电子邮件。 包括在 #2 中进行的更改列表。

如果你真的实在找不到机器，那就在虚拟机中进行吧。

Answer 3

像 nmaven 这样的工具可以帮助解决依赖性问题，（尽管您可能需要查看 java maven 文档以获取信息....)

持续集成工具，例如 cruisecontrol 在每次签入后重复签出并构建您的应用程序，这可以提醒您破坏构建的签入...此外，它们可以运行您的单元测试，从而提醒您签入导致的任何回归......

Answer 4

还有人可以提出一些建议吗？

1. 将您需要构建的文件保存在一个地方（一个目录及其子目录）...大多数版本控制系统将其称为“工作目录”您的
2. 版本控制软件有一个命令来列出工作目录中的内容之间的差异目录和受版本控制的内容...此“差异”包括工作目录中存在的文件和不受版本控制的文件
3. 调整版本控制软件以排除（从步骤 2 显示的列表中）您类型的文件不想存储...例如，您可能只想存储源代码，并排除 *.obj 等...排除这些文件类型意味着当您运行步骤 2 时差异列表中并没有挤满您不打算存储的文件
4. 考虑拥有一台构建机器，它会自动执行签出和构建（如果“构建被破坏”，它会向您发送电子邮件）

Answer 5

Debian Linux 有一个非常棒的工具，名为 pbuilder，它创建新安装的系统的映像，然后尝试构建您的代码。 它只适用于 Debian 软件包系统，但你可以窃取这些想法，这真的很好。

自动化从 chroot 环境或看起来像全新安装的虚拟机进行构建。 然后，您的构建脚本将安装 DLL 等。 或者您的配置脚本将枚举缺少的依赖项（所有依赖项，而不仅仅是第一个）。

现在是凌晨 1 点，我听起来语无伦次，但有两个想法是核心：

• 拥有一个可以模拟空白系统的虚拟机或 chroot 目录。 如今，虚拟机可能是最简单的。

• 调整您的构建系统，直到它自动检查并在您的虚拟机上构建——或者抱怨缺少什么。

  调整您的构建系统，

那时，您可以将该过程作为自动化夜间构建的一部分，您将成为一个快乐的露营者:-)

Answer 6

任何资源/DLL/设置都应与源代码一起检查到版本控制中。

它们应该与源代码进行标记和同等对待，这将允许您将这些资源与源相关联，并将源代码/资源/设置视为单个实体。

在我的公司，我们使用 Rational ClearCase。 除了生成的源代码文件（例如，从 MIDL 编译器生成的 .cpp 和 .h 文件）之外，所有内容都会检查到源代码管理中。 正因为如此，大多数构建都相当顺利。

您还需要确保正确设置依赖项，因此当源文件更改时，所有依赖库都将重新构建。

Answer 7

您可以建立一个全面的清单，在每次签入之前查阅 - 但这会非常耗时且容易出错（特别是在多个开发人员中，并不是每个人都具有每次都严格遵循清单的性格特征）。

相反，设置一个简单的持续集成服务器 - CruiseControl.Net 是开源的； JetBrains 的 TeamCity 是免费的 - 每次签入完成时都会检查构建工作。

这样，您就可以确定——而不是因为遵循了清单就推断事情有效。

Answer 8

SCons 是另一个跨平台工作的工具，有助于管理您的依赖项。 与 gnu make 类似，您有一个“scons 文件/脚本” - 事实上它使用 python 为您提供了很大的灵活性。

http://www.scons.org/

（我与 SCons 没有任何关系；我们只需使用它即可）