A configuração de ambiente é um tópico que mudou consideravelmente entre as versões 4.2, 5.0 e 5.1 do Laravel. Nessa evolução algumas coisas mudaram e infelizmente a documentação não necessariamente acompanhou as novidades de flexibilização de configuração.
Uma coisa que está documentada mas não é necessariamente explícita/clara é a possibilidade de compartilhar uma mesma aplicação em mais de um ambiente de configuração.
Imagine que você queira compartilhar uma aplicação para o ambiente de homologação (staging) e produção (production) apenas trocando as configurações de ambiente com base no domínio servido. Nos tempos do Laravel 4.x isso era configurado através de um recurso do próprio framework. Como você faria isso hoje? 🤔
Usando diferentes arquivos .env por ambiente, de modo que você pode ter um .env.staging para a homologação, um .env.production para a produção, um .env.testing para testes, etc. 😀
Mas como definir qual o ambiente que está sendo usado? Através da variável de ambiente APP_ENV. Ela é a informação chave do ambiente da aplicação, sendo portanto através dela que o framework toma qualquer decisão relacionada ao ambiente em que a aplicação está rodando.
Se por exemplo você tiver um arquivo .env cuja variável APP_ENV tenha o valor staging, nos bastidores o Laravel irá tentar carregar as variáveis de ambiente do arquivo .env.staging e estará efetivamente sobrescrevendo qualquer variável do arquivo .env. E como você já deve ter imaginado, essa variável APP_ENV não se limita ao arquivo .env: você pode usar as variáveis de ambiente a nível do servidor ou sistema para declarar ela, de modo que é possível até mesmo não precisar ter um arquivo .env genérico na raiz do projeto.
Isso aliás era algo que a documentação não esclarecia até então, de que as variáveis de ambiente externas podem não apenas sobrescrever as variáveis do arquivo .env como também substituir este arquivo. Não mais, algumas horas atrás enviei um patch para esclarecer isso (entre outras coisas) na documentação e o Taylor inclusive deu uma melhorada na minha proposta. :smile:
Note portanto que você pode usar as diretivas de configuração de ambiente do servidor web (Apache/Nginx/Lighttpd/LiteSpeed/etc) nas próprias definições de virtual host para determinar o ambiente que um dado domínio estará usando (através da variável APP_ENV), de modo que você pode compartilhar uma mesma instância da aplicação para diferentes ambientes através de diferentes arquivos .env. Isso sem precisar modificar uma única linha de código da aplicação. 😃
Observe que isso também pode ser aplicado ao artisan através da opção --env=. Se por exemplo você executar o comando php artisan migrate:refresh --env=staging, nos bastidores o Laravel estará levando em conta as informações presentes no arquivo .env.staging. 👍
Não menos importante, uma outra melhoria realizada na documentação da configuração de ambiente foi a inclusão de um aviso de segurança há muito tempo necessário a respeito do versionamento dos arquivos .env, de modo a deixar claro que isso nunca, jamais, em hipótese nenhuma deve ser feito. 😆
That's all, folks!