嵌入式软件开发的十二大基本要素（三）：DevOps

在上文《嵌入式软件开发的十二大基本要素（二）：代码性能》中，我们分析了代码性能如何具体影响投资回报率（ROI）和总拥有成本（TCO）。

本文为白皮书系列第三部分，将分析工作流程对生产力的具体影响。

一般来说，在现代开发工作流程中，每增加一行代码或修改软件都会导致软件项目的重新构建。在这种情况下，如果代码太多，就需要很长的时间来构建，从而导致开发周期因为这个等待时间而增加。

这如何转化为公司的优势？

Steve McConnell 的《Software Estimation: Demystifying the Black Art》一书中包含了一张从估算模型 Cocomo II（建设性成本模型）中得出的图表，该图表以人月为单位的工作与以代码行 (SLOC) 为单位的项目规模作对比。如果我们研究 COCOMO II 工作量公式：

工作量 = 2.94 * EAF * (KSLOC)E

EAF：是由成本驱动因素得出的工作量调整系数。

E：是由五个规模驱动因素得出的指数。

KSLOC：以千代码行为单位。

工作量公式中的 EAF 仅仅是与项目的每个成本驱动因素对应的工作量乘数的乘积。

观察下图中从《COCOMO II - 模型定义手册》中提取的成本驱动因素，有很大的比重。在最坏的情况下，极低的评级水平对工作量调整系数 (EAF) 的影响 = 1.40 (1.20*1.17)，在最好的情况下，评级水平非常高，EAF=0.66（0.84*0.78）。

图表：语言和工具经验(LTEX)和软件工具的使用(TOOL)

这将直接影响整个开发团队的生产力。对企业的影响可以在 http://softwarecost.org/tools/COCOMO/ 免费计算和调整。这同样适用于设计和代码生成工具。自动生成的代码的构建时间较长，会影响到设计本身的生产力，因为在进行设计之前，需要对更改或新的逻辑进行测试并集成到整个系统中。

根据不同的客户反馈，以及在客户案例中所述，与其他商业工具相比，IAR Embedded Workbench 的构建速度至少是其两倍。这也同样适用于 IAR 功能安全版本的产品。而跨平台支持的 IAR 构建工具在使用相同的硬件主机的 Linux 上的构建时间，显示出更好的性能（快 4 倍）。在 Ubuntu 上执行标准 C-STAT 静态分析检查所需时间是在 Windows 上的 25%。

更快地交付构建和分析结果意味着持续交付 (CD) 能够更快地收敛。

图表：IAR Embedded Workbench与IAR构建工具的构建时间比较

图中显示的构建时间使用了：

– 574个C/C++源文件

– 最高的编译器优化级别

– 项目构建后进行分析

– 比较基于相同的主机硬件，Intel i7-8700K，24 GB RAM

– 使用 1、2、4和8个CPU内核

同样，一般来说，在 Ubuntu 上使用 IAR 构建工具构建嵌入式软件项目比在 Windows 上使用 IAR Embedded Workbench 构建更快，通常前者构建项目的时间不到后者的 50%。

此外，在现代嵌入式开发工作流程中，采用自动化流程来确保质量并持续构建和测试是一个基本需求。当使用跨平台框架中底层命令行工具实现了相同功能的正确 DevOps 实践时，嵌入式软件研发团队可以实现更短的新功能上市时间。

IAR 解决方案支持 Ubuntu、Red Hat 和 Windows 上的现代可扩展构建服务器拓扑结构，可用于 CI/CD 管道，包括虚拟机、容器 (Docker) 和自我托管的运行器。

审核编辑 ：李倩