Avant, je redoutais avoir à élaborer des codes pour des tâches liées à la messagerie. J’ai toujours eu l’impression que c’était difficile à préparer et qu’il y avait beaucoup de risques que les choses tournent mal. Lorsque la tâche de courriel sur laquelle nous travaillons est toujours en cours, nous voulons éviter d’envoyer des courriels à des personnes extérieures à notre équipe de développement. Nous essayons d’éviter d’inonder cette courte liste de personnes avec une multitude de courriels, car des ajustements mineurs sont continuellement effectués et testés.
Puisque j’ai travaillé avec plusieurs technologies différentes, j’ai expérimenté différentes façons d’aborder cette situation. Nombre de ces approches viennent avec leurs problèmes propres. Je vais commencer par illustrer quelques mauvais exemples, car c’est toujours une bonne chose d’apprendre des erreurs des autres au lieu d’apprendre à la dure. Ensuite, nous explorerons une bonne façon, selon moi, de gérer les courriels à partir d’un environnement de développement.
Exemples de mauvaises façons de faire
Envoi de courriels à des dossiers de bases de données
Dans certains systèmes avec lesquels j’ai travaillé, les courriels devaient être envoyés aux utilisateurs ayant des dossiers de bases de données. Souvent, ces dossiers d’utilisateurs contenaient des données réelles, donc des adresses électroniques de gens qui n’auraient pas dû recevoir de messages pendant le processus d’essai et de développement. J’ai malheureusement été témoin de moments où ces personnes ont reçu des courriels par erreur. C’est problématique!
Cette situation peut être évitée par un remplacement d’adresse électronique. Pour ce faire, une logique peut être incluse dans le code base pour remplacer une vraie adresse électronique par une représentation codée en dur de celle du développeur pour que lui seul reçoive le courriel.
Cela nécessite de modifier le code lui-même, ce qui n’est pas idéal. Dans ce cas, il faudra soit rechanger le code une fois qu’il sera prêt à la production, soit mettre en place une logique d’embranchement qui détermine si le code est exécuté à partir d’un environnement de production ou de développement. Même si cela fonctionne, je pense que nous préférons tous éviter de changer un code uniquement pour qu’il s’adapte à l’environnement à partir duquel il est exécuté.
Envoi massif de courriels
Il s’agit d’un autre problème que j’ai vu alors que le développeur pensait agir de manière sécuritaire. Les courriels n’étaient envoyés qu’à des collègues, mais de façon massive. Une boucle avait été établie pour parcourir la liste de collègues qui pouvaient recevoir le courriel. Cela avait été organisé pour que chaque personne ne reçoive qu’un courriel individuel, ce qui permettait de ne pas exposer les adresses électroniques des autres.
Malheureusement, pendant le développement, la boucle n’a pas fonctionné correctement, et aurait tourné indéfiniment pendant la période d’essai si elle n’avait été interrompue. Lorsque le problème a été identifié, il était déjà trop tard. Puisque les courriels étaient vraiment distribués, le volume de courriels envoyés a fait que le domaine de messagerie de l’expéditeur a été mis sur liste noire. C’était un problème majeur!
Comment envoyer des courriels à partir d’un environnement de développement
MailHog
Je ne crains plus de travailler sur des tâches liées à la messagerie. Cette nouvelle confiance, je la dois au fait d’avoir les bons outils pour m’en occuper de façon correcte. Dernièrement, je me suis tourné vers une application nommée MailHog. Il s’agit d’un utilitaire qui fonctionne comme un serveur de messagerie, mais qui capture les courriels entrant dans une base de données et offre une interface de site Web pour les visualiser plutôt que de les envoyer au destinataire ciblé (il est aussi possible d’envoyer le courriel après la prévisualisation).
Il existe plusieurs autres utilitaires comme MailHog, mais selon moi, il s’agit du plus simple à installer et à utiliser. MailHog est écrit en GoLang. Il pourra donc compiler pour à peu près toutes les plate-formes sur lesquelles vous l’exécuterez. Je travaille dans l’environnement Windows et il y a un système binaire que je peux télécharger et exploiter assez facilement (sans installation). Ils offrent même un DOCKERFILE qui permet de l’utiliser avec Docker Hub si vous préférez fonctionner ainsi.
Pratiques exemplaires
Lorsque je l’exécute, je le lance en utilisant les aiguillages suivants pour qu’il fonctionne selon la configuration que j’ai choisie :
-smtp-bind-addr :2500 -api-bind-addr :8080 -ui-bind-addr :8080Cela lui indique de détecter les courriels sur le port 2500 (la plupart des serveurs de messagerie utilisent le port 25), et me permet de voir tous les courriels reçus en utilisant un navigateur dirigé vers http://localhost:8080
Une fois qu’il est en exécution, assurez-vous que le code sait que votre serveur de messagerie est situé sur un serveur local localhost on port 2500que tous les courriels subséquents qu’il envoie devraient être interceptés par MailHog. C’est aussi simple que ça!
Une fois tout cela configuré, vous pouvez être sûr que vous pourrez voir les courriels comme prévu. Le destinataire initial du courriel sera conservé, le contenu du courriel peut être consulté dans les formats HTML ou texte, vous pouvez prévisualiser ou télécharger les pièces jointes, etc.
Lors de la mise en place d’un système d’envoi de courriels, il est toujours bon de configurer les détails du serveur de messagerie à un seul endroit. Il s’agit d’une pratique courante avec les fichiers .env, mais ce ne sont pas toutes les technologies qui sont capables de mettre à profit une telle configuration. Une fois que vous aurez mis en place ce type de pratique exemplaire, seul ce fichier de configuration devra être mis à jour lorsque vous déplacerez le projet du développement à l’environnement de sandbox/production.
J’espère que cela vous servira et simplifiera vos tâches liées à la messagerie. Si vous avez besoin d’aide pour mettre en place une telle façon de faire, n’hésitez pas à communiquer avec nous.