Sans aller dans le mono vs multiple repo, ce que dit le site en question c’est tout simplement une appli doit être 100% contenue dans un seul repo (en gros pas le droit de faire un checkout de 2 repos pour devoir builder une seule appli, donc pas de git submodules), et que si du code est partagé, alors ce code doit être construit sous forme de bibliothèque (je suppute pour offrir une gestion de version).
C’est tourné de façon un peu alambiqué, mais c’est du bon sens.
Ça n’exclue pas le mono repo, mais ça implique que chaque « sous repo » soit capable de pointer vers une version spécifique de sa dépendance. En gros, si tu veux faire du monorepo, il te faut un système similaire à ce que fait Google en interne. Et ca n’exclue pas le multi repo.
Le 1 repo 1 app est un problème pour des systèmes distribués, typiquement le backend de n’importe quel site de taille raisonnable. Quand t’as plus de 100 services qui contribuent tous au backend, ça veut dire 100 repos. Ça devient plus dur de trouver le code, de faire des scans automatique etc. C’est des problèmes qui peuvent se résoudre, mais le mono repo les évite par design. Après, ça apporte d’autres problèmes, qui peuvent aussi se résoudre. Comme toujours c’est une question de compromis.
Pour le point 11, c’est aussi du bon sens: tes logs sont juste un flux d’événements. Au bout du flux se trouvent des appenders. Ils peuvent écrire sur le disque s’ils veulent, sur stdout s’ils veulent, ou balancer tout ça à ta stack ELK. En gros ce que fait logback ou log4j de base. Au call site, tu te contente de dire log.info("Successfully refubulated the automatic magnetic flux"), sans te préoccuper de savoir ou ça peut bien aller (potentiellement, nulle part).
Bref, ce que je vois surtout dans ce journal, c’est 2 personnes qui ont des problèmes de compréhension de l’anglais.
[^] # Re: Moui... mais...
Posté par groumly . En réponse au journal Douze facteurs dans ta tronche. Évalué à 8. Dernière modification le 07 novembre 2022 à 03:31.
Sans aller dans le mono vs multiple repo, ce que dit le site en question c’est tout simplement une appli doit être 100% contenue dans un seul repo (en gros pas le droit de faire un checkout de 2 repos pour devoir builder une seule appli, donc pas de git submodules), et que si du code est partagé, alors ce code doit être construit sous forme de bibliothèque (je suppute pour offrir une gestion de version).
C’est tourné de façon un peu alambiqué, mais c’est du bon sens.
Ça n’exclue pas le mono repo, mais ça implique que chaque « sous repo » soit capable de pointer vers une version spécifique de sa dépendance. En gros, si tu veux faire du monorepo, il te faut un système similaire à ce que fait Google en interne. Et ca n’exclue pas le multi repo.
Le 1 repo 1 app est un problème pour des systèmes distribués, typiquement le backend de n’importe quel site de taille raisonnable. Quand t’as plus de 100 services qui contribuent tous au backend, ça veut dire 100 repos. Ça devient plus dur de trouver le code, de faire des scans automatique etc. C’est des problèmes qui peuvent se résoudre, mais le mono repo les évite par design. Après, ça apporte d’autres problèmes, qui peuvent aussi se résoudre. Comme toujours c’est une question de compromis.
Pour le point 11, c’est aussi du bon sens: tes logs sont juste un flux d’événements. Au bout du flux se trouvent des appenders. Ils peuvent écrire sur le disque s’ils veulent, sur stdout s’ils veulent, ou balancer tout ça à ta stack ELK. En gros ce que fait logback ou log4j de base. Au call site, tu te contente de dire
log.info("Successfully refubulated the automatic magnetic flux"), sans te préoccuper de savoir ou ça peut bien aller (potentiellement, nulle part).Bref, ce que je vois surtout dans ce journal, c’est 2 personnes qui ont des problèmes de compréhension de l’anglais.