我对自动化构建流程和持续集成相当陌生，并且正在为一小群开发人员设置构建流程/服务器。我们正在使用 SVN、CMake 和 Jenkins 构建服务器。源语言是 C++。
假设我们有两个项目，library(一个 dll)和 executable。 executable 链接到 library，因此要构建 executable，您需要 library 中的 .lib 和 .h 文件。要运行 executable，您需要 library 的 .dll(可能还有调试符号文件)。
当构建整个东西时，它相当简单，您从存储库获取最新源代码并构建library，然后构建executable。
但是，我们有多个开发人员，每个开发人员通常一次处理一个项目。我们的 CMake 脚本允许您选择要构建的项目，因此 John 的设置可能只构建 executable，而 Bob 只构建 图书馆。放弃这不是一种选择。
因此，如果 Bob 对 library 进行更改并提交源代码，John 将需要获取已编译的 .lib 和 .dll 文件(因为他没有编译library)。
现在，二进制文件在 svn 中。在每次编译期间，CMake 将 src/bin 复制到 build/bin 作为预编译步骤，然后编译选择的任何项目(替换 build/中的适当二进制文件) bin)，最后 CMake 将 build/bin 复制到 src/bin。
这意味着当 Bob 进行更改时，他不仅提交了源文件，还提交了编译后的二进制文件，而当 John 更新他的工作副本时，他得到了适当的二进制文件，并且不必进行任何手动文件替换。
这已经工作了一段时间，但出于几个原因我真的不喜欢它。是否有更少的 hack-ish 方式来设置这样的东西？ (实际上有 4 个开发人员，大约 12 个项目，有些是不依赖任何库的库，有些是依赖其他库的库，有些是依赖其他库的可执行文件。)
编辑:这是我想到的过程:
使用工件跟踪系统(如 Artifactory 或 Nexus)在构建后存储二进制文件，以及用于生成这些二进制文件的头文件
在 CMake 中，每个项目都被标记为已编译或预编译。编译的项目是从常规存储库生成的。如果预编译的项目二进制文件和 header 已过期，则会从 Nexus 下载，并且 CMake 会适本地链接和包含它们。 header 也与工件一起保存，以防止我在对 Dave Bacher 的回答的评论中描述的竞争条件。
我唯一不喜欢的是我必须做一些 CMake-foo 来检查工件是否过时并下载它们，但我想没有真正的替代方案，因为显然我我试图设置的太不标准了。
最佳答案
我不喜欢您将开发人员的构建 checkin 为其他人构建的规范引用。它很脆弱，你最终可能会得到糟糕的构建，这些构建对一个人在他们的环境中有效，但对其他人却失败了。或者有人进行了更改，但忘记 checkin 文件，突然之间，他们是唯一可以构建项目的一部分的人。
至少，您应该将 Jenkins 设置为构建库和可执行文件的地方，并让您的开发人员仅 checkin 源代码。 Jenkins 有几个插件(例如 SVN Publisher )，可用于在标准构建环境中构建库和可执行文件后发布它们。
根据我的经验，在构建机器上安装 Jenkins 并为每个项目设置构建非常简单。这让您开始验证每个项目是否构建的第一步。然后努力让 Jenkins 发布其输出，而不是依赖开发人员发布他们的构建。
关于svn - 为依赖项目和多个开发人员设置构建过程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10386245/