硬件版本控制系统的最佳实践

有些 PCB 项目足够简单，并不需要由大型团队中的多位设计人员协同完成。设计文件基本上有两种形式：初始项目文件，以及设计完成后的最终项目文件。按照我们团队的工作方式，我们通常会先从客户那里收到一些设计文件来帮助启动项目，之后的一切都需要我们自己管理。任何项目都可能变得非常复杂，因此 PCB 设计团队需要在整个项目过程中跟踪各个版本修订。

为什么要关注硬件版本修订跟踪？如果你收到产品功能需求变更、产品架构发生重大调整，或者准备最终定稿并进入制造阶段，那么最佳做法是在当前状态下克隆项目，并开始处理新版本。在 PCB 设计项目中跟踪所有这些设计变更，需要借助适合 PCB 设计人员使用的硬件版本控制工具，而你可以在 Altium Agile Teams 中找到这类工具。本文将讨论硬件版本控制最佳实践以及版本编号最佳实践。

值得注意的是，版本控制只是一个更广泛领域的一部分，这个领域称为硬件配置管理（Hardware Configuration Management，HCM）。它不仅涵盖文件变更跟踪，还包括基线定义、变更控制流程，以及贯穿整个产品生命周期的配置审计。 

在 HCM 和 PCB 设计中，最佳实践是将 PCB 项目、元件库、制造输出文件以及机械图纸视为统一配置，在关键里程碑建立基线，并在修改前经过正式的变更审批。 

本文将讨论硬件版本控制最佳实践以及版本编号最佳实践。

硬件版本控制包含哪些内容？

硬件版本控制包括哪些内容，又应该在什么时候使用？进一步说，它到底需要具备什么？自从 Linus Torvalds 于 2005 年创建 Git 以来，软件领域就一直在使用版本控制，而真正实用的硬件版本控制系统直到近些年才逐渐跟上。硬件版本控制提供了一种简单的方法，用于跟踪 PCB 设计项目中较早版本的电子设计数据，涵盖从原理图到制造文档和机械图纸的所有内容。

版本控制管理系统负责跟踪硬件变更，并管理任何信息集合（包括 PCB 设计数据）的连续变更。在我看来，只要条件允许，电子设计中的版本控制就是一项必须利用的功能，尤其是在你的团队需要与多位协作者共同处理复杂 PCB 设计项目时。优秀的硬件开发版本控制系统应提供一些重要功能和信息：

• 项目修订的时间顺序列表。 任何新增或删除的设计文档、PCB 设计数据变更、提交日期以及关于设计修订的任何注释，都应能够按时间顺序查看。 
• 是谁进行了这些更改。 修订历史中列出的每项变更及其提交者，都应与对应的硬件修订一起显示。 
• 已创建的 PCB 项目发布版本。 每当创建包含输出文件的项目发布版本时，该发布版本都应能在修订历史列表中查看和访问。 
• 能够下载或克隆每个修订版本。 将项目的先前修订克隆为新版本的能力，是版本控制的核心。 

对于硬件工程团队而言，最有效的 DevOps 工作流应围绕基于云的 PCB 平台展开，在同一环境中统一实现版本控制、设计规则检查和发布管理，而不是将多个独立工具拼接在一起。这种方式无需专门的 DevOps 资源来维护自定义流水线，并且能让持续集成（CI）流程保留在工程师日常工作的设计流程内部。

硬件持续集成意味着自动化检查作为发布流程的一部分运行，而不是在交付前手动执行。DRC、ERC、BOM 验证以及输出文件生成都会在发布上传之前完成验证。 

在 Altium Agile Teams 中，验证检查会在发布阶段自动运行；如果有任何检查未通过，发布就会失败。这与传统意义上每次提交都触发的 CI 运行器并不完全相同，但它实现了核心目标：也就是，任何设计在通过一组预定义的自动化检查之前，都不会进入制造阶段。

版本控制系统可以在本地服务器上跟踪所有这些数据和修订，也可以通过托管服务器在云端进行跟踪。这样你就可以访问项目的早期版本，无论是为了回滚/克隆到先前状态，还是仅仅为了出于其他目的下载旧项目数据。

何时使用硬件版本控制来克隆项目

无论你是在跟踪软件项目修订还是 PCB 设计数据，都可能因为多种原因需要回退到较早的项目版本。如果你确实打算在版本控制系统中克隆项目，以下是一些应该考虑克隆项目的情况。

