浅析如何创建和使用Shell脚本实现PHP部署自动化

传统部署方式的困境

如果你的 PHP 部署流程还停留在这样一个阶段：

• SSH 登录服务器
• git pull
• composer install
• 可能跑一下 php artisan migrate
• 清一些缓存
• 重载 PHP-FPM 或 nginx
• 然后双手合十祈祷

这个流程乍一看也能跑，但一旦遇到以下情况，就开始暴露问题了：

• 你要管理多台服务器
• 你需要快速回滚
• 你忘了某个小步骤，然后生产环境炸了
• 团队里其他人的操作方式跟你不太一样

到了那个时候，部署就不再是一个简单的任务了——它变成了一种仪式，脆弱、没有文档，而且只有“知道确切步骤”的那个人才能搞定。

一个非常直接有效的解决方案，就是写一个 Shell 脚本。

你不需要 Kubernetes、Terraform，也不需要一整套 CI/CD 平台来实现真正的部署自动化。一个写得好的 shell 脚本可以做到：

• 把 15 条手动命令变成一条可重复执行的命令
• 让你的部署过程用代码记录下来
• 减少人为错误和“哎呀，我忘了清缓存”的时刻
• 成为后续 CI/CD 流水线的构建基础

这篇文章会从 PHP 开发者的角度出发，带你一步步吃透以下内容：

• Shell 脚本基础
• 为 PHP 应用构建一个简单的部署脚本
• 用安全检查、日志、回滚来改进它
• 用 releases/ 和 current/ 符号链接组织部署
• 把脚本接入 Git 或 CI

读完这篇文章，你将拥有一个可以直接适配到自己项目中的部署脚本——无论是 Lara vel 项目、自定义 PHP 后端，还是其他业务系统，都能用上。

PHP 应用部署的核心步骤

在写任何脚本之前，先搞清楚在你的场景下，“部署”具体意味着什么，这会非常有帮助。

在 Linux 服务器上，一个典型的 PHP 部署流程通常包含以下环节：

获取代码

• 克隆仓库（或拉取最新更改）
• 切换到特定的分支或标签

安装依赖

• composer install --no-dev --optimize-autoloader
• （可选）前端：npm ci && npm run build

准备环境

• 确保 .env 文件存在
• 链接共享目录（上传文件、storage、日志）

运行维护任务

• 数据库迁移：php artisan migrate --force
• 清除/优化缓存：php artisan config:cache、route:cache 等

切换版本并重启服务

• 更新符号链接指向新版本
• 重载 PHP-FPM（systemctl reload php-fpm）
• 可能需要重启队列 worker

可选：回滚

• 如果出问题，能够切换回上一个版本

你的脚本的工作，就是把这一切用可靠、可重复的方式编码下来。

Shell 脚本入门（PHP 开发者视角）

如果你对 PHP 很熟悉但对 shell 脚本还不太了解，别担心，下面这些 Bash 基础足够让你上手干活。

每个 shell 脚本的开头，都要有一行声明，告诉系统该用哪个解释器来执行。这行代码就是：

#!/usr/bin/env bash

有了它，你的脚本就可以像其他命令一样直接执行了。

让脚本可执行

创建一个文件：

nano deploy.sh

写入：

#!/usr/bin/env bashecho "Deploying PHP app..."

保存，然后：

chmod +x deploy.sh./deploy.sh

你应该会看到：

Deploying PHP app...

这样你的第一个 shell 脚本就跑起来了。

快速失败：set -euo pipefail

在脚本顶部（shebang 之后），加上：

set -euo pipefail

这行代码做了三件重要的事：

• -e：如果任何命令返回非零退出码，脚本就退出
• -u：把未设置的变量当作错误
• -o pipefail：如果管道 cmd1 | cmd2 中 cmd1 失败了，整个管道都算失败

这就像告诉你的脚本：“如果出了任何问题，就停下来。别继续跑然后假装一切正常。”

变量和参数

基本变量：

APP_NAME="my-php-app"REPO_URL="git@github.com:yourname/your-app.git"

访问位置参数：

ENVIRONMENT="${1:-production}"  # 如果没提供参数，默认是 production

运行：

./deploy.sh staging

在脚本里，$ENVIRONMENT 就是 staging。

函数

