symfony开发_Symfony 2开发和部署清单

symfony开发

In my Building a Personal Web App Head To Toe With Symfony 2 series published on Sitepoint, I have covered some basics in bootstrapping, development and finalizing (on some advanced techniques) to use Symfony 2 to develop a web application. However, due to the length limitation of the series, we have not covered much on the “final” step: To deploy a Symfony 2 application to the production environment.

在Sitepoint上发布的《 构建使用Symfony 2的个人Web应用程序从头到脚》系列中，我介绍了使用Symfony 2开发Web应用程序的自举，开发和完成(一些高级技术)的一些基础知识。 但是，由于该系列的篇幅限制，我们在“最终”步骤上没有涉及太多内容：将Symfony 2应用程序部署到生产环境中。

When we do development, most likely we are in a “root” role; but in a production environment, we may be deprived of this privilege. Also, the settings may be different. To make things worse, sometimes we are not able to change these settings as we do in our own machines.

当我们进行开发时，最有可能我们处于“根本”角色。 但是在生产环境中，我们可能被剥夺了这种特权。 此外，设置可能会有所不同。 更糟的是，有时我们无法像在自己的计算机上一样更改这些设置。

Thus, it is of great importance to check the “compatibility” of our production server BEFORE any real development is done in our own server. This will avoid such horrible situations like: a library that Symfony depends on is missing, some global settings which the app relies on are unchangeable, etc.

因此，在我们自己的服务器上进行任何实际开发之前，检查生产服务器的“兼容性”非常重要。 这样可以避免出现以下可怕情况：缺少Symfony依赖的库，应用程序依赖的某些全局设置是不可更改的，等等。

Testing the “compatibility” of our production server should really be something we do at the very beginning. There are also some other aspects to be addressed during deployment – such as templates for various error messages, etc.

从一开始就应该测试生产服务器的“兼容性”。 在部署过程中还需要解决其他一些方面，例如各种错误消息的模板等。

In the following sections, we’ll be assuming you don’t have full control over your production server. If you do, most of the compatibility issues probably don’t apply, as you should be able to resolve them yourself quite easily.

在以下各节中，我们假定您对生产服务器没有完全控制。 如果这样做，大多数兼容性问题可能都不适用，因为您应该能够很轻松地自己解决它们。

生产服务器上的空Symfony框架 (An empty Symfony framework on the production server)

Please follow the instructions in my first article on Symfony 2 to set up an empty Symfony framework on the production server.

请按照我在Symfony 2上的第一篇文章中的说明在生产服务器上设置一个空的Symfony框架。

This is also useful to test if the server has cURL enabled, not only installed on the server but also as a PHP extension, making sure we can grab external resources. In my particular case, this is very important – composer.org is blocked in my country and I need to use a proxy to fetch and install the Symfony Framework.

这对于测试服务器是否启用了cURL(不仅在服务器上安装而且还作为PHP扩展启用)都非常有用，以确保我们可以获取外部资源。 在我的特定情况下，这非常重要– composer.org在我的国家/地区已被屏蔽，我需要使用代理来获取和安装Symfony框架。

This empty framework can later be checked into version control.

以后可以将此空框架检入版本控制。

配置文件 (The config file)

Symfony 2 comes with a config.php file which resides in the web directory. This is the script to test most of the “readiness” issue. To visit that page, we need to tweak it a bit:

Symfony 2带有一个config.php文件，该文件位于web目录中。 这是测试大多数“就绪”问题的脚本。 要访问该页面，我们需要对其进行一些调整：

<?php

if (!isset($_SERVER['HTTP_HOST'])) {
    exit('This script cannot be run from the CLI. Run it from a browser.');
}

if (!in_array(@$_SERVER['REMOTE_ADDR'], array(
    '127.0.0.1',
    '::1',
))) {
    header('HTTP/1.0 403 Forbidden');
    exit('This script is only accessible from localhost.');
}
...

This file is meant to be called from a local browser only. We need to comment out the second if block so that we can visit it remotely.

该文件只能从本地浏览器调用。 我们需要注释掉第二个if块，以便我们可以远程访问它。

My server is configured correctly and does not have any critical issues:

我的服务器配置正确，没有任何严重问题：

This file tests the readiness issues which I summarize in the table below. The actual testing is done in app/SymfonyRequirements.php so we can also take a look at that file.

该文件测试了准备情况，我在下表中对此进行了总结。 实际测试是在app/SymfonyRequirements.php完成的，因此我们也可以查看该文件。