功能需求变更

客户或工程团队可能会因为各种原因更改产品的功能需求。当发生这种变化时，一个好的做法是在项目当前状态下进行克隆，并在克隆后的项目上应用修订。通过 将项目分叉为新版本，如果新的功能需求最终被放弃，你始终可以回退到之前的项目。

元件变更

在开始新设计之前，尤其是在开始新的 PCB 布局之前，你始终都应该先清理并核查 BOM。即使你很早就检查过元件库存，供应链也可能迅速变化，某些关键元件可能已经变为 EOL、LTB、NRND、obsolete，或者缺货。

如果这种情况发生在 MCU、FPGA 或其他专用 IC 上，替代元件可能会采用完全不同的引脚定义。在这种情况下，你可以克隆当前项目，并在新项目中放置新元件。如果旧元件之后重新可用，只需回退到旧项目即可。我发现，当客户非常坚持使用某个他们实际上无法采购到的 MCU，但又希望得到一块可制造且元件可采购的电路板时，这种做法特别有用。当你把两个版本的项目都交给他们时，他们肯定会非常满意。

准备制造

一旦你将设计数据发布给制造商（并且支付了 NRE 费用），他们可能会对布局或输出文件做一些修改。我总是在将最终项目发布给制造厂之前先复制一份，然后告诉他们的团队可以根据需要进行任何修改。通常他们会把一套设计文件发回给你，其中已经直接应用了所需修改。

在下图中，Altium Designer 让你无需通过网页浏览器，就可以轻松在由 Altium 365 管理的内容服务器上克隆项目。我已经将该项目纳入版本控制，并与我 Workspace 中的文件同步，但我仍然可以轻松克隆该项目，并将新副本保存到我的 Workspace 中；无需先下载再重新上传克隆后的项目。我还可以将这个克隆项目用作新的变体、在新设计中复用，或根据需要将其作为备份。

在 PCB 设计项目中使用硬件版本控制，还有许多其他方式和理由。无论你需要完成什么任务，都需要使用能够直接与 PCB 设计软件集成的世界级数据管理系统。

上述克隆方法本质上是一种分支策略。对于硬件-固件协同团队，更实用的模型是：保持一个稳定的主分支，仅接收经过审查的变更；硬件和固件的功能开发则分别在独立分支上进行，并在预定义的同步点进行集成。凡是会影响固件的变更，例如新增外设或引脚变更，都应在合并前明确标记，以便固件工程师及时响应。有些团队会将共享接口文档或 HAL 文件纳入版本控制，作为两个领域之间正式交接的依据。

元件库是硬件版本控制中最容易被忽视的领域之一。对于分布式团队来说，管理松散的元件库几乎必然会成为错误来源。例如，一位工程师更新了封装，另一位却没有拉取该变更，结果两个不同版本最终都进入了生产。 

更好的做法是将元件库视为版本化工件。也就是说，将其与设计文件一起存储，应用相同的发布和审批流程，并确保设计引用的是特定的元件库版本，而不是始终漂移的最新版本。像 Altium Agile Teams 这样的平台通过将元件库集中到工作区中来实现这一点，从而确保所有团队成员都从同一个已批准的来源获取数据。

在规模较大的团队中，硬件配置管理越来越多地成为一个专门岗位，而不再是大家共同分担的职责。其核心技能既包括技术层面，也包括流程层面。你需要熟悉版本控制系统，理解 PCB 设计数据格式和发布工作流，具备变更控制和 ECO 管理经验，并能够胜任配置审计和文档控制。大多数 HCM 从业者都具有 PCB 设计或系统工程背景。

Altium Agile Teams 是 PCB 与硬件版本控制的未来

版本控制是一个简单却强大的概念，更多设计人员应该有意识地去采用它。刚开始 与远程团队协作 时，每位设计人员都会在自己的本地计算机上跟踪各自的一系列项目修订。在某些情况下，客户会使用专有系统来处理这些任务。这些解决方案效率低下，而且第三方解决方案也无法与你的 PCB 设计软件集成。

软件中使用的同样版本控制流程，也可以通过 Altium Agile Teams 用于硬件版本控制。 设计团队可以通过将设计人员、最终用户和制造商纳入开发流程，建立高效且协作顺畅的 PCB 设计工作流。团队中的每个人都可以访问供应链数据、评论功能和数据共享工具，从而帮助简化 PCB 设计协作。 了解更多关于 Altium Agile Teams 的信息 →