这本按部就班的教程描述了如何在 Heroku 云平台上部署一个 Symfony 网页应用程序。其内容基于在 Heroku 上出版的原创文章。设置创建一个新的 Heroku 网站，首先用 Heroku 注册或者用您自己的证书注册。然后在您的本地计算机上下载并安装 Heroku Toolbelt。您也可以查看在 Heroku 上开始使用 PHP 的指导来获取更多的对于在 Heroku 上使用 PHP 应用程序的细节的熟悉度。
这个按部就班的教程描述了如何在 Microsoft Azure 云平台上部署一个小型的 Symfony 网页应用。它将会解释如何设置一个新的 Azure 网页，包括设置正确的 PHP 版本和全局环境变量。文件还展示了您如何可以利用 Git 和 Composer 在云上部署您的 Symfony 应用。建立 Azure 网站建立一个新的 Microsoft Azure 网站，首先注册 Azure 或者用证书注册。
部署的过程是一个复杂且多样的任务，它依靠于您应用的设置及需求的任务。本文不是按部就班的指导，而是一个关于部署大部分的需求和想法的大概的列表。Symfony 部署基础在部署一个 Symfony 应用时采取的典型步骤包括：加载您的代码到成品服务器；安装您的供应商依赖（基本上通过 Composer 完成也可能是在加载前就完成）；
当您在本地机器上运行一个 Symfony 工程时，您应该使用 dev 环境（app dev .php 前端控制器）。优化此配置主要有两个目的：在任何时候有不当情况发生（网页调试工具栏，nice 异常页面，分析器…）时，给开发者正确的反馈；尽可能与生产环境相似来避免在部署项目过程中的问题。
代替你自己处理文件上传，你可以考虑使用 VichUploaderBundle bundle。这个 bundle 提供所有的一般选项（例如文件重命名，保存和删除）并且整合了 Doctrine ORM, MongoDB ODM, PHPCR ODM 和 Propel。 试想在你的应用程序中有一个 Product 实体并且你想为你的每一个产品添加一个 PDF 格式的小册子。
在本书中，你已经学习了当扩展基本的 Controller 类时如何轻松使用 controller 了。除此之外，controllers 也可以被指定为服务。 将 controller 指定为服务将会花费一番功夫。最基本的优点就是整个 controller 或其它传递到 controller 的服务可以通过服务容器配置修正。当开发开放的 bundle 或者在不同的工程中使用 bundle 时将会很有用。
在 Symfony 应用程序中，所有的错误都会被认为是异常，不论只是一个 404 Not Found 错误还是你的代码中的一些异常引起的重大错误。 在开发环境中，Symfony 缓存所有的异常并且通过一个拥有很多调试信息的异常页来帮助你发现问题的根源： 由于这个页面包含了很多敏感的内部信息，Symfony 不会将其在产品环境中展示。
默认情况下，Symfony 将会在每一个 bundle 的 Command 目录下进行检查并且自动登录你的命令。如果一个命令扩展 ContainerAwareCommand，Symfony 将会甚至注入这个容器。然而为了使得这个更容易，它有一些限制： 你的命令必须在 Command 目录下；基于你的环境或者依赖性的可用性没有注册你的服务的条件；
控制台组件没有提供任何的立即可用的日志能力。正常来讲，你可以手动运行控制台命令观察输出结果，这就是为什么不提供日志的原因。然而，有些时候你就需要日志。举例来说，如果你是自动运行控制台命令，例如从工作或者开发脚本，很容易使用 Symfony 的日志能力而不是配置其它工具去收集控制台的输出并且编辑它。
不幸的是，命令行环境不知道你的虚拟主机或者域的名称。这就意味着如果你使用控制台命令生成了绝对的 URL 你将可能像 http://localhost/foo/bar 一样结束而并没有什么用。 为了解决这个问题，你需要配置“请求环境”，这是一种受欢迎的说明方式也就是你需要设置你的环境使得它知道当生成 URL 的时候该用哪一个。
控制台组件文档讲解了如何创建控制台命令。本指导文章将会讲解如何直接从 Controller 调用一个控制台命令。 你可能有执行只有在控制台命令中可用的某些功能的需要。通常情况下，你应该重构命令然后向服务中移动一些能够在 controller 中应用的逻辑。然而，当命令是第三方函数库的一部分时，你就会不想修正或者复制它们的代码。作为替代你可以直接执行命令。
组件文档的使用控制台命令，快捷键和内建命令页全局的看控制台选项。当你使用控制台作为全栈框架的一部分时，一些附加的全局选项也是可用的。 默认情况下，控制台命令在 dev 环境中运行，你可能要对某些命令改变这种情况。举例来说，你可能由于性能的原因想要在 prod 环境下运行一些命令。除此之外，一些命令的结果可能会由于环境的不同而不同。
组件一节（The Console Component）的控制台页介绍了如何创建控制台命令。这个指导文章介绍了在 Symfony 框架下创建控制台命令的不同之处。 自动注册命令为了使得控制台命令在 Symfony 下自动可用，在你的 bundle 中创建一个 Command 目录并且以 Command.php 为后缀创建你想要的命令。举例来说，如果你想要扩展 AppBundle 来在命令行运行，那么创建 GreetCommand.
Symfony 的标准版本默认定义了三种运行环境名为 dev, prod 和 test。环境简单的代表了用不同的配置执行相同的基础代码的方式。 为了选择每个环境需要加载的配置文件，Symfony 执行 AppKernel 类的 registerContainerConfiguration() 方法： // app/AppKernel.phpuse Symfony\Component\HttpKernel\Kernel;use Symfony\Component\Config\Loader\LoaderInterface;
最好的开发你的 Symfony 应用程序的方法就是使用 PHP 的内部网页服务器。然而，当使用老版本的 PHP 时或者当在开发环境运行应用程序时，你就会需要一个全功能的网页服务器。这篇文章介绍了在 Symfony 中使用 Apache 或者 Nginx 的一些方法。 当使用 Apache 时。你可以将 PHP 设置成 Apache module 或者使用 PHP FPM FastCGI。FastCGI 也是用 Nginx 使用 PHP 的最好的方法。
使用 Apache Router 不再是一个明智之举。应用程序的路由选择的小小的增加不至于大费周章地升级路由配置。 Apache Router 将会在 Symfony 3 中移除，我们强烈建议不要在你的应用程序中应用它。 Symfony 也快速的提供了各种各样的方法来通过一些微小的调整增加速度。其中的一种方法就是让 Apache 直接处理路由，而不是由 Symfony 直接处理。
在 Symfony 2.6 中有一个后向兼容：数据库模式稍作改变。更多细节请见 Symfony 2.6 的改变。 默认的 Symfony 的 session 存储将 session 信息写进文件。大多数的中到大型的网页使用一个数据库储存 session 的值而不是文件，因为数据库很好用并且适应多线程网页服务器环境。 Symfony 有一个内建的数据库 session 的存储解决方案名为 PdoSessionHandler。
在如何掌握并创建新的环境一章中，你学会了如何管理你的应用程序的配置。有些时候，在你的工程代码之外储存证书会对你的应用程序有好处。数据库配置就是这样一个例子。Symfony 的服务容器的灵活性使得你很容易这么做。 环境变量Symfony 将会抓取以 SYMFONY__ 作为前缀的变量并且将其设置成为服务容器中的参数。结果的参数名称都应用了一些转换： SYMFONY__ 前缀被移除；
在如何掌握并创建新的环境这一节中我们解释了 Symfony 如何在不同的配置之下使用环境来运行的应用程序的基本思想。这一节我们将会更加深入地介绍当你的应用程序自我启动时会发生什么。
你已经在 Symfony 服务容器中看到如何使用配置参数了。举例来说，存在特殊的情形比如当你想使用 %kernel.debug% 参数使得你的 bundle 中的服务进入调试模式。对于这种情况来说为了使系统理解参数的值你需要做很多工作。默认情况下你的 %kernel.debug% 参数将会被认为是简单的字符串。看看下面这个例子： // inside Configuration class$rootNode ->
关注时代Java
