1. 测试系统部署与版本管理导论

在开始学习具体的部署操作和版本控制命令之前，有必要先建立一张"全景地图"：一个典型的 LabVIEW 测试系统到底由哪些部分组成，为什么它比普通桌面软件更难部署，以及版本管理在测试领域究竟要解决什么问题。本章不涉及具体操作，而是为后续 29 章建立共同的概念基础和判断标准。

1.1 一个 LabVIEW 测试系统由什么构成

从部署与版本管理的视角看，LabVIEW 测试系统可以划分为五个层次，它们各自有独立的版本、依赖和变更节奏：

• 硬件层：PXI/PXIe 机箱、DAQ 模块、串口/CAN/GPIB 仪器、相机、PLC 等。硬件本身有驱动版本（如 NI-DAQmx 2023 Q1、VISA 7.2），驱动与 LabVIEW 版本存在兼容矩阵。
• 驱动与运行时层：NI-DAQmx、NI-VISA、NI-488.2、LabVIEW Run-Time Engine（RTE）、.NET/ActiveX 依赖。这一层决定了程序能否在目标机上"跑起来"。
• 代码层：LabVIEW 项目（.lvproj）、VI、子 VI、类（LVClass）、库（LVLib）、XControl、DLL 调用、MathScript 节点。代码层是版本管理的主要对象。
• 配置与数据层：INI/XML/JSON 配置文件、测试序列（TestStand 序列文件）、标定参数、通道映射表、数据库连接串。这一层常被忽略，却是"同一份代码在不同产线表现不同"的常见原因。
• 部署与运行环境层：目标机操作系统版本、用户权限、防火墙、共享目录、许可证（License）、安装包（Installer）与部署规范。

这五层之间存在明确的依赖方向：上层依赖下层，但版本约束是双向的。例如 LabVIEW 2021 无法调用为 LabVIEW 2023 编译的 PPL（Packed Project Library），而 DAQmx 2024 可能要求 LabVIEW 2020 以上。理解这种"双向约束"是后续所有部署决策的基础。

1.2 部署与版本管理的核心挑战

LabVIEW 测试系统的部署难点，与普通 Web 或桌面软件有本质区别，主要体现在四个方面。

第一，图形化代码的二进制特性。LabVIEW 的 VI 是二进制文件，无法像文本代码那样逐行 diff。两个 VI 的差异只能通过"比较"工具查看，且合并冲突时往往需要人工介入。这意味着版本管理策略必须更保守：小步提交、频繁打标签、避免多人同时修改同一 VI。

第二，依赖链长且隐式。一个测试程序可能依赖 30 个驱动、5 个 DLL、2 个 PPL 和 1 个 RTE。这些依赖不会全部出现在项目文件中，部分通过"动态调用"在运行时才解析。部署时若漏装一个驱动，程序可能在开发机上正常、在产线上报错。因此需要建立"依赖清单"并纳入版本管理。

第三，环境漂移。开发机、测试机、产线机往往安装不同版本的 LabVIEW 和驱动。同一份源代码在不同环境下编译出的可执行文件行为可能不同。解决思路是"锁定环境"：记录开发环境的完整版本快照，并在部署前校验目标机。

第四，配置与代码分离不彻底。很多团队把通道映射、阈值、标定系数硬编码在 VI 中，导致每次换产线都要改代码、重新编译、重新部署。正确做法是把这些参数外置为配置文件，代码只负责读取和校验。

1.3 课程目标与学习路径

本课程的目标不是让你记住所有命令，而是建立一套可执行的部署与版本管理方法。学完后，你应当能够：

• 为一个 LabVIEW 测试项目建立完整的依赖清单和环境快照；
• 使用 Git 管理 LabVIEW 项目，并正确处理 VI、LVClass、PPL 的版本控制；
• 制作可复现的安装包（Installer），并在目标机上验证部署结果；
• 设计分支策略，支持开发、测试、产线三套环境的并行演进；
• 在出现"版本不一致"故障时，快速定位是代码、驱动、配置还是环境问题。

学习路径按"认知—工具—实践—治理"四段推进：