4、环境搭建：Python虚拟环境配置、Docker容器化部署、Git版本控制初始化

好，咱们进入第四节。说实话，环境搭建这块，很多工程师觉得「不就是装个软件嘛」，结果项目一跑起来全是坑。我见过太多人因为Python包冲突、Docker镜像拉不下来、Git提交乱成一锅粥，白白浪费一整天。

今天咱们就把这三件事一次性捋清楚。你跟着我的节奏走，保证后面30个章节的实战，环境上不会卡你一下。

4.1 Python虚拟环境配置

为什么要搞虚拟环境？说白了，就是隔离。你想想看，一个项目用dSPACE的Python API，另一个项目用pytest做自动化测试，它们依赖的库版本可能完全不一样。混在一起，迟早要炸。

我个人习惯用 venv，Python 3.3以后自带的，轻量又干净。别用 virtualenv 了，多装一个包没必要。

核心操作：

# 创建虚拟环境（在项目根目录下执行）
python -m venv .venv

# 激活虚拟环境（Windows）
.venv\Scripts\activate

# 激活虚拟环境（Linux/Mac）
source .venv/bin/activate

# 安装项目依赖
pip install -r requirements.txt

# 退出虚拟环境
deactivate

这里有个坑，我踩过好几次。如果你用PyCharm，它会自动帮你创建虚拟环境，但默认路径藏在项目外面。我建议你手动指定 .venv 放在项目根目录，这样Git提交时一眼就能看到，也方便别人拉下来直接激活。

我的小技巧： 在 requirements.txt 里，别写死版本号，用 >= 宽松一点。比如 dspace-python-api>=1.2.0。为什么？因为dSPACE的API经常有小版本更新，写死了后面升级麻烦。

嗯，还有一个细节。激活虚拟环境后，记得检查一下 pip 版本：

pip list
pip install --upgrade pip

我遇到过好几次，老版本pip安装某些包会报错，升级一下就解决了。

4.2 Docker容器化部署

Docker这东西，一开始我觉得「不就是个虚拟机嘛」，后来真用上了才发现，它比虚拟机轻太多了。尤其是在HIL测试环境里，你需要在不同机器上复现一模一样的测试环境，Docker就是最佳方案。

咱们这个课程里，我会用Docker来封装dSPACE的测试运行环境。你想想看，以后新同事入职，不用再折腾半天装Python、装库、配环境变量，直接 docker run 就完事了。

Dockerfile 示例：

# 基于Python 3.9镜像
FROM python:3.9-slim

# 设置工作目录
WORKDIR /app

# 复制依赖文件
COPY requirements.txt .

# 安装Python依赖
RUN pip install --no-cache-dir -r requirements.txt

# 复制项目代码
COPY . .

# 默认命令
CMD ["python", "run_tests.py"]

构建和运行命令也很简单：

# 构建镜像
docker build -t hil-test-platform:1.0 .

# 运行容器（挂载本地目录，方便调试）
docker run -v $(pwd)/testcases:/app/testcases hil-test-platform:1.0

注意： 如果你在Windows上用Docker Desktop，记得把文件共享设置好。我曾经因为没开共享，容器里死活读不到本地文件，折腾了半小时才发现是权限问题。

还有一个实战经验：dSPACE的硬件驱动（比如RTI、ControlDesk）通常不能直接跑在Docker里，因为需要访问底层硬件。所以我的做法是——把测试逻辑和数据处理放在Docker里，硬件交互部分留在宿主机。这样既隔离了环境，又不影响硬件访问。

4.3 Git版本控制初始化

Git这块，我不打算讲太多基础操作，什么 add、commit、push 你肯定都会。我想重点说说HIL测试项目里，Git怎么用才不乱。

我见过最惨的一个项目，测试脚本、测试数据、报告、配置文件全堆在一个仓库里，分支乱得像蜘蛛网。后来重构了一次，才把规矩立起来。

我的推荐结构：

hil-test-platform/
├── .gitignore
├── README.md
├── requirements.txt
├── Dockerfile
├── src/                  # 测试框架源码
│   ├── __init__.py
│   ├── test_runner.py
│   └── utils.py
├── testcases/            # 测试用例（按模块分）
│   ├── module_a/
│   └── module_b/
├── config/               # 配置文件
│   ├── device_config.yaml
│   └── test_params.json
├── reports/              # 测试报告（不提交到Git）
│   └── .gitkeep
└── scripts/              # 辅助脚本
    └── setup_env.sh

.gitignore 文件里，我建议至少加上这些：

# Python
__pycache__/
*.pyc
.venv/
*.egg-info/

# IDE
.idea/
.vscode/

# 测试报告和日志
reports/
*.log

# Docker
.dockerignore

初始化命令很简单：

git init
git add .
git commit -m "初始化HIL测试平台项目结构"

避坑指南： 我曾经犯过一个错——把 .venv 提交到了Git仓库。结果团队里每个人拉下来，虚拟环境路径都不一样，根本没法用。所以记住，虚拟环境永远不要提交，用 requirements.txt 来管理依赖。

分支策略上，我建议用最简单的「主分支+功能分支」模式：

  • main 分支：只放稳定版本，每次提交前必须跑通所有测试
  • dev 分支：日常开发，可以频繁提交
  • 功能分支：比如 feature/add-docker-support，开发完合并到 dev

嗯，最后说一句。Git提交信息别写「update」或者「fix bug」这种废话。我要求团队用「动词+对象+原因」的格式，比如：

feat: 添加Docker支持，解决环境不一致问题
fix: 修复test_runner.py中路径拼接错误，导致Windows下无法运行

这样以后翻Git log，一眼就知道每个提交干了什么。

小结

今天这三件事，说白了就是给咱们的测试平台打好地基。Python虚拟环境解决依赖冲突，Docker解决环境一致性，Git解决版本混乱。这三板斧下去，后面写代码、跑测试、协作开发，都会顺畅很多。

下一节，咱们开始搭建dSPACE的测试框架核心——测试用例的加载和执行引擎。到时候你会看到，今天配的环境会怎么用起来。

← 上一章 📖 返回目录 下一章 →