适用于芯片行业的开发及管理工具：版本控制、持续集成、代码分析及项目管理工具介绍

2024-04-27
上海
本文字数：6423 字
阅读完需：约 21 分钟

3 月 28 日-29 日，2024 国际集成电路展览会暨研讨会（IIC Shanghai）在上海成功举行。此次盛会汇聚了集成电路产业的众多领军企业，共同探寻和把握集成电路产业的发展脉络。

龙智携芯片研发及管理解决方案亮相展会，展示如何通过集成项目管理-Jira、知识库管理-Confluence、需求管理-Jama、版本控制-Helix Core、静态代码分析-Helix QAC/Klocwork等全球领先工具，及全面专业的支持服务，助力芯片行业客户加速芯片开发与管理。

展会现场，龙智技术工程师巫晓光发表了“数智赋能，加速芯片开发及产品上市”的主题演讲，深入剖析了芯片开发过程中的挑战，分享如何选择并有效利用好的工具，赋能芯片开发和管理，推动企业高效发展。

▽点击观看演讲视频

以下为演讲内容回顾（有删改润色）：

大家好，我是龙智的技术工程师巫晓光，非常荣幸有机会和大家一起分享我在芯片开发当中的一些心得和体会。

首先，简单介绍一下我们公司。龙智是一家专注于DevSecOps领域的服务提供商，已在该领域深耕十多年，致力于帮助企业实现软件开发运营一体化。已先后为国内外 1000 多家的企业提供了咨询、培训、实施、运维及二次开发等服务，帮助客户更科学、安全、高效地管理软件开发，更好、更快地交付软件产品。

众所周知，芯片行业作为典型的资金与知识密集型产业，投资规模巨大，且市场竞争异常激烈。在此背景之下，企业的生产效率就显得尤为重要。正所谓“工欲善其事，必先利其器”，优质的工具能够显著提升企业的生产效率。我今天的演讲内容也将主要聚焦于芯片开发过程中，如何选择并有效利用这些优质工具，从而赋能芯片开发和管理。

版本控制——强大的版本控制工具：Perforce Helix Core

说到版本控制工具，大家应该非常熟悉，在市面上也有一些开源、免费的版本工具，比如 Git、SVN。当企业规模和数据体量比较小，业务也相对单一时，开源的版本管理工具基本能够满足企业的需要。但随着企业规模的扩大及数据量的增长，业务也会变得更加复杂，开源的版本管理工具就会面临很多挑战。

VCS 面临的挑战

首先，版本分支的管理难度会增加，这一点在芯片开发行业中非常突出。我们知道，一个 Fullchip 包括很多的子系统，每个子系统由不同的 IP 组成，每个 IP 又会包括不同的模块，每个模块都有自己的分支。如此一来，分支管理难度就会变得非常复杂。分支多了以后，分支之间的合并也会是一个问题。我们知道，一些开源版本管理工具的合并功能相对较弱，在合并过程中经常会引入一些不必要的冲突，需要耗费很多的人力、物力去解决。

第二个挑战，来自于海量数据。在芯片开发过程中，虽然前端开发的文件体积相对较小，但综合和后端却会产生大量的大文件，这些大文件同样需要进行版本管理。当单个文件的大小超过 10G 时，版本控制系统的提交速度会显著下降，甚至导致提交失败，这严重影响了开发效率。此外，开源管理工具的单个实例是无法支撑大量数据的，一些客户到后期会发现，数据已经达到几百 TB 的级别，不得不将这些数据分散到各个子系统和各个实例中，这无疑会给后期的维护和追溯带来不必要的麻烦。

第三个挑战来自于跨地域协作。芯片企业的规模从几十人到上万人不等，员工分布广泛，可能遍布全国甚至全球的各个研发中心。这种分散的人员分布，也要求版本管理工具有灵活的部署方式，以支撑跨地域团队协作。

第四个挑战来自于安全审计的需求。在芯片开发过程中，由于涉及专利、知识产权和商业机密等敏感信息，文件的安全性和权限控制尤为重要。此外，审计需求也要求版本管理工具能够提供完备的日志记录，以便后期进行追踪和追溯。

然而，随着企业面临的安全和审计问题日益增多，开源版本管理工具的局限性也逐渐暴露出来。这些工具往往无法满足企业对严格权限控制和完备日志的需求，导致企业的生产效率下降，管理成本上升。虽然企业在初期可能在版本控制工具上节约了开支，但长期来看，这种选择实际上给企业带来了巨大的隐性成本。因此，企业需要寻求更加高速、安全、强大的版本控制工具。

强大的版本管理工具是研发流程的核心

强大的版本管理工具是研发流程的核心。为什么这样说？我们知道，企业的一些核心资产包括设计资料、代码、配置项、生成物（制品）等，最终都会转化为数字资产，存储在版本控制工具中，而所有的研发行为都是围绕数字资产展开的。所以使用强大的版本控制工具，可以实现在单一平台上，安全、高速地管理企业的所有数字资产。