你可以用函数来组织脚本：

deploy() {    echo "Deploying to environment: $ENVIRONMENT"}rollback() {    echo "Rolling back..."}

调用它们：

case "${1:-deploy}" in  deploy)    deploy    ;;  rollback)    rollback    ;;  *)    echo "Usage: $0 [deploy|rollback]"    exit 1    ;;esac

这种模式能让你的脚本更易读、更好维护。

退出码

• exit 0 → 成功
• exit 1 → 通用失败
• 其他代码可以表示特定错误（可选但挺好）

了解了这些基础，你就可以开始自动化真正的工作了。

构建简单的 PHP 部署脚本（单服务器）

从最常见的单服务器场景入手：

• 单台 Linux 服务器（比如 Ubuntu）
• Nginx + PHP-FPM
• PHP 应用在 /var/www/myapp
• 你通过 SSH 登录服务器然后运行 ./deploy.sh 来部署

目录结构

先保持简单：

/var/www/myapp/

├── .git/

├── public/

├── vendor/

├── storage/

└── ...

部署流程：

• git pull
• composer install
• 清缓存
• 重载 PHP-FPM

这是一个最小脚本：

#!/usr/bin/env bashset -euo pipefailAPP_DIR="/var/www/myapp"PHP_FPM_SERVICE="php8.2-fpm"   # 根据你的 PHP 版本调整BRANCH="${1:-main}"            # 默认分支log() {    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"}cd "$APP_DIR"log "Fetching latest code from branch '$BRANCH'..."git fetch --allgit checkout "$BRANCH"git pull origin "$BRANCH" --ff-onlylog "Installing PHP dependencies with Composer..."COMPOSER_ALLOW_SUPERUSER=1 composer install \    --no-dev \    --prefer-dist \    --optimize-autoloader# 如果你用的是 Lara vel 或其他框架，添加框架特定的步骤：if [[ -f artisan ]]; then    log "Running database migrations..."    php artisan migrate --force    log "Clearing and caching Lara vel configuration..."    php artisan config:clear    php artisan config:cache    php artisan route:cache || true  # route cache 在开发环境可能会失败filog "Reloading PHP-FPM service..."sudo systemctl reload "$PHP_FPM_SERVICE"log "Deployment completed successfully."

用法：

chmod +x deploy.sh./deploy.sh              # 部署 main 分支./deploy.sh production   # 如果你想用名为 'production' 的分支

这已经比手动运行每条命令好多了：

• 步骤在脚本里清晰可见
• 如果出问题会快速失败
• 任何有权限的人都能运行同样的流程

但它还可以大幅改进。

增强安全性：备份、检查与回滚

回过头来看，前面那个简单脚本其实存在一个很大的隐患：如果迁移挂了或者部署半途出问题，你唯一的回滚方式是“希望你有备份”。

现在开始给它加一些安全网。

开头的健全性检查

在脚本顶部，在做任何危险操作之前，先检查：

• 你没有意外地在错误的服务器上运行
• 必需的二进制文件存在（git、composer、php、systemctl）

示例：

check_requirements() {    local bins=("git" "composer" "php" "systemctl")    for bin in "${bins[@]}"; do        if ! command -v "$bin" >/dev/null 2>&1; then            echo "Error: required binary '$bin' not found in PATH."            exit 1        fi    done}

尽早调用 check_requirements：

check_requirements

你也可以断言环境：

if [[ "$(hostname)" != "prod-app-1" ]]; then    echo "Warning: this does not look like the production server ($(hostname))."    # sleep 5 或者 exit；你自己选fi

数据库备份（可选但推荐）

对于小型系统，你可以在迁移之前快速做个数据库备份：

