ChatView

PHP 项目部署方式

ChatGPT 原始来源 28 次浏览 公开 不过期
分享到 X 导出 JSON
作者选择不上传此对话中的文件，因此相关图片或文档未在此展示。
You
php web项目，当前线上代码更新用的还是FTP文件替换的方式更新代码，如果不上容器，有别的更好的方式吗？
ChatGPT

可以。不上容器，也比 FTP 覆盖文件强很多。推荐按成熟度分三档：

方案 1：Git 拉代码部署，最低改造

适合：小团队、单机 PHP 项目、暂时不想引入复杂 CI/CD。

流程

服务器上保留项目 Git 仓库：

Bash
cd /var/www/project
git fetch origin
git checkout main
git pull
composer install --no-dev--optimize-autoloader
php artisan migrate --force# Laravel 才需要
php artisan config:cache       # Laravel 才需要
sudo systemctl reload php-fpm


优点


    

  • 

    比 FTP 安全、可追踪
    

    • 

  • 

    能知道线上当前是什么 commit
    

    • 

  • 

    可以快速回滚：
    

    • 



Bash
git checkout <previous_commit>
composer install --no-dev--optimize-autoloader
sudo systemctl reload php-fpm


问题


    

  • 

    部署过程中可能出现“半更新”状态
    

    • 

  • 

    多台机器同步麻烦
    

    • 

  • 

    权限、缓存、依赖安装容易出问题
    

    • 



适合作为第一步替代 FTP，但不是最终形态。




方案 2：CI/CD 自动部署，推荐起点


适合：希望团队规范化，不想手动登录服务器。


可以用：


    

  • 

    GitHub Actions
    

    • 

  • 

    GitLab CI
    

    • 

  • 

    Jenkins
    

    • 

  • 

    Gitea Actions
    

    • 

  • 

    Coding / 阿里云云效 / 腾讯 CODING
    

    • 



基本逻辑


开发合并到 main 或打 tag 后自动执行：


    

  1. 

    拉代码
    

    2. 

  2. 

    安装依赖
    

    3. 

  3. 

    跑测试
    

    4. 

  4. 

    打包产物
    

    5. 

  5. 

    上传到服务器
    

    6. 

  6. 

    执行部署脚本
    

    7. 

  7. 

    reload PHP-FPM / Nginx
    

    8. 



例如用 GitHub Actions + SSH：


YAML
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_KEY }}
          script: |
            cd /var/www/project
            git pull origin main
            composer install --no-dev --optimize-autoloader
            sudo systemctl reload php-fpm


优点


    

  • 

    不再人工 FTP
    

    • 

  • 

    有部署日志
    

    • 

  • 

    权限可控
    

    • 

  • 

    可以加测试、审批、通知
    

    • 

  • 

    适合团队协作
    

    • 



问题


如果只是 git pull 覆盖线上目录，仍然存在短暂不一致风险。




方案 3：Release 目录 + 软链接切换，强烈推荐


这是不上容器时比较稳的 PHP 部署方式。


目录结构


Bash
/var/www/project/
  releases/
20260615120000/
20260615123000/
  shared/
    .env
    storage/
    uploads/
  current -> /var/www/project/releases/20260615123000


Nginx 指向：


Nginx
root /var/www/project/current/public;


部署流程


每次发布新建一个 release 目录：


Bash
RELEASE=/var/www/project/releases/$(date +%Y%m%d%H%M%S)

git clone git@github.com:xxx/project.git $RELEASE
cd$RELEASE

composer install --no-dev--optimize-autoloader

ln-s /var/www/project/shared/.env $RELEASE/.env
ln-s /var/www/project/shared/storage $RELEASE/storage

ln-sfn$RELEASE /var/www/project/current

sudo systemctl reload php-fpm


回滚


只需要把 current 指回上一个 release：


Bash
ln-sfn /var/www/project/releases/20260615120000 /var/www/project/current
sudo systemctl reload php-fpm


优点


    

  • 

    发布接近原子切换
    

    • 

  • 

    回滚很快
    

    • 

  • 

    不会出现 FTP 那种文件传一半线上就混乱的问题
    

    • 

  • 

    很适合 PHP-FPM + Nginx 架构
    

    • 



这个是我最推荐的非容器方案。




可以直接用的工具


如果不想自己写部署脚本，可以看这些：


工具适合场景
DeployerPHP 项目非常适合，支持 release、shared、rollback
CapistranoRuby 生态老牌部署工具，也可部署 PHP
Ansible多服务器、配置管理、发布流程统一
Jenkins/GitLab CI公司内部规范 CI/CD
GitHub Actions轻量、成本低、上手快


其中 Deployer 很适合 PHP：


Bash
composer require deployer/deployer --dev
vendor/bin/dep init
vendor/bin/dep deploy production


它天然支持：


    

  • 

    releases
    

    • 

  • 

    shared files
    

    • 

  • 

    symlink
    

    • 

  • 

    rollback
    

    • 

  • 

    composer install
    

    • 

  • 

    deploy hooks
    

    • 





我的建议


你们现在是 FTP 替换，建议按这个路线走：


第一阶段：马上替换 FTP


用：


Git + SSH 部署脚本


目标是先解决：


    

  • 

    文件不可追踪
    

    • 

  • 

    人工替换容易漏文件
    

    • 

  • 

    无部署日志
    

    • 

  • 

    回滚困难
    

    • 



第二阶段：标准化发布


升级成：


CI/CD + releases 目录 + current 软链接


这是不上容器时的主力方案。


第三阶段：补齐工程规范


增加：


    

  • 

    Git 分支策略：dev / staging / main
    

    • 

  • 

    测试环境自动部署
    

    • 

  • 

    线上发布需要 tag 或手动审批
    

    • 

  • 

    部署前自动备份
    

    • 

  • 

    数据库 migration 谨慎执行
    

    • 

  • 

    发布失败自动回滚
    

    • 

  • 

    发布通知到 Slack / 飞书 / 企业微信
    

    • 





注意几个坑


1. 不要把用户上传文件放在代码目录里


比如：


Bash
public/uploads
storage
runtime


这些应该放到 shared，然后软链接进 release。


否则每次发版可能覆盖或丢失用户文件。




2. .env 不进 Git


线上配置应该在服务器的 shared/.env。


代码发布时软链接进去。




3. Composer 不建议在线上临时慢慢装


更稳的方式是 CI 阶段装好依赖、打包上传。


如果项目不大，也可以先在线上执行：


Bash
composer install --no-dev--optimize-autoloader


但要注意 composer 版本、PHP 扩展、网络稳定性。




4. 数据库变更要单独谨慎处理


代码回滚容易，数据库回滚不一定容易。


建议：


    

  • 

    migration 向前兼容
    

    • 

  • 

    大字段变更提前做
    

    • 

  • 

    删除字段延后
    

    • 

  • 

    关键发布前备份数据库
    

    • 





结论


不上容器，最推荐：




GitLab CI / GitHub Actions + SSH + Deployer / Release 软链接部署




这是比 FTP 稳定很多、成本又不高的方案。


如果你们当前技术债不重，可以直接上 Deployer；如果团队想完全可控，就自己写 release 部署脚本。