Configuration avancée de l’environnement

Dans cette leçon, nous allons voir comment aller au-delà des simples configurations _ss_environment.php et comment déployer des fonctionnalités ciblées dans des environnements de développement, de test et en direct.

Dépôt de code à télécharger

  • Un aperçu des environnements
  • Configuration de la journalisation sur différents environnements
  • Traiter avec email

 

Un aperçu des environnements

Jusqu’ici, nous avons travaillé sur notre projet uniquement dans le contexte d’un environnement de développement, mais il est important de noter que nous allons éventuellement vouloir déployer dans un environnement de test distant et, espérons-le, peu après, un site Web de production. Un projet donné peut avoir de nombreux environnements, en particulier de grands projets qui impliquent plusieurs efforts de développement simultanés. Chaque environnement introduit un nouvel état et la gestion de cet état peut s’avérer très lourde si vous n’avez pas de configuration solide. Par conséquent, il est important de commencer à prendre en compte vos environnements dès le début de votre processus de développement.

Nous avons déjà parlé un peu de la pièce maîtresse de la gestion de l’environnement dans SilverStripe, le .envfichier. Pour rappel, ce fichier est destiné à résider au-dessus de la racine Web pour fournir des variables spécifiques à l’environnement au projet. Cela vous permet de déployer une base de code cohérente dans chaque environnement sans avoir à écrire de logique conditionnelle pour servir chaque environnement. Cela introduit toutefois la complexité de la nécessité d’un niveau plus élevé d’accès en écriture sur votre serveur. Vous devez donc vous assurer que vous disposez d’un accès shell ou d’un compte FTP hautement privilégié vous permettant d’éditer des fichiers au-dessus de la racine Web.

 

Configuration de la journalisation sur différents environnements

L’un des services que vous souhaitez activer lors du test et, plus encore, de la production, est la consignation et la notification des erreurs. Dans notre environnement de développement, nous souhaitons supprimer cette option, car éviter les erreurs verbeuses ne nous dérange pas. Une fois le projet mis en ligne, vous souhaitez supprimer autant que possible les erreurs d’affichage et simplement les déconnecter afin que vous puissiez les réparer de manière proactive.

À partir de la version 4.0, SilverStripe utilise la norme de journalisation PSR-3 . Cela signifie qu’il est facile d’échanger l’enregistreur avec une implémentation alternative et permet à votre application SilverStripe de bien fonctionner avec d’autres frameworks et bibliothèques.

Pour consigner les erreurs, il suffit d’accéder à l’interface du consignateur avec Injector.

 

use SilverStripe\Core\Injector\Injector;
use Psr\Log\LoggerInterface;

Injector::inst()->get(LoggerInterface::class)->error('Description of error');

 

Sont également disponibles selon la norme PSR-3:

  • emergency()
  • alert()
  • critical()
  • warning()
  • notice()
  • info()
  • debug()
  • log()