backup_database() {    local backup_dir="/var/backups/myapp"    mkdir -p "$backup_dir"    local filename="${backup_dir}/db-$(date '+%Y%m%d-%H%M%S').sql.gz"    log "Creating database backup at $filename..."    # MySQL 示例 - 调整凭据    mysqldump -u myuser -p'mypassword' mydatabase | gzip > "$filename"}

在迁移之前调用 backup_database。

（正式环境一般会用托管备份，这里只是展示思路。）

回滚策略（基础）

在非常简单的设置上（没有 releases 目录），回滚确实很棘手。这也是为什么很多团队会转向 releases + 符号链接的模式，我们接下来会详细讲。

现在只需要知道：最好的回滚策略是避免就地修改“当前”代码。相反，你把新代码部署到一个单独的目录，然后在一切通过健康检查后切换符号链接。

接下来就进入那个模式。

基于版本目录的零停机部署

要说业界最常用的部署模式，那一定是基于版本目录和符号链接的方式。它受 Capistrano、Envoyer、Deployer 等工具的启发，核心思路是：

在 releases/ 中保留多个应用版本

有一个 current 符号链接指向当前活跃的版本

部署时：

• 创建一个新的 releases/20251127-153000/ 目录
• 在那里安装代码 + 依赖
• 运行迁移、构建资源等
• 更新 current 指向新版本
• 可选保留几个旧版本用于回滚

目录结构：

/var/www/myapp/

├── releases/

│ ├── 2025-11-27-153000/

│ └── 2025-11-26-112030/

├── shared/

│ ├── .env

│ ├── storage/

│ └── uploads/

└── current -> releases/2025-11-27-153000/

Nginx 指向 /var/www/myapp/current/public。

使用 releases 的部署脚本

这是一个使用这种模式的更高级脚本：

#!/usr/bin/env bashset -euo pipefailAPP_NAME="myapp"BASE_DIR="/var/www/${APP_NAME}"RELEASES_DIR="${BASE_DIR}/releases"SHARED_DIR="${BASE_DIR}/shared"CURRENT_LINK="${BASE_DIR}/current"REPO_URL="git@github.com:yourname/your-app.git"PHP_FPM_SERVICE="php8.2-fpm"KEEP_RELEASES=5TIMESTAMP="$(date '+%Y-%m-%d-%H%M%S')"NEW_RELEASE_DIR="${RELEASES_DIR}/${TIMESTAMP}"log() {    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"}run_composer() {    COMPOSER_ALLOW_SUPERUSER=1 composer install \        --no-dev \        --prefer-dist \        --optimize-autoloader}link_shared() {    log "Linking shared files and directories..."    # 链接 .env    if [[ -f "${SHARED_DIR}/.env" ]]; then        ln -s "${SHARED_DIR}/.env" "${NEW_RELEASE_DIR}/.env"    fi    # 链接 storage（Lara vel 用）    if [[ -d "${SHARED_DIR}/storage" ]]; then        rm -rf "${NEW_RELEASE_DIR}/storage"        ln -s "${SHARED_DIR}/storage" "${NEW_RELEASE_DIR}/storage"    fi    # 链接 uploads 或其他共享资源    if [[ -d "${SHARED_DIR}/uploads" ]]; then        mkdir -p "${NEW_RELEASE_DIR}/public"        ln -s "${SHARED_DIR}/uploads" "${NEW_RELEASE_DIR}/public/uploads"    fi}run_lara vel_tasks() {    if [[ -f artisan ]]; then        log "Running Lara vel migrations..."        php artisan migrate --force        log "Optimizing Lara vel caches..."        php artisan config:clear        php artisan config:cache        php artisan route:cache || true        php artisan view:cache || true    fi}update_symlink() {    log "Updating current symlink to ${NEW_RELEASE_DIR}..."    ln -sfn "${NEW_RELEASE_DIR}" "${CURRENT_LINK}"}cleanup_old_releases() {    log "Cleaning up old releases, keeping last ${KEEP_RELEASES}..."    cd "${RELEASES_DIR}"    ls -1dt */ | tail -n +$((KEEP_RELEASES + 1)) | xargs -r rm -rf}deploy() {    log "Starting deployment to ${BASE_DIR}..."    mkdir -p "${RELEASES_DIR}" "${SHARED_DIR}"    log "Creating new release directory at ${NEW_RELEASE_DIR}..."    git clone --depth=1 "${REPO_URL}" "${NEW_RELEASE_DIR}"    cd "${NEW_RELEASE_DIR}"    log "Installing composer dependencies..."    run_composer    link_shared    run_lara vel_tasks    update_symlink    log "Reloading PHP-FPM..."    sudo systemctl reload "${PHP_FPM_SERVICE}"    cleanup_old_releases    log "Deployment finished successfully. New release: ${TIMESTAMP}"}deploy

这个脚本的工作流程：

• 把你的仓库克隆到一个带时间戳的文件夹
• 在那里安装依赖
• 从 shared/ 目录链接 .env、storage 和 uploads
• 运行迁移和缓存（Lara vel 用）
• 把 current 切换指向新版本
• 清理旧版本以免撑爆磁盘

要手动回滚，你可以：

1.列出版本：

ls -1 /var/www/myapp/releases

2.把 current 指向旧版本：

ln -sfn /var/www/myapp/releases/2025-11-26-112030 /var/www/myapp/currentsudo systemctl reload php8.2-fpm

你甚至可以把回滚脚本化（比如“回到上一个版本”），通过检查 releases/ 目录来实现。

多环境部署（staging 与 production）

一般来说，一个完整的项目流程至少会涉及两个环境：

• staging（或 test）
• production

你可以重用同一个脚本，但按环境参数化。

使用 ENV 参数

扩展变量：

ENVIRONMENT="${1:-production}"case "$ENVIRONMENT" in  production)    BASE_DIR="/var/www/myapp"    PHP_FPM_SERVICE="php8.2-fpm"    REPO_URL="git@github.com:yourname/your-app.git"    ;;  staging)    BASE_DIR="/var/www/myapp-staging"    PHP_FPM_SERVICE="php8.2-fpm"    REPO_URL="git@github.com:yourname/your-app.git"    ;;  *)    echo "Unknown environment: $ENVIRONMENT"    exit 1    ;;esac

