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

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等，静态代码扫描工具都能够覆盖。对于汽车、航空等行业来说，还需要满足各种行业合规标准，如：

在这里插入图片描述

这里为客户分享两款静态代码扫描工具——Perforce Helix QAC和Klocwork。该两款工具在满足上述要求外，各有其特点与优势，能够帮助开发人员更好地进行代码扫描。
在这里插入图片描述

项目管理——项目管理工具Jira：为芯片开发提供全面支持

最后一部分是关于项目管理。对于芯片行业来说，项目管理面临着很多挑战：

多个开发中心需要跨地域协作；
职能部门及业务繁多，导致管理难度增大；
”流程管理为主，人治为辅”的管理方式转变迫在眉睫为了响应集团的数字化转型，研发过程体系也要数字化（ALM系统），包括产品管理、项目管理、测试管理、效能管理等功能模块；
工具链过时、离散，无法支持透明、高效的项目管理。

客户需要怎样的项目管理平台？我们认为，该管理平台应具备如下特点：
提升项目透明度、项目过程质量、多地协同办公工作效率；
帮助实现项目全生命周期精细化管理；
融入业界优秀实践（IPD、敏捷等），提升企业竞争力；
从多维度对研发工作进行度量，为管理层决策和过程改进提供数据支撑；
支持处理大量数据；
支持不同工具/系统数据互联。

Jira作为功能强大的项目管理工具，为芯片开发提供全面的支持
对此，我们为客户推荐的是Atlassian旗下的Jira产品。作为一款功能强大的项目管理工具，Jira可以为芯片开发提供全面支持，覆盖需求管理、缺陷管理、实时报告、集成能力以及安全高可用各个方面，帮助芯片团队更高效、更安全地开发。
在这里插入图片描述