如何部署Symfony程序

3.4 版本
维护中的版本

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

Symfony部署基础 

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

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

部署过程还包括其他任务,诸如:

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

如何部署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:

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 环境下。

D) 清除Symfony缓存 

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

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

E) 剥离Assetic资源 

如果你使用了Assetic,你需要剥离出assets:

1
$  php bin/console assetic:dump --env=prod --no-debug

F) 其他内容! 

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

程序生命周期:持续整合,质量保证等 

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

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

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

本文,包括例程代码在内,采用的是 Creative Commons BY-SA 3.0 创作共用授权。

登录symfonychina 发表评论或留下问题(我们会尽量回复)