然后调用：

./deploy.sh staging./deploy.sh production

在脚本内部，其他所有东西都用 $BASE_DIR、$REPO_URL 等。

为每个环境使用不同的 .env 文件

在 shared/ 里，你可以有：

/var/www/myapp/shared/

├── .env.production

└── .env.staging

然后在 link_shared() 里：

ENV_FILE="${SHARED_DIR}/.env.${ENVIRONMENT}"if [[ -f "${ENV_FILE}" ]]; then    ln -s "${ENV_FILE}" "${NEW_RELEASE_DIR}/.env"else    echo "Warning: env file ${ENV_FILE} not found."fi

这让环境配置保持干净和明确。

集成 PHP 生态工具

说起 shell 脚本，其实它更像一个调度中心，把各种你熟悉的工具按顺序安排起来：Composer、Artisan、cron、supervisord 等等。

优化 Composer

你可以通过添加一些标志，让 Composer 运行得更快、更可预测：

run_composer() {    COMPOSER_ALLOW_SUPERUSER=1 composer install \        --no-dev \        --prefer-dist \        --classmap-authoritative \        --no-interaction \        --no-progress}

处理队列和 worker

如果你使用队列（比如 Lara vel 队列 worker 或 Horizon），部署后你可能需要重启 worker。

用 supervisor 管理的 Lara vel 队列 worker 示例：

restart_workers() {    log "Restarting queue workers via supervisor..."    sudo supervisorctl reread    sudo supervisorctl update    sudo supervisorctl restart all}

或者就：

php artisan queue:restart

把这加到你的 run_lara vel_tasks() 或单独的步骤里。

Cron 任务

如果你依赖 cron 调用 php artisan schedule:run，不需要做特别的事——cron 会在下次运行时自动使用新的 current 符号链接。

只要确保你的 cron 条目指向 current 路径，而不是特定的版本：

* * * * * cd /var/www/myapp/current && php artisan schedule:run >> /dev/null 2>&1

接入 CI/CD 系统

脚本写好了，在服务器上能跑通，接下来就是接入 CI 了。这一步其实比想象中简单。

GitHub Actions 通过 SSH 部署

一个非常简化的工作流：

# .github/workflows/deploy.ymlname: Deploy to Productionon:  push:    branches:      - mainjobs:  deploy:    runs-on: ubuntu-latest    steps:      - name: Checkout        uses: actions/checkout@v4      - name: Add SSH key        uses: webfactory/ssh-agent@v0.9.0        with:          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}      - name: Deploy via SSH        run: |          ssh -o StrictHostKeyChecking=no deploy@your-server.com \            "cd /var/www/myapp && ./deploy.sh production"

CI 不需要知道你的部署逻辑；它只需要运行你的脚本。

GitLab CI

