如何部署Symfony程序


部署Symfony可能是一个复杂和多样的任务，取决于你的程序的设置和需求。本文并非手把手的指南，而是罗列了部署时的常见需求和建议。

Symfony部署基础 

发生在部署Symfony时的典型步骤包括：

  1. 把你的代码上传到产品服务器;
  2. 安装三方依赖 (通常透过Composer完成，并且可以在上传程序之前完成);
  3. 运行数据库迁移（migration）或类似任务，以更新“已改变的”数据结构;
  4. 清除 (可选地，预热[warming up]) 你的缓存。

部署过程还包括其他任务，诸如：

  • 对代码的某个特定版本打上标签，作为你的版本宝库中的一个发布;
  • 创建一个临时区域，以构建你的 "offline" 离线已更新设置;
  • 运行任意可用测试，以确保代码和/或服务器的稳定性;
  • 从 web/ 目录删除任何不必要的文件以保持生产环境干净;
  • 清除外部缓存系统 (像是 Memcached 或 Redis)。

如何部署Symfony程序 

部署Symfony程序时有几种方式。始于一些基本的部署策略，然后从那里开始。

基本文件传输 

部署一套程序最基本的方式是通过FTP/SCP（或类似方法）手动拷贝文件。其欠点是，比如在升级过程中，你缺少对系统的控制。这种方法也需要你在文传输之后执行一些手动步骤（参考 常见的后部署任务）。

使用版本控制 

如果你使用了版本控制（比如Git或SVN），你可以直接把现场安装（live installation）做成你repository的一个拷贝。当你已经准备好升级时，简单到如同从版本控制系统中取出最新的更新一样。

这令你的文件更新变得 更容易，但你仍然需要考虑手动执行其他步骤（参考 常见的后部署任务）。

使用平台服务 

鲜少使用有相关需求的用户，请参考Symfony官网原文。另，现代云平台，比如微软Azure，都可以一步支持Symfony3+。

不同的服务供应商之间，特殊的部署步骤十分多样化，因此从以下独立文章中查找你所选择的服务：

使用构建脚本和其他工具 

有几种工具可以帮助减轻部署时的痛苦。其中的一些几乎是为Symfony的需求而量身定制的：

  • Capistrano 配合 Symfony plugin
  • Capistrano 是一个Ruby写就的远程服务器的自动化和部署工具。Symfony plugin 是一个简化Symfony关联任务的插件，灵感来自 Capifony (它仅能和Capistrano 2一起工作)
  • sf2debpkg
  • 帮你为Symfony项目构建一个原生的Debian包。
  • Magallanes
  • 这个“类Capistrano”部署工具由PHP构建，对PHP开发者来说可以较容易地扩展其需求。
  • Fabric
  • 这个基于Python的类库提供了一个用来“执行本地或远程命令行以及上传下载文件”的基础套件。
  • Deployer
  • 这是又一个由原生PHP重写的Capistrano，有一些专门提供给Symfony的功能。
  • Bundles
  • 有一些 添加了部署功能的bundles 可以直接在你的Symfony控制台中使用。
  • 基础脚本
  • 你当然可以使用命令行， Ant 或其他任何构建工具，来脚本化部署你的项目。

常见的后部署任务 

在部署了你的真正源代码之后，有一些常见事项需要你来做：

A) 需求检查 

运行以下命令以检查服务器是否满足需求：

1
$  php bin/symfony_requirements

B) 配置app/config/parameters.yml文件 

此文件 不应　被部署，而是被Symfony提供的一个自动工具来管理。

C) 安装/更新vendors 

你的vendors（三方包儿）可以在上传源代码之前进行更新（比如更新 vendor/ 目录，然后再传源代码）或是到服务器上完成更新。不管哪种方式，只需像往常一样来更新vendors：vendor/ 目录，然后再传源代码）或是到服务器上完成更新。不管哪种方式，只需像往常一样来更新vendors：

1
$  composer install --no-dev --optimize-autoloader

通过构建一个 "class map" 类映射，--optimize-autoloader 旗标大幅改进了Composer的自动加载性能。--no-dev 旗标可确保开发环境的包不被安装到生产环境。

如果在这一步你得到 "class not found" 错误，你可能需要在执行前述命令之前先运行 export SYMFONY_ENV=prod 以便 post-install-cmd 脚本运行在 prod

1

$  php bin/console cache:clear --env=prod --no-debug

通过构建一个 "class map" 类映射，--optimize-autoloader 旗标大幅改进了Composer的自动加载性能。--no-dev 旗标可确保开发环境的包不被安装到生产环境。

如果在这一步你得到 "class not found" 错误，你可能需要在执行前述命令之前先运行 export SYMFONY_ENV=prod 以便 post-install-cmd 脚本运行在 prod 环境下。

D) 清除Symfony缓存 

确保清除（以及warm-up）了你的Symfony缓存。

1
$  php bin/console assetic:dump --env=prod --no-debug
E) 剥离Assetic资源 🎜¶🎜🎜🎜如果你使用了Assetic，你需要剥离出assets：🎜🎜🎜🎜🎜🎜🎜🎜rrreee🎜🎜🎜🎜rrreee🎜🎜🎜🎜🎜

F) 其他内容！ 

  • 运行数据库迁移
  • 清除APC缓存
  • 运行 assets:install (已经在 composer install 过程中被打点好了)
  • 添加/编辑 CRON 任务
  • 发布assets资源到CDN
  • ...

程序生命周期：持续整合，质量保证等 

虽然本文覆盖了部署过程的技术细节，但是代码从开发到生产时的完整生命周期可能需要更多步骤（考虑staging部署，QA[Quality Assurance/质量保证]，运行测试，等等）

staging、测试、QA、持续整合（continuous integration），数据库迁移以及失败时的向下兼容，统统被强烈建议。有各种简单或复杂的工具，其中的某一款会令你的部署在满足环境需求的过程变得容易（或老练）。

别忘了在部署过程中也牵扯到更新依赖（一般通过Composer），迁移数据库，清除缓存以及其他潜在事项，诸如将资源发布到CDN（参考 常见的后部署任务）。