2. 环境准备与工具链：Python环境配置、虚拟环境管理、版本控制与依赖管理

说实话，很多同学写升级脚本翻车，不是逻辑写错了，而是环境没搭对。我见过太多人直接在系统 Python 里 pip install，结果某天升级一个包，把系统工具搞崩了。嗯，咱们先把地基打牢。

2.1 Python 环境配置

我个人习惯用 Python 3.8+ 来写升级脚本。为什么？因为 3.6 以下已经停止安全更新了，而 3.11+ 有些第三方库还没跟上。

2.2 虚拟环境管理

为什么要用虚拟环境？说白了，就是给每个项目一个独立的 Python 小房间。你在房间里随便折腾，不会影响到外面的系统。

2.2.1 venv（Python 内置）

Python 3.3 以后自带的，不用额外安装。我个人最常用它，轻量、简单。

# 创建虚拟环境
python -m venv upgrade_env

# 激活（Linux/Mac）
source upgrade_env/bin/activate

# 激活（Windows）
upgrade_env\Scripts\activate

# 退出
deactivate

2.2.2 pipenv（更高级的封装）

pipenv 把 pip 和虚拟环境管理合二为一，还自动生成 Pipfile 和 Pipfile.lock。适合需要精确锁定依赖版本的项目。

# 安装 pipenv
pip install pipenv

# 创建虚拟环境并安装依赖
pipenv install requests

# 激活虚拟环境
pipenv shell

# 生成 requirements.txt
pipenv lock -r > requirements.txt

我遇到过一种情况：团队里有人用 venv，有人用 pipenv，结果 requirements.txt 格式不统一，CI 构建老报错。后来我们统一用 venv + requirements.txt，简单粗暴，反而少了很多麻烦。

2.3 版本控制工具（Git）

升级脚本不放在 Git 里？那你胆子真大。我见过有人直接在服务器上改脚本，改完忘了备份，回滚的时候欲哭无泪。

2.3.1 基本配置

# 设置用户信息
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# 初始化仓库
git init

# 添加文件并提交
git add upgrade_script.py
git commit -m "feat: 初始版本升级脚本"

2.3.2 分支策略

我个人习惯这样管理升级脚本：

• main：稳定版本，只合入经过测试的代码
• develop：开发中的脚本
• feature/xxx：某个特定升级功能的开发分支
• hotfix/xxx：紧急修复分支

2.4 依赖管理（requirements.txt）

这个文件就是你的脚本的「购物清单」。别人拿到它，一条命令就能装好所有依赖。

2.4.1 标准格式

# requirements.txt
paramiko==2.12.0
requests==2.31.0
pyyaml==6.0.1
# 不指定版本，默认装最新
jsonschema

2.4.2 生成与安装

# 生成当前环境的依赖列表
pip freeze > requirements.txt

# 从文件安装依赖
pip install -r requirements.txt

2.4.3 依赖版本锁定策略

2.5 知识体系总览

下面这张图把本章的核心脉络串起来了。你跟着它走一遍，心里就有底了。

2.6 实战：搭建一个完整的升级脚本项目

咱们把上面这些知识点串起来，走一遍完整的流程。

# 1. 创建项目目录
mkdir db_upgrade_project
cd db_upgrade_project

# 2. 初始化 Git
git init

# 3. 创建虚拟环境
python -m venv venv
source venv/bin/activate

# 4. 安装依赖
pip install paramiko pyyaml

# 5. 生成依赖文件
pip freeze > requirements.txt

# 6. 创建 .gitignore（忽略虚拟环境目录）
echo "venv/" >> .gitignore
echo "__pycache__/" >> .gitignore

# 7. 第一次提交
git add .
git commit -m "chore: 初始化升级脚本项目"