Ce que coûtent réellement les preview environments
Le coût des preview environments augmente avec le nombre de pull requests ouvertes, pas avec la taille de l'équipe. Découvrez où se cachent les dépenses, quelles ressources partager et comment faire expirer les previews pour que cinq PR ouvertes ne deviennent pas cinq stacks.
Les preview environments font partie des fonctionnalités les plus rentables qu'une équipe puisse activer. Un reviewer clique sur un lien et utilise la modification au lieu de lire un diff en essayant de se la représenter. Le design détecte les problèmes avant le merge. La QA cesse d'être une phase distincte.
C'est aussi le poste de dépenses le plus susceptible de faire discrètement tripler votre facture, pour une raison liée à l'arithmétique que personne ne prend le temps de calculer au moment d'activer la fonctionnalité.
L'arithmétique
Le coût d'un preview environment évolue avec le nombre de pull requests ouvertes, et non avec le nombre de personnes dans l'équipe ou le nombre de merges.
Une équipe de quatre personnes avec une bonne culture de la review peut avoir cinq à huit PR ouvertes à un instant donné. Si chacune provisionne une copie complète de votre stack, vous exécutez cinq à huit copies de la production en plus de la production elle-même. Une stack dont l'exécution coûte 30 $ par mois revient alors à 180–270 $, sans que cela apparaisse dans les estimations de qui que ce soit, car l'estimation portait sur un seul environnement.
Pire encore, le nombre de PR ouvertes augmente précisément aux périodes où les mauvaises surprises sont le moins bienvenues : avant une release, pendant un refactor, lorsqu'une personne est en congé et que sa branche reste ouverte pendant trois semaines.
Où va réellement l'argent
Toutes les composantes d'une preview n'ont pas le même coût, et c'est en sachant les distinguer que vous pouvez maîtriser les dépenses.
Conteneurs applicatifs — coût modéré, et qui en vaut la peine. C'est la partie dont vous avez réellement besoin. C'est aussi celle qui se réduit facilement, car une preview n'a pas besoin de la mémoire de la production.
Bases de données — la partie coûteuse. Une base de données dédiée par preview est le principal poste de dépenses, et c'est généralement la ressource la moins nécessaire. La plupart des reviews n'ont pas besoin d'une base de données isolée ; elles ont besoin d'une base contenant des données plausibles.
Minutes de build — invisibles et cumulatives. Chaque push sur une PR ouverte déclenche un nouveau build. Une branche avec quarante commits sur deux semaines est buildée quarante fois. Il s'agit d'une dépense bien réelle qui n'apparaît jamais comme une ressource en cours d'exécution et échappe donc complètement à l'audit mental.
Egress — faible par preview, important au total. Les URL de preview sont découvertes et crawlées. Un crawler qui récupère vos assets depuis huit preview environments effectue huit fois plus de travail que sur la production, et vous payez l'ensemble de ce trafic.
Quatre mesures pour réduire les coûts sans perdre la valeur
Partager la base de données
Pour la majorité des changements, les previews peuvent partager une base de données contenant des données représentatives. Réservez les bases de données isolées aux PR qui en ont réellement besoin : migrations, changements de schéma et opérations destructives.
La règle qui fonctionne en pratique : base de données isolée uniquement lorsque la PR touche au schéma. Tout le reste est partagé.
Réduire la taille de la preview
Une preview consultée par un seul reviewer n'a pas besoin des ressources de la production. Réduire de moitié la mémoire et utiliser une fraction du CPU est généralement invisible pour la personne qui effectue la review, tout en diminuant sensiblement les coûts.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Les faire expirer
C'est la mesure qui a le plus fort impact. Une preview ne devrait pas survivre à sa pull request.
La suppression automatique lors du merge ou de la fermeture de la PR est le strict minimum. Ce qui piège les équipes, ce sont les PR abandonnées : une branche créée par quelqu'un qui a été affecté à autre chose et n'a jamais été fermée. Ces environnements tournent pendant des mois.
Un âge maximal constitue le filet de sécurité idéal : toute preview âgée de, disons, quatorze jours est supprimée, quel que soit l'état de la PR. Si quelqu'un en a de nouveau besoin, une seule commande suffit.
Les exclure des moteurs de recherche
Les URL de preview sont indexées. C'est problématique pour deux raisons : le contenu dupliqué entre en concurrence avec votre site de production, et vous payez le trafic des crawlers sur des environnements que personne n'utilise.
dockup noindex my-project/my-api --on
Sur Dockup, les PR previews sont configurables par service et peuvent être activées ou désactivées explicitement, plutôt que de dépendre d'un paramètre global dont vous héritez :
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Les lister est l'étape que les équipes sautent, avant de le regretter. Les environnements que vous ne pouvez pas dénombrer sont des environnements pour lesquels vous payez sans le savoir.
L'audit à réaliser une fois par mois
Trois questions, cinq minutes :
- Combien de previews tournent actuellement ? Comparez ce nombre à celui des PR réellement ouvertes.
- Quel âge a la plus ancienne ? Au-delà de deux semaines, elle est presque certainement abandonnée.
- Lesquelles ont leur propre base de données ? Tout ce qui ne correspond pas à un changement de schéma n'en a probablement pas besoin.
La plupart des équipes découvrent au moins un environnement issu d'une PR mergée plusieurs mois auparavant, qui tourne toujours et continue d'être facturé.
Profiter de la valeur sans mauvaise surprise
Rien de tout cela ne constitue un argument contre les preview environments. Il s'agit de les traiter comme une infrastructure dotée d'un lifecycle, plutôt que comme une simple case à cocher.
Les équipes qui maîtrisent le sujet font trois choses : elles réduisent la taille des previews, les font expirer et partagent ce qui peut l'être sans risque. Cela permet généralement de maintenir l'ensemble de l'empreinte des previews à un coût inférieur à celui d'un seul service de production — un niveau de dépenses qui rend leur intérêt évident.
Les équipes qui ont de mauvaises surprises sont celles qui ont activé la fonctionnalité une fois, correctement, puis n'ont plus jamais consulté la liste.
Foire aux questions
Les preview environments coûtent-ils autant que la production ? Par environnement, ils peuvent coûter autant si leur configuration est identique. Avec des ressources réduites et une base de données partagée, une preview coûte généralement une fraction du prix de la production.
Chaque preview doit-elle avoir sa propre base de données ? Uniquement lorsque la modification touche au schéma. Le partage d'une base contenant des données initialisées couvre la plupart des reviews et supprime le principal poste de dépenses.
Que devient une preview lorsque la PR est fermée ? Elle devrait être automatiquement détruite. Sinon, vous accumulerez des environnements issus de PR dont plus personne ne se souvient.
Les preview environments nuisent-ils au SEO ?
Ils le peuvent s'ils sont indexés : le contenu dupliqué entre en concurrence avec vos pages de production. Ajoutez-leur l'attribut noindex, ce qui empêche également les crawlers de générer du trafic que vous payez.