Comment charger différents paramètres de configuration du pilote de messagerie en fonction du paramètre app_env dans l'application Laravel 5.3 ?

Question

Dans mon application PHP Laravel 5.3, mes paramètres de configuration se trouvent dans le fichier .env avec le fichier APP_ENV=local qui peut être changé en APP_ENV=production lorsque mon application est en mode production/live.

Dans ce .env J'ai également un fichier MAIL_DRIVER=preview qui s'inscrit dans mon config/mail.php avec le fichier de configuration env('MAIL_DRIVER', 'smtp') comme ça :

return [
    'driver' => env('MAIL_DRIVER', 'smtp'),
]

Donc maintenant ma question est, quand je change mon .env réglage APP_ENV=local en APP_ENV=production

Comment puis-je faire en sorte qu'il charge un autre env('MAIL_DRIVER') sur cette base env('APP_ENV') le réglage ?

existe-t-il un moyen de charger différentes .env pour chaque environnement ou différents fichiers de configuration ou comment gérer cela dans Laravel 5.3.

Je me souviens que dans les anciennes versions de Laravel, il suffisait de créer un nouveau dossier dans le dossier de configuration pour chaque environnement, mais l'ensemble du système de configuration est différent de ces anciennes versions.

Answer 1

Avec Laravel 5, vous disposez d'une copie différente de votre .env dans chaque environnement.

Ce fichier n'est PAS livré dans votre dépôt. Au contraire, votre .env.example et c'est ce que vous faites une copie et nommez en tant que .env dans l'environnement.

Dans les versions précédentes de Laravel (c'est-à-dire <= 4), vous pouviez avoir des fichiers d'environnement séparés dans la même copie extraite du projet et passer d'un environnement à l'autre, mais cela n'a pas beaucoup de sens.

Gardez votre .env.example à jour avec toutes les options dont vous aurez besoin dans votre application, et initialisez-les à des valeurs vides. Lorsque vous déployez dans un nouvel environnement, vous le copiez en tant que nouveau fichier, ce qui vous évite de commettre accidentellement des informations d'identification dans votre repo et permet de garder les choses simples :

cp .env.example .env

Ensuite, éditez le fichier et définissez les valeurs pour qu'elles soient appropriées à cet environnement spécifique. Par exemple, au lieu d'utiliser les clés API de test, vous pouvez utiliser les clés de production pour certains services. En éditant, par exemple :

sudo vim .env # If you like VIM

ou

sudo nano .env # If you like NANO

Une exception à ce que je viens de dire ci-dessus concerne les tests. Selon la documentation :

Vous pouvez également créer un fichier .env.testing. Ce fichier remplacera les valeurs du fichier .env lors de l'exécution des tests PHPUnit ou des commandes Artisan avec l'option --env=testing.

Dans ce cas, le fait d'avoir votre fichier .env.testing dans votre dépôt est très probablement acceptable, à condition qu'il ne contienne pas de valeurs de production sensibles, ce qui ne devrait probablement pas être le cas.