比我承认的次数还要多，我让刚接触项目的人进行结帐，却发现他们缺少各种资源、dll 和设置。我想养成让我的项目编译顺利的正确习惯，就像从新结帐时一样。
关于如何构建我的项目以使它们在从版本控制中重新签出时不会出现编译问题，有哪些提示或建议？
我已经开始在我的项目中保留一个“资源”文件夹，其中包含源代码管理中所有需要的 dll 引用。其他人可以提出一些建议吗？
anon
问问题
523 次
8 回答
2
找到一台未使用的旧计算机并将其设置为自动“滚动构建”：
- 等到有人签入更改
- 更新到所有文件的最新版本。
- 清除所有非源代码控制文件（
make clean还不够 - 扫描碎片并将其删除） - 建造。
- 运行单元测试。
- 每天一次，保存成功运行的二进制文件。将其称为当天的“官方构建”。
如果构建或测试失败，请发送包含错误的电子邮件。包括在 #2 中选择的更改列表。
如果你真的，真的找不到机器，就在虚拟机里找。
于 2009-01-13T03:26:59.420 回答
2
假设您在 Visual Studio 环境中，这里有一些您可能会发现有用的东西，当然是 YMMV，请注意我们使用 Subversion，但任何 VCS 工具都应该这样做......
- 将所有（或尽可能多的）依赖项置于版本控制之下，并在您的项目中引用它们。我们使用 Subversion externals 来管理它。
- 不要版本控制标准输出目录（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 -> 检查修改。如果检测到更改，则可能需要忽略这些文件。
于 2009-01-13T03:38:17.243 回答
1
像nmaven这样的工具可以帮助解决依赖性问题，（尽管您可能需要查看java maven文档以获取信息......）
像Cruisecontrol这样的持续集成工具会在每次签入后重复签出并构建您的应用程序，这可以提醒您签入会破坏构建...此外，它们可以运行您的单元测试，从而提醒您任何由以下原因引起的回归你的签到也...
于 2009-01-13T01:06:38.610 回答
1
其他人可以提出一些建议吗？
- 将您需要构建的文件保存在一个地方（一个目录及其子目录）......大多数版本控制系统将其称为“工作目录”
- 您的版本控制软件有一个命令可以列出您的工作目录中的内容和版本控制下的内容之间的差异......这个“差异”包括工作目录中存在的文件和不受版本控制的文件
- 调整您的版本控制软件以排除（从步骤 2 显示的列表中）您不想存储类型的文件......例如，您可能只想存储源代码，并排除
*.obj等等......排除这些文件类型意味着当您运行第 2 步时，差异列表不会挤满您不打算存储的文件 - 考虑拥有一台构建机器，它会自动进行签出和构建（如果“构建被破坏”，它会向您发送电子邮件）
于 2009-01-13T03:10:24.367 回答
1
Debian Linux 有一个非常棒的工具叫做pbuilder，它创建一个新安装的系统的镜像，然后尝试构建你的代码。它仅适用于 Debian 软件包系统，但您可以窃取这些想法，这非常好。
从 chrooted 环境或看起来像全新安装的虚拟机自动构建。然后，您的构建脚本将安装 DLL 等。或者您的配置脚本将枚举缺少的依赖项（所有依赖项，而不仅仅是第一个）。
现在是凌晨 1 点，我听起来语无伦次，但有两个想法很重要：
拥有可以模拟空白系统的虚拟机或 chroot 目录。如今，虚拟机可能是最简单的。
调整您的构建系统，直到它自动检查并在您的虚拟机上构建——或者抱怨缺少什么。
到那时，您可以将该过程作为自动化夜间构建的一部分，您将成为一个快乐的露营者 :-)
于 2009-01-13T06:06:22.623 回答
0
任何资源/DLL/设置都应与源代码一起检查到版本控制中。
它们应该被标记并与源代码同等对待，这将允许您将这些资源与源相关联并将源代码/资源/设置视为一个实体。
在我的公司，我们使用 Rational ClearCase。 除了生成的源代码文件（例如，从 MIDL 编译器生成的 .cpp 和 .h 文件）之外，所有内容都被检查到源代码控制中。因此，大多数构建都相当顺利。
您还需要确保正确设置了依赖项，以便在更改源文件时，将重新构建所有依赖库。
于 2009-01-13T01:07:38.140 回答
0
您可以建立一个全面的清单，在每次签入之前查阅该清单 - 但这会很耗时且容易出错（尤其是在多个开发人员中，并不是每个人都具有每次都密切关注清单的性格特征）。
相反，设置一个简单的持续集成服务器——CruiseControl.Net是开源的；JetBrains 的TeamCity是免费的 - 每次签入时都会检查构建工作。
通过这种方式，您可以肯定地知道——而不是因为遵循了清单就推断事情有效。
于 2009-01-13T03:17:21.030 回答
0
SCons 是另一个跨平台工作的工具，可以帮助管理您的依赖项。与 gnu make 类似，您有一个“scons 文件/脚本”——它使用 python 的事实为您提供了很大的灵活性。
（我与 SCons 没有任何关系；我们只是使用它）
于 2009-01-13T03:22:40.863 回答