Settings/Modules	Requirement	Seriousness	Actions
PHP version	= 5.3.3	Required but must NOT be 5.3.16	Upgrade to latest version. Suggest to use at least PHP 5.4.8 and above.
Vendor libraries	Installed by composer.phar	Required	Update using composer.phar
cache, logs directory	Writable	Required	By issuing chmod to grant permissions. Normally, the privilege should be 755 or 777.
Timezone	Something like 'Asia/Shanghai' or your timezone	Required	Change php.ini.
json_encode, session_start, ctype_alpha, token_get_all, simplexml_import_dom	Enabled	Required	Enable respective PHP libraries. Most PHP servers have these enabled.
APC	Enabled/Disabled	Enabled if APC is used	Enable APC or disable APC if you are using another cache/accelerator.
xdebug	Various settings	Required, Recommended	Change xdebug settings accordingly.
DomDocument, mb_strlen, icony, utf8_decode, intl, etc	Various modules	Recommended	Enable if you wish.
Accelerators	Various settings	Recommended	Install and enable per your request.
<? short open tag, magic_quotes_gpc, register_globals, session.auto_start	Disabled	Recommended	Suggest to follow the suggestions. PHP latest versions have some of them disabled by default.
PDO	Database driver	Recommended	Please do install and enable it. It is mandatory if you are using Doctrine ORM.

设置/模块	需求	严肃	动作
PHP版本	= 5.3.3	必需，但不得为5.3.16	升级到最新版本。 建议至少使用PHP 5.4.8及更高版本。
供应商库	由composer.phar安装	需要	使用composer.phar更新
cache ， logs目录	可写的	需要	通过发出chmod授予权限。 通常，特权应为755或777 。
时区	像'Asia/Shanghai'或您所在的时区	需要	更改php.ini 。
json_encode ， session_start ， ctype_alpha ， token_get_all ， simplexml_import_dom	已启用	需要	启用相应PHP库。 大多数PHP服务器都启用了这些功能。
装甲运兵车	启用/禁用	如果使用APC，则启用	启用APC或禁用APC(如果您使用其他缓存/加速器)。
调试器	各种设定	必需，推荐	相应地更改xdebug设置。
DomDocument ， mb_strlen ， icony ， utf8_decode ， intl等	各种模块	推荐的	如果需要，启用。
促进剂	各种设定	推荐的	根据您的要求安装并启用。
<? 短打开标记magic_quotes_gpc ， register_globals ， session.auto_start	残障人士	推荐的	建议遵循建议。 PHP最新版本默认禁用了其中一些功能。
PDO	数据库驱动	推荐的	请安装并启用它。 如果您正在使用Doctrine ORM，则这是强制性的。

A seriousness level of “Required” means we have to change our server settings to meet the requirement. Otherwise, Symfony 2 won’t be running and thus should not be the right choice for our application development. A “Recommended” item can be safely ignored but I do suggest we fulfill those recommendations as much as we can. In my case (shown above), my production server only has one warning. That establishes a solid and reliable ground for further development.

严重性级别为“ 必需 ”表示我们必须更改服务器设置以满足要求。 否则，Symfony 2将无法运行，因此不是我们应用程序开发的正确选择。 可以安全地忽略“ 推荐 ”项目，但我建议我们尽我们所能实现这些建议。 就我而言(如上所示)，我的生产服务器只有一个警告。 这为进一步发展奠定了坚实而可靠的基础。

使用git同步文件 (Using git to sync files)

During development, you may, instead of copying the files to the production server, want to use version control to sync local changes to the remote site.

在开发过程中，您可能不想使用版本控制将本地更改同步到远程站点，而不是将文件复制到生产服务器。

In that case, a proper .gitignore (or equivalent in other version control systems) will become handy. The below excerpt from my .gitignore file is for reference:

在这种情况下，适当的.gitignore (或其他版本控制系统中的等效文件)将变得很方便。 我的.gitignore文件的以下摘录仅供参考：

