1. 环境准备
1.1 选择云主机与操作系统
在开始部署前需要明确目标负载与预算，选择合适的云服务商与实例规格，以满足并发与内存需求。常见的组合是 Ubuntu 22.04 LTS 作为系统镜像，原因在于长期维护、丰富的软件源和稳定的安全更新。
同时要建立基本的安全基线，包括 最小化安装组件、禁用不必要的服务以及在首次启动后进行系统升级，这些都直接影响上线后的稳定性与安全性。
1.2 网络与域名配置
上线前应确保域名解析指向目标服务器，并在服务器层配置好 防火墙与入站策略，只暴露必要端口（如 80/443、22、443）。
TLS 是上线的核心要素，建议使用 自动续期的 TLS 证书，如 Let’s Encrypt 配合 CertBot，降低人工运维成本与风险。
1.3 PHP 运行环境与依赖
为 PHP 应用选择合适的 PHP 版本，并安装常用扩展以确保功能完整性与性能。常见组合是 PHP 8.1/8.2 配合 FPM 模式运行。
# 安装 PHP 8.1 及常用扩展
sudo apt-get update
sudo apt-get install -y php8.1-fpm php8.1-mysql php8.1-xml php8.1-mbstring php8.1-zip php8.1-curl php8.1-json php8.1-opcache同时保障 PHP-FPM 与 Web 服务器之间的通信通畅，开启 OpCache 提升执行效率，并确保扩展版本与内核兼容。
2. 代码管理与分支策略
2.1 版本控制与分支模型
把代码托管在 Git 仓库中，是实现可追溯部署的前提。应采用清晰的 分支策略，如主干（trunk）发布、功能分支或半年滚动版本；确保上线流程可重复、可回滚。
在协作中应使用 标签或版本号 对应不同环境，如 v1.2.x 代表生产就绪版本，便于回溯与回滚。
2.2 标签与环境对应的配置
为不同环境维护独立的配置，避免把开发环境的密钥或数据库信息带入生产。通常通过 环境变量或环境配置文件 的形式管理敏感信息。
git checkout -b release/1.2.0
git push origin release/1.2.0在 CI/CD 流程中通过 环境分离的配置文件，确保生产镜像只包含生产环境所需信息。
3. 构建与依赖管理
3.1 依赖安装
上线前需要对后端依赖进行打包与去除开发依赖，确保产线镜像尽量小且安全。应执行 Composer 安装并跳过开发依赖，搭配自动加载优化。
# 生产环境依赖安装
composer install --no-dev --optimize-autoloader如果项目包含前端资源，前端依赖也要在构建阶段处理，确保产物可直接部署到服务器。
3.2 构建前端资源
前端资源的打包通常在部署阶段完成，确保 Node.js & npm/yarn 的版本与后端兼容，并执行前端构建以获得优化后的静态资源。
# 构建前端资源（示例）
npm ci
npm run build
构建产物应被存放在一个稳定的目录，便于后续的持续部署工具读取并同步到目标服务器。
4. 数据库与迁移
4.1 数据库准备
上线前需要评估数据库结构变更、数据备份与迁移策略。应在生产前确保 数据库用户权限最小化，并建立备份计划。
部署过程中可执行迁移脚本或应用自带迁移工具，确保 数据模型与应用代码版本一致，迁移过程可控且可回滚。
# 示例：执行数据库迁移（通用方式）
php migrations/run.php --env=production
上线前应进行一次 热备份与一致性校验，确保迁移完成后数据完整可用。
5. 配置与安全
5.1 配置文件管理
配置与源码分离，推荐使用 环境变量或配置中心，避免把敏感信息直接写入代码库。
# 使用环境变量管理敏感信息
export APP_ENV=production
export DB_PASSWORD=secure_password上线前应对配置进行一次完整审计，确保 证书、密钥、数据库连接串等信息都在受控范围内。
5.2 安全性与访问控制
生产环境的安全要点包括 最小权限的数据库账户、强密码、密钥管理、以及对外暴露面板的严格访问控制。
还应启用 Web 应用防火墙(WAF)、HTTPS 强制跳转、以及服务器端的速率限制以防止滥用。
6. 自动化测试与质量保障
6.1 单元测试与静态分析
持续集成阶段应包含单元测试与静态分析，以确保代码质量与回归保护。重点关注 代码覆盖率、静态分析结果 以及对变更的回归影响。
# 运行单元测试
vendor/bin/phpunit# 静态代码分析
vendor/bin/phpstan analyse src --level=max将测试与分析结果纳入 发布门槛，确保进入生产的版本具备基本质量保障。
6.2 漏洞检测
在发布前进行依赖漏洞检测，通常通过 Composer 安全审计 与前端依赖的漏洞识别实现。
# Composer 漏洞检测
composer audit通过持续的 漏洞监控与修复，降低上线后受到已知问题影响的风险。
7. 服务器部署与服务编排
7.1 Nginx/Apache 配置
生产环境的 Web 服务应具备高效、稳健的反向代理能力。典型工作流是 Nginx + PHP-FPM，通过反向代理将 PHP 请求转发到后端处理。
server {listen 80;server_name example.com;return 301 https://$host$request_uri;
}
server {listen 443 ssl;server_name example.com;root /var/www/app/public;index index.php;ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;location / {try_files $uri $uri/ /index.php?$query_string;}location ~ \\.php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;}
}
域名解析、证书配置与站点重定向应保持一致性，确保用户体验与性能。
7.2 PHP-FPM 池配置
为并发量设定合理的 PHP-FPM 池参数，确保 进程数与内存使用 在服务器容量范围内，避免 OOM 或高延迟。
; /etc/php/8.1/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 60
pm.start_servers = 6
pm.min_spare_servers = 6
pm.max_spare_servers = 12
通过监控实际请求和资源使用，动态调整参数以保持稳定性。
7.3 证书与加密
TLS 证书应尽量实现自动续期，确保 HTTPS 永久生效。CertBot 与 Nginx 的集成是常见方案。
# 通过 CertBot 获取并自动配置证书
sudo certbot --nginx -d example.com --non-interactive --agree-txt证书续期失败时需有备用通知与手动干预流程，确保服务仍可访问。
8. 持续集成与持续部署
8.1 CI/CD 流程设计
应将构建、测试、打包、部署等步骤以流水线形式实现，保证从代码提交到上线的全自动化，降低人为错误。
常见的流水线阶段包括：获取代码、安装依赖、运行测试、构建产物、执行部署脚本、回报状态。
8.2 部署脚本示例
示例部署脚本可通过远程执行或镜像推送实现，确保 上线过程可重复且可回滚。
name: Deploy PHP App
on:push:branches: [ main ]
jobs:deploy:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v3- name: Set up PHPuses: shivammathur/setup-php@v2with:php-version: '8.1'- name: Install Dependenciesrun: composer install --no-dev --prefer-dist- name: Deployrun: |rsync -avz --delete-after ./ user@server:/var/www/app
通过 自动化部署脚本，将应用从构建到生产的一致性完全交给系统执行。
9. 上线前的切换策略与灰度
9.1 蓝绿/灰度发布
上线时可使用 蓝绿发布或灰度发布，以最小化风险并实现逐步切换。通过路由策略将部分流量导向新版本，监控关键指标后再全面切换。
灰度阶段应设定明确的 回退条件，如错误率、响应时间、日志告警等达到阈值即触发回滚。
9.2 回滚方案
一旦新版本出现问题，需具备快速 回滚到上一个稳定版本 的能力。回滚流程应包含数据库回滚、服务重启与缓存清理等步骤。
生产环境中应保留 历史部署记录，方便在任意时间点回滚并重建状态。
10. 日志、监控与运维
10.1 日志收集
应集中化收集 Web 与应用日志，确保 可检索与告警，并建立轮替与保留策略。
常见做法是将日志集中到 ELK/EFK、Prometheus 等系统，以便进行时序分析与异常检测。
# 典型的 logrotate 配置
/var/log/nginx/*.log {dailymissingokrotate 14compressdelaycompressnotifemptycreate 0640 www-data adm
}
10.2 指标与告警
对关键指标设定阈值并接入告警渠道，例如 错误率、P95/P99 延迟、QPS、CPU 内存占用等，确保问题能在第一时间被发现。
推荐在分布式部署中对各节点进行独立监控，避免单点故障对全局可用性造成影响。
11. 常见问题排查
11.1 常见 Web 5xx 与超时问题
排查顺序通常包括 应用日志、Web 服务器日志、数据库连接，以及后端服务健康检查的结果。
关注点包括：队列阻塞、慢查询、内存不足等，逐步缩小范围以定位根因。
11.2 数据库连接与迁移失败
数据库连接失败常见原因为 网络策略变更、账号权限、密码错误，应先验证网络连通性与凭据。
迁移失败可能与版本不兼容、字段冲突相关，应对迁移脚本进行 幂等性设计与回滚能力，确保能在重复执行时保持一致性。
11.3 依赖与构建相关问题
依赖更新后可能引入兼容性问题，应保持 锁定版本、逐步升级，并在 CI 阶段进行回归测试。
构建阶段若遇网络或资源不足，应具备 缓存与并行构建策略，以减少失败概率。