Perforce Helix Core正是这样一款强大的版本管理工具，它具备诸多功能特点，能够为企业提供全面的版本控制解决方案。

强大的版本控制工具——Perforce Helix Core

首先，Perforce Helix Core具有良好的伸缩性。当企业规模比较小，只有几十个用户时，使用 Helix Core 非常灵活。当企业发展到几万名用户，数据增长到数百个 GB 时，Helix Core 也能够为其提供良好的支撑。

其次，Perforce Helix Core 部署非常灵活，具有成熟的分布式的部署能力，能够支撑全球团队高效协作。它还能够支撑每天数以千计的流水线的构建。很多企业前台会用到 Git，Perforce Helix Core 可以与 Git 兼容，并作为后台的一个强大支撑。此外，Helix Core 灾备方案也非常容易，具备统一的企业级的灾备计划。

另外，Helix Core 的权限控制也非常灵活，其权限控制力度可以达到文件级别。日志也非常完备，以便于后期审计追踪，比如谁进行了修改、访问，以及在什么时间进行的修改或访问，都可以进行完备记录。

同时，Helix Core 的界面也非常友好，可与各个类型的客户端兼容，同时与芯片行业的主流 EDA 工具也能够良好集成。

持续集成——企业级 Jenkins：CloudBees CI

说到 CI/CD 工具，大家很自然的会想到 Jenkins。不可否认的是，Jenkins 非常强大。据报告统计，全球超过 70%的开发者在使用 Jenkins，而且这个数量还在持续增长。Jenkins 已有超过十年的发展，成熟而稳定。其庞大的生态系统，有超过 1,800 个插件可满足各种各样的功能扩展。Jenkins 还有出色的集成能力，几乎可以与任何平台、任何软件集成。

Jenkins 面临的挑战

既然 Jenkins 如此强大，是不是使用 Jenkins 就可以高枕无忧了？很遗憾，答案是否定的。在我们日常的咨询服务中，客户经常反映使用 Jenkins 会遇到各种各样的问题。具体有哪些问题呢？首先，我们一起来看下面这张图：

该图是一个非常典型的 Jenkins 的部署场景。从图中可以看到这家公司有很多部门，每个部门都有自己的 Jenkins 实例，这些实例由部门的 DevOps 团队或者公司统一的 DevOps 团队来维护。我们把这种部署方式称为“Jenkins 孤岛”。“孤岛”的形容非常贴切，因为从图上可以看到，这些 Jenkins 实例相互隔离，之间没有任何联系，各自的实例都是按照各自的规则和实践在运行，使得资源和经验无法共享。

这样一种部署方式，会给管理带来哪些问题呢？

首先，难以集中高效管理多个 Jenkins 实例。我们知道，Jenkins 实例的维护其实是非常繁琐的，涉及到插件的安装、升级、配置以及权限的设置、脚本的编写等等。若公司有 100 个 Jenkins 实例，就需要在 100 个 Jenkins 实例上进行重复配置，这是非常耗时耗力的。另外，从全局运维的角度来看，也难以真正了解到每一个 Jenkins 实例的运行状态。

从图上可以看出，Agent 属于具体的 Jenkins 实例，这又带来一个问题——资源分配的不平衡。当 Agent 属于特定的 Jenkins 实例时，不同部门或项目之间的业务繁忙程度差异会导致资源利用的不均衡，可能会出现闲置的 Agent 造成资源浪费，繁忙的部门则可能因资源不足而影响工作效率，这种就是 Jenkins 孤岛在管理上的问题。很多企业为了解决这一问题，倾向于减少 Jenkins 实例的数量，将所有内容部署在少数的 Jenkins 实例上，不过这又会带来另外一个问题——巨型 Jenkins。

下面我们再来看一下，这种巨型 Jenkins 所带来的问题。

上图是一个典型的 Jenkins Master 的分布式架构，可以看到，中间的 Jenkins Master 作为中枢接收各种触发器，比如代码管理工具、流程管理工具触发的任务命令，当 Master Jenkins 实例接收到这些任务时，会将任务分派给各个 Slave 节点去具体执行。对于此种部署架构，我们会发现，当把更多内容集中到某个单一的 Jenkins 实例时，Master Jenkins 实例就会成为一个性能瓶颈。因为开源的 Jenkins 是不支持高可用的，无法将负载分摊到其他的 Jenkins 实例上，这样又会导致一些后果。

首先，会导致服务器响应减缓，任务执行时间延长，甚至部分任务因无法及时响应而停滞在队列中。随着负载的增加，Master Jenkins 实例可能面临宕机风险，引发单点故障，进而导致整个系统崩溃，严重影响工作进程。

