Une boîte fourre-tout est la réponse la plus simple possible à un problème de préproduction : au lieu de créer un compte pour chaque adresse dont un environnement pourrait avoir besoin, vous demandez au domaine de tout remettre à une seule boîte. N’importe quelle partie locale est acceptée, rien ne doit être provisionné au préalable, et une fixture qui invente une adresse sur-le-champ fonctionne quand même. La commodité est réelle, et les coûts le sont aussi, ces derniers ayant tendance à apparaître quelques semaines après avoir basculé l’interrupteur.
Ce que fait réellement une boîte fourre-tout
Chaque domaine doit publier un enregistrement nommant le serveur qui accepte le courrier pour lui. Cela est commun à tout le courrier. Ce qu’un fourre-tout ajoute, c’est une règle du côté récepteur : lorsqu’un message arrive pour une partie locale qui n’a pas de boîte, au lieu de le rejeter, on le remet à une boîte désignée.
La distinction qui compte est celle entre un joker et une règle par défaut. Certains systèmes récepteurs acceptent tout et trient ensuite ; d’autres n’acceptent n’importe quoi que lorsqu’aucune correspondance plus spécifique n’a été trouvée. Les deux se comportent identiquement quand un test invente une nouvelle adresse, et ils se comportent de manière très différente quand un message arrive pour une adresse que vous avez délibérément bloquée.
Pourquoi les équipes de préproduction y recourent-elles ?
La motivation tient presque toujours à la friction. Considérez ce qu’un fourre-tout supprime :
- Aucune étape de provisionnement avant qu’un test puisse s’exécuter, donc un nouveau cas n’a pas besoin qu’une nouvelle boîte soit créée pour lui.
- Aucune coordination entre les équipes, car n’importe quelle adresse du domaine fonctionne pour tout le monde.
- Aucune dépendance à un fournisseur de messagerie externe, puisque tout le domaine est sous votre contrôle.
- Aucun courrier perdu quand un test génère une adresse avec une étiquette aléatoire, ce que les tests font précisément.
Pour une équipe qui passe ses journées à trier des échecs causés par des boîtes manquantes, un fourre-tout ressemble au remède d’une catégorie entière de bruit. La question qui vaut la peine d’être posée est de savoir contre quel bruit il l’échange.
Qu’est-ce qui va mal quand tout atterrit dans une seule boîte ?
Le volume et la sensibilité, principalement, et ils se cumulent.
| Risque | Pourquoi cela arrive | Ce que cela coûte |
|---|---|---|
| Volume illimité | N’importe quelle adresse du domaine est acceptée | Le stockage se remplit et la boîte cesse d’être lisible |
| Trafic sans rapport mélangé | Tests et services partagent une seule destination | Les échecs deviennent difficiles à attribuer |
| Capture accidentelle de vrai courrier | Un domaine est réutilisé ou mal orthographié | Le message d’une vraie personne stagne dans un plateau de test |
| Conservation sans propriétaire | Personne ne possède une boîte partagée | Les données s’attardent longtemps après l’exécution |
La troisième ligne est celle à prendre au sérieux. Un domaine utilisé en préproduction est un domaine qui finira par apparaître dans une configuration, dans une capture d’écran, dans un ticket de support ou dans un rejet. Dès qu’un vrai message peut atteindre cette boîte, le fourre-tout a cessé d’être une commodité de test pour devenir une boîte sans propriétaire contenant la correspondance de quelqu’un d’autre.
Il existe une quatrième défaillance, plus silencieuse que les autres : un fourre-tout configuré sur la mauvaise zone. Si la règle est appliquée à un domaine partagé plutôt qu’à un sous-domaine réservé aux tests, les notifications internes et le courrier administratif peuvent aboutir dans un plateau que personne ne surveille, ce qui est à la fois un problème de confidentialité et un problème de fiabilité lorsque le message était censé aller quelque part de réel.
Garder le courrier de production hors d’une boîte de préproduction
La règle à concevoir autour tient en une phrase : la préproduction ne doit jamais pouvoir recevoir du courrier adressé à un utilisateur de production. Tout le reste relève de la mise en œuvre.
La forme pratique de cette règle est un domaine dédié, ou un sous-domaine dédié, dont le seul rôle est le trafic de test, combiné à un examen des endroits où ce domaine est référencé. Les configurations d’alerte, de facturation et de notification en particulier ne devraient pointer vers des adresses de ce domaine que dans les environnements de préproduction, et la différence entre environnements devrait provenir de la configuration plutôt que d’une étape manuelle que quelqu’un doit se rappeler.
Conservation et nettoyage comme décision de conception
Une boîte partagée sans politique de conservation devient une pile grandissante que personne ne peut lire et que personne n’ose supprimer. Décidez deux choses à l’avance : combien de temps un message capturé est conservé, et ce qui se passe à la fin de cette période.
Une conservation courte est plus douce pour tout le monde. Un plateau de test qui se vide tout seul borne le volume, empêche le contenu sensible de stagner, et rend la boîte de nouveau lisible après une semaine bruyante. Quelle que soit la fenêtre, elle devrait être une propriété documentée de l’environnement de préproduction plutôt que l’accident d’un disque qui se remplit. Si vous ne pouvez pas dire combien de temps un message survit, vous n’avez pas encore de politique.
Pour les développeurs : routage par préfixe et portée de l’interrupteur
L’amélioration la moins coûteuse d’un fourre-tout consiste à cesser de le traiter comme un seau indifférencié. Comme la partie locale du destinataire est capturée avec le message, vous pouvez router dessus : donnez à chaque test ou à chaque service son propre préfixe, et laissez le code de lecture filtrer par ce préfixe plutôt que par ordre d’arrivée.
Limitez ensuite la portée du joker. Préférez une règle qui accepte un ensemble connu de motifs et rejette tout le reste à une règle qui accepte tout. Une liste d’autorisation vous coûte une ligne de configuration par nouveau consommateur et supprime toute la classe de capture accidentelle, car une adresse que personne n’a enregistrée est refusée plutôt qu’absorbée.
Enfin, traitez le fourre-tout comme un réglage d’environnement, et non comme une propriété permanente du système de messagerie. Si la même configuration est appliquée partout parce que c’est plus facile que de la faire varier, l’arrangement de préproduction finira par s’appliquer là où il ne le devrait pas. L’article sur les données de départ pour la préproduction couvre le même principe pour les comptes et les lignes avec lesquels un environnement de préproduction démarre.
Quiconque utilise ce motif devrait garder son but en vue. Un fourre-tout ici est de la plomberie d’ingénierie pour le trafic de test, pas une identité, et il ne devrait jamais être traité comme la boîte d’une personne réelle.
Étapes suivantes
Ouvrez la configuration qui définit votre domaine de préproduction et répondez à une question : que devient un message adressé à une adresse qu’aucun test n’a jamais utilisée ? Si la réponse est qu’il atterrit dans la boîte partagée, resserrez la règle. Quand vous avez besoin d’une seule boîte éphémère plutôt que d’un domaine, la page de courrier temporaire en crée une à la demande, et la capture de courrier à l’intérieur du pipeline explique la variante qui ne quitte jamais la machine de build.