Ubuntu PHP如何实现持续集成与持续部署

说到PHP项目的持续集成与持续部署，其实很多人第一反应会觉得这是大厂才玩的东西，或者觉得配置起来特别复杂。但说实话，一旦流程跑通，收益是立竿见影的——手动部署的错误率大幅下降，发布周期从几天压缩到几小时甚至几分钟。下面就以Ubuntu环境为例，把整个CI/CD落地的步骤拆开揉碎了讲清楚。

1. 打好基础：环境与工具准备

在开始配置CI/CD之前，有几样东西是必须装好的。首先是PHP本身，直接用包管理器安装就行，记得把常用扩展一并带上：

sudo apt install php php-cli php-mbstring php-gd php-xml

然后是Composer，PHP的依赖管理工具，没有它后面寸步难行：

curl -sS https://getcomposer.org/installer | php && sudo mv composer.phar /usr/local/bin/composer

版本控制方面，Git必须在项目中初始化好。另外，Nginx或Apache这类Web服务器也要提前配置妥当，比如把虚拟主机指向你的项目目录/var/www/myproject。这些基础工作做好，后面才能顺畅跑起来。

2. 选对工具：CI/CD平台怎么挑

市面上的CI/CD工具不少，但每个都有自己适合的场景：

• GitHub Actions：如果你的代码托管在GitHub上，这是最顺手的方案，内置大量现成的Action，配置起来相当省心。
• GitLab CI：GitLab原生集成，支持复杂管道，还有自动DevOps功能，适合偏重的项目。
• Jenkins：开源老将，灵活度最高，但需要自己手动搭环境，适合对管道定制有极致要求的团队。
• Tra vis CI：云托管服务，小项目用起来很方便，但只支持GitHub仓库，扩展性有限。

选哪个取决于你的团队习惯和项目复杂度，但从普及度来看，GitHub Actions和GitLab CI是目前的主流选择。

3. 具体配置：三种主流管道搭建方案

下面分别演示三种工具的配置方法，你可以根据自己的情况直接参考。

方案一：GitHub Actions（推荐给GitHub用户）

在项目根目录下创建.github/workflows/php-ci.yml文件，这个工作流会在每次推送代码到master分支时自动触发构建、测试和部署：

name: PHP CI/CD
on:
  push:
    branches: [ master ]
jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      # 拉取代码
      - uses: actions/checkout@v3
      # 配置PHP版本和扩展
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.0'
          extensions: mbstring, gd, curl
      # 安装依赖
      - run: composer install --no-interaction --prefer-dist --optimize-autoloader
      # 运行测试（需要配置PHPUnit）
      - run: vendor/bin/phpunit
      # 部署到服务器（通过SSH）
      - name: Deploy to Server
        run: scp -r . user@your-server-ip:/var/www/myproject
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

这里有几个关键点：shivammathur/setup-php是社区维护的Action，能帮你快速配置PHP环境和扩展；composer install建议加上--prefer-dist参数，能大幅提升构建速度；测试环节需要你提前准备好phpunit.xml配置文件；部署时用scp直接将代码推送到服务器，但SSH私钥要放在GitHub Secrets里，千万别硬编码在文件中。

方案二：Jenkins（适合高度定制化需求）

先在Ubuntu上安装Jenkins，然后用Jenkinsfile定义管道，同样放在项目根目录：

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                checkout scm
                sh 'composer install'
                sh 'php artisan key:generate'  // 如果用的是Lara vel
            }
        }
        stage('Test') {
            steps {
                sh 'vendor/bin/phpunit'
            }
        }
        stage('Deploy') {
            when { branch 'master' }
            steps {
                sh 'ssh deploy@your-server-ip "cd /var/www/myproject && git pull && composer install && systemctl restart nginx"'
            }
        }
    }
}

Jenkins的配置相对较重，但好处是管道逻辑完全由你掌控。部署阶段直接通过SSH远程执行命令，包括拉取代码、安装依赖和重启服务，一气呵成。

方案三：GitLab CI（GitLab仓库专用）

在项目根目录创建.gitlab-ci.yml文件，配置逻辑与Jenkins类似：

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - composer install
  artifacts:
    paths:
      - vendor/

test_job:
  stage: test
  script:
    - vendor/bin/phpunit

deploy_job:
  stage: deploy
  only:
    - master
  script:
    - ssh deploy@your-server-ip "cd /var/www/myproject && git pull && composer install && systemctl restart nginx"

GitLab CI的语法很简洁，但功能一点不弱。注意artifacts字段，它把vendor目录保存为构建产物，后续测试和部署阶段可以直接复用，省去重复安装依赖的时间。

4. 让管道跑得更稳的几条铁律

管道配好只是第一步，真正要让CI/CD发挥价值，下面几点值得特别留心：

• 测试必须自动化：用PHPUnit写好单元测试和集成测试，管道中只要测试失败就阻断部署。这是守住代码质量的第一道防线。
• 敏感信息绝不硬编码：数据库密码、SSH密钥这些统统放到CI/CD系统的环境变量或机密存储中。GitHub用Secrets，GitLab用CI/CD Variables，Jenkins也有Credentials管理。
• 管道配置纳入版本控制：无论是.github/workflows/、Jenkinsfile还是.gitlab-ci.yml，都和代码一起提交到Git仓库。这样做的好处是，任何配置变更都有历史可查，团队协作也更透明。
• 依赖管理要优化：composer install加上--prefer-dist --optimize-autoloader，前者优先使用压缩包加速下载，后者生成优化后的自动加载，部署效率能提升不少。
• 定期复盘管道日志：慢在哪一步？依赖冲突多不多？测试耗时是不是越来越长？这些都需要定期查看日志来发现瓶颈。

5. 部署完成之后呢？别忘了收尾工作

代码成功推送到服务器并不代表万事大吉，后续还有几个关键动作需要自动化处理：

• 重启服务：PHP-FPM和Nginx/Apache都得重启，新代码才能生效。命令很简单：systemctl restart php8.0-fpm和systemctl restart nginx。
• 清除缓存：比如Lara vel项目需要跑php artisan cache:clear，其他框架也有类似的命令，这一步不能省。
• 通知团队：通过Slack、邮件或钉钉发送部署结果通知，谁部署的、部署了什么、成功还是失败——这些信息对团队协作非常重要。大部分CI/CD工具都内置了通知集成，配置一下就好。

把这些步骤走完，一套完整的CI/CD管道就真正运转起来了。从代码提交到线上发布，全流程自动化，既减少了人为失误，也让团队能把精力集中在真正重要的事情上——写更好的代码，而不是重复地手动部署。