# .gitlab-ci.ymlstages:  - deploydeploy_production:  stage: deploy  only:    - main  script:    - ssh deploy@your-server.com "cd /var/www/myapp && ./deploy.sh production"

shell 脚本就是部署流程的唯一规范。

日志、通知与故障排查

如果一个部署脚本失败时没有任何反馈，那它和手动部署的可靠性其实没什么区别。

记录日志到文件

你可以用一个简单的日志机制包装你的脚本：

LOG_DIR="${BASE_DIR}/logs"LOG_FILE="${LOG_DIR}/deploy-$(date '+%Y-%m-%d').log"mkdir -p "$LOG_DIR"# 在最顶部（在其他所有东西之前）：exec > >(tee -a "$LOG_FILE") 2>&1

这会把 stdout 和 stderr 都重定向到日志文件（同时仍然打印到终端）。

现在每次运行都会被记录，包括错误信息。

Slack/Discord 通知

你可以用 curl 在部署成功或失败后发送一个简单的 webhook。

Slack webhook 调用示例：

notify_slack() {    local status="$1" # "success" 或 "failure"    local webhook_url="https://hooks.slack.com/services/XXX/YYY/ZZZ"    local emoji=":white_check_mark:"    if [[ "$status" == "failure" ]]; then        emoji=":x:"    fi    curl -X POST -H 'Content-type: application/json' \        --data "{            \"text\": \"${emoji} Deploy ${status} for ${APP_NAME} on $(hostname) at $(date '+%Y-%m-%d %H:%M:%S')\"        }" \        "$webhook_url" >/dev/null 2>&1 || true}

然后使用 Bash trap：

trap 'notify_slack failure' ERRtrap 'notify_slack success' EXIT

现在每当部署运行时你的团队都会收到消息。

（实际上你可能需要比“EXIT 时总是 success”更精细的控制，不过这里先这样。）

Shell 脚本的局限与进阶方向

当然，Shell 脚本虽然是很好的起点，但你也需要清楚它的局限性。

Shell 脚本的适用场景

• 单台或少量服务器
• 简单的部署拓扑（一个应用，一个数据库）
• 你的团队主要是后端开发和系统管理员
• 你想要快速、易懂的自动化，不需要额外工具

需要进阶的场景

• 很多服务器，复杂的环境
• 复杂的网络、负载均衡、蓝绿部署
• 基础设施即代码（Terraform、Ansible 等）
• Kubernetes 或容器编排

在那些场景里，shell 脚本仍然有用——但它们通常变成胶水代码，而不是主要的部署机制。

好消息是：你现在编码的部署逻辑（运行什么、按什么顺序、什么必须成功）即使你后来转向 Deployer、GitHub Actions 工作流、Ansible 或任何其他工具，也依然有价值。这些精力不会白费，你是在把部署流程文档化。

总结

最后，我们来整体回顾一下，这篇文章到底构建了什么：

1. 你学习了专门用于部署的 shell 脚本基础：

#!/usr/bin/env bash、set -euo pipefail、函数、参数

2. 你从一个简单脚本开始：

• git pull
• composer install
• 运行迁移和缓存任务
• 重载 PHP-FPM

3. 然后你把它演进成了一个更健壮的系统，使用：

• releases/ 目录和 current 符号链接
• 用于 .env、storage 和 uploads 的共享目录
• 自动清理旧版本

你让它具有环境感知，用单个脚本处理 staging 和 production。

你集成了 PHP 生态工具，如 Composer、Artisan、队列和 cron。

你把脚本接入了 CI，这样部署就变成了 push + 流水线，而不是“SSH 然后祈祷”。

你添加了日志和通知，这样部署就不是黑盒了。

4. 结果看起来很简单：

./deploy.sh production

但在这一条命令背后，是一套清晰的、受版本控制的流程，完整定义了你的 PHP 应用如何从 Git 到达线上服务器。

你不需要一次性采纳这篇文章里的每个想法。一个你可以遵循的进阶路径：

• 从一个小小的 deploy.sh 开始，只是把你当前的手动步骤包装起来
• 添加 set -euo pipefail 和一些基本的日志
• 向 releases/ + current/ 结构演进，以获得更安全的部署和回滚
• 按环境参数化
• 最后，把脚本接入 CI