C语言■Github架构师解读Cu002FC++应用包管理的Why和How
一、背景 本文整理自Johannes Nicolai在JFrog 2019用户大会上的讲演《DevOps for Non-Hipsters（aka C/C++ programmers）》 。
本文插图
Johannes Nicolai是Github的解决方案架构师 ， 主要负责德语区的用户 。 他和很多制造业的用户（多数使用C/C++）交流 ， 询问他们在DevOps或持续交付方面的挑战 ， 通常会得到如下的描述：
本文插图
在嵌入式C/C++领域 ， 花费几十个小时完成一个完整的DevOps流水线并不少见 。 为某一个提交运行单独的构建和测试几乎是不可能的 ， 通常每次构建都包含了几百个同事所有的提交 。 而构建时间长的主要原因在于交付包包含了大量的依赖包 ， 而每次构建这些依赖包都需要从头开始重新构建 。 上述的描述并不仅限于德语区 ， Johannes询问了美国制造业的用户 ， 也得到了类似的反馈 。
从业界的发展来看 ， 声明式包管理能够很好的解决上述的问题 。 在交付包中通过声明描述所需的依赖包 ， 在构建时根据声明从包管理系统中获取相应的依赖包 ， 这样能够大大缩短构建时间 。 Java或JavaScript的开发者很熟悉这样的方式 。
本文插图
对于像Java或JavaScript这样的开发语言 ， 包管理的实现相对简单 ， 包的每一个版本只对应一个二进制文件 。 而在C/C++中 ， 由于操作系统、架构、编译器等的不同 ， 包的每一个版本会对应多个不同的二进制文件 ， 彼此之间还并不兼容 。 这也就导致了C/C++的包管理一直是业界公认的难题 。
当然 ， 针对C/C++的开发 ， 现在也出现了像Conan这样比较成熟的包管理解决方案 。 Johannes在本次讲演中首先分析了为什么要在DevOps中引入包管理 ， 然后通过演示介绍了Conan如何通过方便的包管理和开发方式 ， 帮助C/C++程序员实现简洁、高效的DevOps流水线 。
二、为什么要在DevOps中引入包管理 现在业界大都在推行敏捷 ， 而在敏捷提出的12条原则中 ， 第一条就是：通过早期和持续型的高价值工作交付满足“客户” 。
通过持续性的交付 ， 首先能够快速发现问题 ， 从而尽早解决问题 ， 而不是每次发布前都要积累大量的问题 ， 从而导致过长的修复时间和交付质量的下降 。
本文插图
其次 ， 用户可能一开始并不是特别清楚自己的需求 。 通过持续性的交付 ， 用户可以不断的试用来渐进明晰地明确自己的实际需求 ， 从而保证了交付的有效性 。
本文插图
要实现敏捷原则所要求的持续性交付 ， 我们必须实现持续性、可重复的DevOps流水线 。 而为了实现这样的DevOps ， 一个基本原则是要做到“只构建一次二进制文件” 。
本文插图
也就是说 ， 每一个版本的交付包 ， 我们只构建一次 。 获得其对应的二进制文件后 ， 在DevOps的后续阶段、不同环境中 ， 都应该用且只用这同一个二进制文件 。
本文插图
然而 ， 针对C/C++的应用来说 ， 各种不同的目标环境导致同一个版本的交付包 ， 必然会对应多个互不兼容的二进制文件 。 在这种情况 ， 要做到仅一次构建 ， 无疑需要借助于良好的包管理解决方案 。
推荐阅读
- 「事情」史海峰：万字长文剖析技术人如何成长
- 「」什么是基础架构即代码和平台即代码？看完就清楚了
- 凤凰网安徽综合：除了Scratch，2020年热门的少儿编程语言还有哪些
- 「」微软翻译器和其他产品现在提供十种印度语言实时翻译服务
- 『』提升手机上行链路效率的射频功放架构--EER技术介绍
- 「技术」自然语言处理技术可提升创新效率
- []深入了解CI/CD：工具、方法、环境、基础架构的全面指南
- 智能手机■CEVA全新高性能传感器中枢DSP架构SensPro—助力智能感知发展
- 「PC硬科技」英伟达MX400系列移动显卡现身，图灵架构、GDDR6
- 『』一文看懂荣耀30首发的麒麟985处理器 三档能效架构