# Composer
vendor
vendor/*
!public/assets/js/vendor
!public/assets/js/vendor/*
!public/assets/css/vendor
!public/assets/css/vendor/*
composer.phar
composer.lock

# Symfony
app/cache/*
app/logs/*

# Logs
error.log
access.log

# Netbeans
nbproject
.nbproject
.nbproject/*
nbproject/*
nbproject/private/
build/
nbbuild/
dist/
nbdist/
nbactions.xml
nb-configuration.xml

This is never an exhaustive or fit-all-purposes list. For example, if you use PhpStorm but not Netbeans, you can delete the Netbeans section and replace with filters fit for PhpStorm:

这绝不是详尽无遗的清单。 例如，如果您使用PhpStorm而不是Netbeans，则可以删除Netbeans部分并替换为适合PhpStorm的过滤器：

# IntelliJ - PhpStorm and PyCharm
.idea
.idea/
.idea/*
*.iml
*.ipr
*.iws

Or just leave them both in, so you automatically accommodate other devs who may be using other IDEs. It is recommended to always include the first 3 sections (Composer, Symfony, Logs).

或者只是将它们都留在里面，这样您就可以自动容纳可能使用其他IDE的其他开发人员。 建议始终包括前3个部分( Composer ， Symfony ， Logs )。

清除缓存 (Clearing cache)

The first time a Symfony app runs on a remote server, it will create a compiled version of our app in the app/cache/prod directory. When our files, especially our controllers and routes, are updated, we need to refresh the cache, or the output may be incorrect and often causes 500 errors.

Symfony应用程序首次在远程服务器上运行时，它将在app/cache/prod目录中创建我们应用程序的编译版本。 当我们的文件(尤其是我们的控制器和路由)被更新时，我们需要刷新缓存，否则输出可能不正确，并经常导致500错误。

To clear the cache, I will normally SSH to my production server and do a rm -rf cache command under app directory. The console cache:clear or console cache:warmup command may not be the cleanest way to do so.

要清除缓存，我通常将SSH到生产服务器，并在app目录下执行rm -rf cache命令。 console cache:clear或console cache:warmup命令可能不是最干净的方法。

远程开发模式 (Remote dev mode)

Use this with caution and only when absolutely necessary!

请仅在绝对必要时谨慎使用此功能！

In some cases, a local functioning site may just crash when it is deployed to the production server. The reasons causing this may be complex and not related to the coding process itself. In these circumstances, we can consider enabling the remote dev mode.

在某些情况下，本地正常运行的站点在部署到生产服务器时可能会崩溃。 造成这种情况的原因可能很复杂，并且与编码过程本身无关。 在这种情况下，我们可以考虑启用远程dev模式。

To do this, we take the similar approach to disable the localhost check by commenting the below code block in app_dev.php:

为此，我们采用类似的方法通过在app_dev.php注释以下代码块来禁用localhost检查：

// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
    || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    || !in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1'))
) {
    header('HTTP/1.0 403 Forbidden');
    exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

We can then visit the domain and pages with something like: http://rsywx_remote/app_dev.php. When something goes wrong, this dev mode displays more useful debug information and can help us a lot to find some deep rooted issues. For added security during this debug period, add a check that only allows visits from your own IP to the above file – this will keep the dev mode off for everyone else. Most of the issues will be related to database setup (wrong database and/or credentials), wrong API URIs (local and remote URIs may be different), outdated cache, missing libraries used locally but not enabled remotely, etc.

然后，我们可以使用以下内容访问域和页面： http://rsywx_remote/app_dev.php 。 当出现问题时，此dev模式会显示更多有用的调试信息，并可以帮助我们找到一些根深蒂固的问题。 为了在此调试期间提高安全性，请添加一项检查，该检查仅允许您使用自己的IP访问上述文件-这将使开发模式对其他所有人保持关闭状态。 大多数问题将与数据库设置(错误的数据库和/或凭据)，错误的API URI(本地和远程URI可能不同)，缓存过期，缺少本地使用但未远程启用的库等相关。

When the problems have been fixed, please do remember to un-comment those lines to restore full access control. Regular users shall only be allowed to use app.php as our app’s entry point.

解决问题后，请切记取消注释这些行以恢复完整的访问控制。 普通用户只能使用app.php作为我们应用程序的切入点。

自定义错误页面 (Customize the error pages)

Symfony 2’s default Twig template engine does provide some error pages (404, 500, etc). But the design of these pages will usually not fit our application. The official site has the detailed explanation on how to do this. We can develop our own error pages based on our own layout and theme.

Symfony 2的默认Twig模板引擎确实提供了一些错误页面(404、500等)。 但是这些页面的设计通常不适合我们的应用程序。 官方站点上有关于如何执行此操作的详细说明 。 我们可以根据自己的布局和主题来开发自己的错误页面。

We can customize the error pages and put them under app/Resources/TwigBundle/views/Exception. The files can be named error404.html.twig for 404 errors, error403.html.twig for 403 errors, etc, or just error.html.twig for general purposes.

我们可以自定义错误页面，并将其放在app/Resources/TwigBundle/views/Exception 。 这些文件可以被命名error404.html.twig 404错误， error403.html.twig为403错误等，或者只是error.html.twig一般用途。

It’s important to note that in Symfony 2, error message pages do not support the Twig template extension. This means we cannot have an error page extended from a existing layout designed for other pages. We have to design the error pages from scratch. This is a bit inconvenient but still worth doing for a serious site.

需要特别注意的是，在Symfony 2中，错误消息页面不支持Twig模板扩展。 这意味着我们不能从为其他页面设计的现有布局扩展错误页面。 我们必须从头开始设计错误页面。 这有点不方便，但是对于一个严肃的网站还是值得的。

结论 (Conclusion)

In this article, we have covered some Symfony deployment related topics: the server readiness, version control, remote dev mode, cache update, error pages customization, etc.

在本文中，我们讨论了一些与Symfony部署相关的主题：服务器就绪，版本控制，远程dev模式，缓存更新，错误页面自定义等。

Deployment is usually the final step in our development. I do hope this article helped you avoid some common pitfals and made your deployment process more smooth.

部署通常是我们开发的最后一步。 我确实希望本文能帮助您避免一些常见的麻烦，并使您的部署过程更加顺利。

Please reshare this article if you’ve found it interesting or useful, and leave a comment below if you have feedback, it’s much appreciated!

如果您发现本文有趣或有用，请转发此文章，如果您有反馈，请在下面发表评论，不胜感激！

翻译自: https://www.sitepoint.com/symfony-2-checklist-development-deployment/

symfony开发