Symfony2 lista implantação

Por padrão, o Composer gera um autoloader que não é totalmente otimizado. De fato, quando você possue muitas classes, o autoloader pode tomar um tempo considerável...

No ambiente de produção, você quer que o autoloader seja rápido. O Composer pode gerar um autoloader otimizado, que converte pacotes que utilizam a PSR-0 em um único mapeamento de classes, o que melhora o desempenho.

Para usar o autoloader otimizado, apenas adicione a opção --optimize para o comando dump-autoload do Composer:

php composer.phar dump-autoload --optimize

É claro, esta opção faz com que o comando demore um pouco mais. Por isso que ela não vem habilitada por padrão.

Se você usa as páginas de erro em seu ambiente de desenvolvimento, isto não é, felizmente, o que os seus visitantes devem ver em caso de erro no seu ambiente de produção. Então, você deve customizar diferentes páginas de erro, afim de integrar estes ao seu layout.

Felizmente, a customização das páginas de erro é realmente fácil. As "views" são localizadas dentro do componente TwigBundle, que lhe dá a possibilidade para substituí-los pelos seus. As páginas que você precisa criar são: Exception/errorXXX.html.twig, onde XXX é o número do erro ocorrido. É altamente recomendado personalizar ao menos as páginas para os erros 404 e 500.

Para usar as suas próprias páginas, existe duas possibilidades:

  1. Você pode criar um novo bundle(componente), que estenderá de TwigBundle, e colocar os seus arquivos em Resources/views/Exception/errorXXX.html.twig. Isso permite que você possa reutilizá-lo em diferentes projetos, pois é um componente reutilizável;
  2. Você também pode adicionar as suas páginas no diretório app/Resources/TwigBundle/views/Exception/errorXXX.html.twig. Se as suas páginas de erros são específicas para o seu projeto, isso evita que você crie um novo bundle apenas para isto.

Symfony2 Form Component automaticamente incorpora e valida CSRF tokens para você.

Esteja seguro que você personalizou a sua chave segura, ela é utilizada na geração do token seguro, está no arquivo app/config/parameters.yml:

secret:  por_favor_utilize_uma_chave_real_aqui

Além disso, você pode customizar o token formulário a formulário, o que é ainda melhor. Você pode fazer isso atráves da definição da opção intention em seus formulários:

namespace Acme\DemoBundle\Form;

use Symfony\Component\OptionsResolver\OptionsResolverInterface;

class TaskType extends AbstractType
{
    // ...

    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            // uma chave unica ajuda a gerar um token secreto
            'intention'  => 'task_form',
        ));
    }

    // ...
}

Antes de subir a sua aplicação, você deve verificar se seu servidor de produção está pronto para rodá-la.

Para testar o seu servidor você deve escolher uma opção entre os três métodos:

  1. Manualmente rode php app/check.php e veja o que deve ser resolvido;
  2. Acesse config.php com o seu navegador, localizado no diretório web;
  3. Se você não tem acesso ao seu servidor ainda (você pretende escolhe-lo), você pode acessar a página de referência

O componente para geração de logs da sua aplicação é essencial para gerenciar a sua plataforma web. Symfony2 possue o componente Monolog exclusivamente para essa tarefa.

A configuração padrão está preparada para o ambiente de desenvolvimento, o que não é suficiente para a produção. As mudanças serão realizadas com dois objetivos:

  • Enviar os erros para o administrador via e-mail(logs de nível "error")

  • Salvar todas as autenticações, como estes são logs de nível "info", eles não são salvos por padrão.

Vamos configurar o Monolog através do arquivo config_prod.yml:

monolog:
    handlers:
        main:
            type:               fingers_crossed
            action_level:       error
            handler:            grouped
        grouped:
            type:               group
            members:            [streamed, swift]
        streamed:
            type:               stream
            path:               "%kernel.logs_dir%/%kernel.environment%.log"
            level:              debug
        swift:
            type:               swift_mailer
            from_email:         FQN@foo.com
            to_email:           webmaster@company.com
            subject:            "OOps"
            level:              debug
        login:
            type:               stream
            path:               "%kernel.logs_dir%/auth.log"
            level:              info
            channels:           security

Isso é tudo!

Symfony2 é um framework flexível e poderoso... que, obviamente, acaba aumentando relativamente o tempo de execução. É claro que, o ambiente de produção é muito mais rápido que o seu ambiente de desenvolvimento de costume, mas isso não é o suficiente.

Com a intenção de aumentar a velocidade de sua aplicação em produção, é muito recomendado instalar um Acelerador para o PHP como o APC.

Em um servidor dedicado

Plataforma Linux

Para instalar o APC em uma distribuição linux baseada em debian, execute:

apt-get install php-apc

Adapte o comando para a sua distruição.

Plataforma Windows

Descomente a linha a baixo em seu php.ini:

extension=php_apc.dll

Em todos os casos

Depois da instalação, você deve habilitar o uso da extensão. Isto é feito adicionando a linha a baixo em seu php.ini:

[APC]
apc.enabled=1

Em um host compartilhado

Se você está em um host compartilhado, você pode não ter acesso SSH. Neste caso, a melhor opção é contatar o administrador da sua hospedagem. Diga para ele que é melhor para o seus servidores rodar com um Acelerador PHP.

Garanta que sua aplicação em produção esteja usando uma chave custimozada. Cheque isto no arquivo app/config/parameters.yml:

secret:  please_use_a_real_secret_here

Por padrão a "secret" não é verdadeiramente secreta, você precisa mudá-la por uma aleatória.

No ambiente de produção, é altamente recomendado utilizar o cache do Doctrine. Aqui estão dois tipos de cache.

Query e Metadata Cache

  • A Query Cache visa o cacheamento da transformação de DQL query para o SQL. Em produção, as suas requisições não irão mudar, então porque não fazer o cache.
  • A Metadata Cache permite o cacheamento das informações de metadata vindas de diferentes formatos como YAML, XML, Annotations, etc.

O cache dessas informações é feito definindo alguns paramêtros no arquivo de configuração config_prod.yml:

doctrine:
    orm:
        auto_mapping: true
        query_cache_driver:    apc
        metadata_cache_driver: apc

Result Cache

O resultado das suas queries podem ser armazenadas em cache para que a consulta não seja executada no banco de dados várias vezes. Como isso é um ajuste mais delicado, você não consegue apenas alterar um paramêtro em sua aplicação. Você apenas precisa setar o driver como anteriormente:

doctrine:
    orm:
        auto_mapping: true
        result_cache_driver: apc

Mas você precisa tornar explicito o uso ou não desse cache na maioria de suas queries. Isto é feito setando o nome e o tempo de vida de cada querie. Veja Doctrine Result Cache documentation.

Você não quer que o logo do Symfony apareça no navegador dos seus visitantes. É por isso que você deve substituir o favicon padrão pelo seu antes de subir a aplicação.

Apenas substitua o arquivo web/favicon.ico.

Para criar o seu favicon, você pode:

  • Usar ferramentas online para gerar os arquivos .ico. Exemplo: favicon.cc;
  • Usar um ícone PNG. Neste caso você precisa definir um link no seu HTML: <link rel="icon" type="image/png" href="suaImagem.png">