标签：安装 normal 需要 时间 静态 log 收集 abi tag
C 和 C ++ 目前被应用在操作系统、嵌入式系统、财务、科研、汽车、机器人、游戏等非常重要的行业。主要原因是 C 和 C++ 相比于其他技术来说拥有很高的性能。但同样，C/C ++ 生态系统也面临一些巨大的挑战：巨石应用 -- 拥有数百万甚至更多行代码，在不使用现代工具的情况下很难管理项目。
应用程序二进制接口（ABI）不兼容 -- 为了保证库与其他库和应用程序的兼容性，需要控制不同的配置（如操作系统，体系架构和编译）。
编译时间慢 -- 由于包含头文件和预处理器扩大，再加上上述挑战，需要特别注意优化过程并仅重建需要重建的库。
代码链接和内联 -- 静态 C/C++ 库可以嵌入来自相关库的头文件。另外，共享库可以嵌入一个静态库。在这两种情况下，当它们的依赖关系发生变化时，都需要管理库的重建。
不同的生态系统 -- 针对不同的平台、目标和用途，有许多不同的编译器和生成系统。
本文将展示如何使用 Jenkins CI，Conan C/C++ 包管理器和 JFrog Artifactory 通用工件存储库实现 DevOps C/C++ 开发的最佳实践。
Conan 的诞生就是为解决这些痛点。
Conan 使用了 Python，描述了如何通过显式调用任何构建系统来构建库，还描述了用户所需的信息（包括目录，库名等）。Conan 使用“Settings”（操作系统，架构，编译器等）管理不同的配置和 ABI 的兼容性。当一个设置被改变时，Conan 为同一个库生成一个不同的二进制版本。
构建后的二进制文件可以上传到 JFrog Artifactory 或 Bintray，与团队或整个社区共享。 团队中的开发人员不需要重新编译库，Conan 将从配置好的远程库（分布式模型）中仅提取匹配用户配置所需的二进制包。 但是还有更多的挑战需要解决：
如何管理 C/C++ 项目的开发和发布过程？
如何分发你的 C/C++ 库？
如何测试你的 C/C ++ 项目？
如何为不同的配置生成多个包？当其中一个更改时，如何管理库的重建？
Conan 生态系统正在快速发展，使用 C/C++ 的 DevOps 现在已经成为现实：
JFrog Artifactory 管理完整的开发和发布周期。
JFrog Bintray 是通用的分发中心。
Jenkins 自动执行项目测试，生成 Conan 软件包的不同二进制配置，并自动重建库。
提供 Conan DSL，是比较通用但有效的从 Jenkins 流水线脚本调用 Conan 的方法。
使用 Artifactory 实例管理远程配置，隐藏认证详细信息。
收集从 Conan 操作（安装/上传包）的工件来生成 Buildinfo 并且发布到 Artifactory。 BuildInfo 对象是非常有用的，例如，将创建的 Conan 包推广到不同的存储库并对 Jenkins 构建具有完整的可追溯性：
下面是带有 Artifactory 插件的 Conan DSL 的一个例子。首先我们配置 Artifactory 存储库，然后检索依赖关系并最终构建它：
在上面的例子中你可以看到 Conan DSL 是非常明确的。它对常用操作有很大的帮助，而且也允许强大的自定义集成。这对于 C/C++ 项目非常重要，因为每个公司都有一个非常具体的项目结构，自定义集成等。
正如我们在本文开始时看到的那样，在构建 C/C++ 项目时节省时间至关重要。 以下是几种优化流程的方法：
只重新构建需要重建的库。 有些库已经被一个依赖库的改变而影响了。
如果可能，并行构建。 当项目关系图中两个或多个库之间没有关系时，可以并行构建它们。
并行构建不同的配置（操作系统，编译器等）。
我们来看一个使用 Jenkins 流水线功能的例子
上图显示了我们的项目 P 及其依赖关系（A-G）。我们希望分发两个不同的体系结构，x86 和 x86_64。
如果我们改变库 A 会发生什么？
如果我们碰到 A（v1）的版本没有问题，我们可以更新 B 的要求，也可以将版本升级到 B（v1）等等。完整的流程如下：
将A（v1）版本推送到 Git，Jenkins 将构建 x86 和 x86_64 二进制文件。Jenkins 会把所有的包上传到 Artifactory。
手动将 B 更改为 v1，现在取决于 A1，推送到 Git，Jenkins 将使用从 Artifactory 检索到的新 A1 来为 x86 和 x86_64 构建 B（v1）。
对 C，D，F，G 和我们的项目重复相同的过程。
但是，如果我们在开发库中开发我们的库，我们可能依赖于最新的 A 版本，或者将在每次 Git 推送时重写 A（v0）软件包，并且我们希望在这种情况下自动重建受影响的库 B，D，F ，G 和 P。
Jenkins 流水线会怎么做
首先我们需要知道哪些库需要重新构建。“conan info --build_order”命令会标识在我们的项目中被更改的库，并且还告诉我们哪些可以并行重新构建。
于是，我们创建了两个 Jenkins 管道任务：
建立每个单一库的 SimpleBuild 任务。类似于使用 Jenkins Artifactory 插件使用 Conan DSL 的第一个示例。这是一个参数化的任务，接收需要构建的库。
MultiBuild 任务，在可能的情况下并行的协调、启动“ SimpleBuild”任务。
我们也有一个 Yml 配置的仓库。 Jenkins 任务将使用它来了解每个库的配置，以及要使用的不同配置文件。在这种情况下，它们是 x86 和 x86_64。
这意味着我们需要开始构建 B，然后我们可以并行构建 D 和 F，最后构建 G。请注意，库 C 不需要重建，因为它不受 A 库变化的影响。
“MultiBuild”任务的 Jenkins 流水线脚本将对“SimpleBuild”任务的并行调用，最后并行启动组。
最终，这将会发生什么：
两个 SimpleBuild 任务将被触发，都是用于构建库 B，一个用于 x86 还是另一个用于 x86_64 体系结构
一旦“A”和“B”被构建，将触发“F”和“D”，4个工作将同时运行“SimpleBuild”任务（x86，x86_64）
最后将构建“G”。所以2个工作将平行运行。
Jenkins Stage 视图：
MultiBuild
SimpleBuild
我们可以在不同节点（Windows，OSX，Linux ...）中配置“ SimpleBuild ”任务，并控制 Jenkins 配置中可用的执行程序的数量。
对于 C/C++ 来说，落地 DevOps 仍然是许多公司需要做的事情。 这需要大量的时间投入，但从长远来看可以节省很多的时间在开发阶段并且释放生命周期。 而且它提高了 C/C++ 产品的质量和可靠性。
上面的 Jenkins 示例演示了如何并行控制库构建，只是通过 Groovy 代码和一个自定义的方便的 Yml 文件。 关于它的伟大的事情不是例子或代码本身。 最重要的是可以定义自己的流水线脚本以适应特定的工作流程，这要归功于 Jenkins Pipeline，Conan 和 JFrog Artifactory。
原文链接：https://jenkins.io/blog/2017/07/07/jenkins-conan/
JFrog 中国研发工程师，曾在唯品会担任研发工程师，擅长Java，参与过多个互联网平台的研发和运维工作，现专注于Devops 落地，持续集成、持续交付领域。
欢迎转载，但转载请注明作者与出处。谢谢！
C/C++ 如何进行持续交付？使用 Jenkins+Conan！
标签：安装 normal 需要 时间 静态 log 收集 abi tag
原文地址：http://blog.51cto.com/jfrogchina/2061098