此外，除了性能问题，插件之间的兼容性也是一大挑战。当多个项目和内容集中部署在少数 Jenkins 实例上时，需要安装多种插件以满足不同需求。然而，插件之间以及插件与 Jenkins 本身之间可能存在兼容性问题。比如在处理安全漏洞或升级 Jenkins 时，需要仔细选择和调整插件版本，以确保系统稳定性。若处理不当，可能导致系统崩溃，造成不可预测的后果。

当遇到这些问题时，我们推荐客户使用CloudBees CI。

企业级 Jenkins — CloudBees CI

国内客户对于 CloudBees CI 可能比较陌生，其实 CloudBees CI 是 Jenkins 商业版，Cloudbees 是 Jenkins 代码的最大贡献者。接下来，我们一起来了解企业级 Jenkins—— CloudBees CI 在开源的 Jenkins 上做了怎样的改良。

上图中可以看到，在开源的 Jenkins 架构之上，我们增加了一个 Operations Center 来集中管理所有的 Jenkins 实例。在此架构下，团队可以自主控制 Jenkins 实例，同时这些实例也受到 Operations Center 的集中管理。

全面运维方面，团队也可以通过 Operations Center 清楚了解到每一个 Jenkins 实例的运行状态。另外，Agent 不再属于某一个具体的 Jenkins 实例，而是属于整个集群，即所有 Jenkins 实例之间可以共享一个 Agent。

关于插件的兼容性问题，CloudBees 也可以妥善解决。在升级 CloudBees CI 时，我们会将常用且经过兼容性验证的几百个插件，打包至 CloudBees CI 安装包，一旦 CloudBees CI 升级，打包的插件也会自动升级。

上图是 CloudBees CI 的具体界面。界面中间的 Operations Center 提供一个统一视图，便于用户查看各个 Jenkins 实例的运行状态，也可以通过 Operations Center 轻松创建 Jenkins 实例。此外，可以通过 Operations Center 进行统一集中管理，比如统一升级 Jenkins 实例或插件、统一备份、统一重启等，从而简化管理工作，提升管理效率。

在性能方面，CloudBees CI 也提供了高可用的解决方案。

如上图所示，可以在 Jenkins 实例前面搭建负载均衡器，后端共享其文件系统以优化资源利用。有了高可用方案，可为 Jenkins 配置多个节点，有效防止单点故障。当负载过大时，可以将负载均衡地分配至多个节点，从而保证性能。此外，CloudBees CI 也结合了 K8s 的特性，通过滚动升级的方式来实现零停机要求。节点的弹性伸缩也非常方便，可通过监控 CPU 的使用情况来按需创建，比如 CPU 达到 80%时，系统将自动创建新节点。

质量与合规——静态代码分析工具：Perforce Helix QAC & Klocwork

说到质量与合规，我们都知道，代码质量在芯片行业中尤为关键，特别是芯片广泛应用于航天航空、医疗等高精度领域，而这些行业对代码质量的要求极高。不过，经验再成熟的软件开发人员也难以完全杜绝 Bug 的产生，对此，我们可以通过调整发现 Bug 的时机和方法来减少 Bug，以更好地确保代码质量。

上图显示的是代码质量与企业成本之间的关系。横坐标代表软件的各个生命周期，比如代码阶段、单元测试阶段、功能测试阶段、系统集成及发布阶段。其中，蓝色曲线表示 85%的 Bug 在开发阶段产生；橙色曲线表示发现 Bug 的时机集中在测试阶段，开发阶段基本没有发现 Bug；红色曲线代表修复 Bug 的成本，可以看出，成本随着生命周期的推进在不断增加。

这并不难理解，因为开发阶段的环境相对简单，一旦出现 Bug，修复也相对容易。到了测试阶段，不仅涉及测试人员准备测试用例，也涉及开发人员的参与和沟通，成本会显著增加。到了后期的系统集成和发布阶段，成本更是呈指数级增长。因此将 Bug 发现时机左移至开发阶段就显得尤为重要了。

尽管很多企业已经尝试这样做，但大多采用人工审核的方式，具有明显的局限性。这种方式高度依赖个人经验，若没有严格要求，可能更多关注命名不规范或大小写的问题。并且，代码数量通常很庞大，有些软件甚至达到几百万行的级别，人工审核是难以完全覆盖和应对的。因此，我们推荐引入静态代码扫描工具，以更全面、高效地检测潜在 Bug。

简单介绍一下静态扫描工具的原理，其原理是利用标准、权威的一些代码标准和规则，去扫描代码，及时帮助发现潜在问题。使用静态扫描工具可以有效地在代码阶段发现代码质量问题。

一款优质的静态扫描工具，需具有误报率及漏报率低、检查规则全面、扫描速度快、对开发人员友好、易与 CI 工具集成等特点。也需满足合规标准与要求，常用的一些代码标准，比如 MISRA C， C++， AUTOSAR C++、CERT、CWE 等，静态代码扫描工具都能够覆盖。对于汽车、航空等行业来说，还需要满足各种行业合规标准，如：