Pour une liste complète, voir la documentation du PSR-3] ( http://www.php-fig.org/psr/psr-3/ ).

C’est une bonne idée de les ajouter à votre code d’utilisateur, le cas échéant. La journalisation peut être très utile pour le débogage. Lorsque vous utilisez l’enregistreur dans vos classes, vous n’avez pas besoin de continuer Injectorà obtenir une instance d’enregistreur. Une approche plus propre consiste à injecter l’enregistreur en tant que dépendance.

 

namespace My\App;

use Psr\Log\LoggerInterface;
use PageController;

class MyPageController extends PageController
{
  private static $dependencies = [
    'logger' => '%$' . LoggerInterface::class
  ];

  protected $shouldFail = true;

  public $logger;

  public function doSomething()
  {
    if ($this->shouldFail) {
      $this->logger->log('It failed');
    }
  }
}

 

Ce que toutes ces méthodes de journalisation font réellement dépend de la mise en œuvre de LoggerInterfacecelle que vous utilisez. Par défaut, SilverStripe est fourni avec Monolog , une bibliothèque de journalisation livrée avec sa propre implémentation de journalisation PSR-3 Monolog\Logger.

La Monolog\Loggerclasse prend en charge les gestionnaires , qui doivent implémenter leur propre HandlerInterfacedéfinition. Vous pouvez ajouter autant de gestionnaires que vous le souhaitez. Certains gestionnaires couramment utilisés sont livrés avec SilverStripe Framework.

Voici un exemple d’ajout d’un gestionnaire de messagerie. Toute erreur se produisant au niveau de journalisation donné ou au-dessus de celui-ci enverra un courrier électronique à un administrateur. Faisons n’importe quoi error()et surtout envoyez un email.

app / _config / logging.yml

 

SilverStripe\Core\Injector\Injector:
  Psr\Log\LoggerInterface: 
    calls:
      EmailHandler: [ pushHandler, [ %$EmailHandler ] ]
  EmailHandler:
      class: Monolog\Handler\NativeMailerHandler
      constructor:
        - errors@example.com
        - Error reported on example.com
        - admin@example.com
        - error
      properties:
        ContentType: text/html
        Formatter: %$SilverStripe\Logging\DetailedErrorFormatter

 

Le courrier électronique étant une forme de notification d’erreur assez agressive, nous ne souhaitons probablement pas l’envoyer ailleurs que dans l’environnement en direct. Mettons cela dans un bloc conditionnel.

app / _config / logging.yml

 

    --- 
    Name: lessons-live-logging
    Only:
      environment: live
    ---
    SilverStripe\Core\Injector\Injector:
     Psr\Log\LoggerInterface: 
      calls:
        EmailHandler: [ pushHandler, [ %$EmailHandler ] ]
    #...

 

Une meilleure option pour les erreurs de bas niveau consiste à écrire dans un fichier journal. Réglons cela pour tout ce qui dépasse le notice()niveau.

app / _config / logging.yml

 

    ---
    Name: lessons-all-logging
    ---
    SilverStripe\Core\Injector\Injector:
      Psr\Log\LoggerInterface: 
        calls:
          FileLogger: [ pushHandler, [ %$FileLogger ] ]
      FileLogger:
        class: Monolog\Handler\StreamHandler
        constructor:
          - "../errors.log"
          - "notice"

 

Veillons à ce que le journal des erreurs ne soit pas archivé dans notre référentiel en l’ajoutant à .gitignore.

.gitignore

...
# ignore error log
errors.log

Traiter avec email

Pendant que nous parlons de courrier électronique, prenons un certain contrôle sur les courriers électroniques transactionnels dans nos environnements. Cela peut être un problème vraiment ennuyeux pour plusieurs raisons. D’une part, si nous testons avec de vraies données, nous ne voulons pas que les emails transactionnels soient envoyés à de vrais utilisateurs à partir de notre environnement de développement. Deuxièmement, nous voulons pouvoir vérifier si ces courriels seraient envoyés et quel serait leur contenu si nous étions en production.

Une solution simple à ce problème consiste simplement à forcer l’adresse “to” à vous contacter dans l’environnement de développement. Vous pouvez le configurer dans la configuration yaml.

app / _config / config.yml

 

Email:
  send_all_emails_to: 'me@example.com'

 

Assez simple, mais nous oublions quelque chose. Nous ne voulons pas que ce paramètre s’applique à tous les environnements. Nous devons nous assurer que ce yaml n’est chargé que dans l’environnement dev. Nous n’écrivons pas PHP, nous n’avons donc pas l’avantage des blocs if / else, mais heureusement, l’analyseur SilverStripe YAML nous offre une API de base pour la logique conditionnelle.

app / _config / email.yml

 

    ---
    Name: dev-email
    Only:
      environment: dev
    ---
    Email:
      send_all_emails_to: 'me@example.com'

 

Peut-être que dans les environnements de test et de production, nous souhaitons surveiller le courrier électronique transactionnel à distance. Nous pourrions forcer un BCC à notre adresse e-mail dans ce cas.

app / _config / email.yml

 

    ---
    Name: dev-email
    Only:
      environment: dev
    ---
    Email:
      send_all_emails_to: 'me@example.com'
    ---
    Name: live-email
    Except:
      environment: dev
    ---
    Email:
      bcc_all_emails_to: 'me@example.com'

 

Cela fonctionne bien, mais c’est un peu large. Si nous avons d’autres développeurs sur le projet, ils ne recevront aucun courrier électronique et nous ne pouvons pas non plus tester avec précision, dans notre environnement de développement, ce que l’adresse “à” serait réellement en production ou à tester.

MailCatcher

Une solution beaucoup plus complète consiste à utiliser un outil tiers pour capturer les e-mails sortants de votre environnement de développement. Quelques outils sont disponibles, mais celui que je préfère et que je recommande est MailCatcher . Suivez les instructions de la page d’accueil pour installer le logiciel, et avec juste un peu de configuration, vous pouvez diriger tous les courriels dans une boîte de réception locale. Pour parcourir la boîte de réception, visitez simplement localhost: 1080. Désormais, vous pouvez surveiller tous les courriels sortants et savoir exactement qui les recevra et quel sera leur contenu dans un environnement de production.

TOUT VOIR Ajouter une remarque
VOUS
Ajoutez votre commentaire
 
© Academy EdTech. 2019 All rights reserved.
X