Alors, 1 repo pour 1 app, c'est un truc qui me semble super sur le papier, mais je ne vois pas comment le faire fonctionner efficacement passé une certaine complexité. Les systèmes avec lesquels je travaille ont typiquement des dizaines d'applications. Une moitié sont des applications de type "service", et l'autre moitié de type "outil console" pour contrôler ou requêter les services. Chaque application est typiquement très petite, et dépend de 3 ou 4 grosses bibliothèques avec beaucoup de fonctionnalités communes. Est-ce donc qu'il me faut un dépôt par bibliothèque, et 25 dépôts supplémentaires pour chaque application ?
En fait, c'est là que je ne comprends plus. Par exemple, je change une API dans ma bibliothèque, faut-il que je déploie ma bibliothèque (tests, revue de code, fusion...), puis que j'aille dans chacun des 25 dépôts pour vérifier si ça compile, faire les changements, et faire 25 déploiements (tests, revue de code, fusion...) ? Et rebelotte si je me suis vautré au début ? Je ne comprends absolument pas en quoi séparer les dépôts aide à quoi que ce soit.
Mais j'aimerais savoir si il existe un meilleur modèle, parce que sur le principe, un peu de modularité dans mon monorepo, j'aime bien, avec principalement l'idée de réduire le temps de compilation / test.
Ensuite, sur les logs, en effet, dans un cloud Kubernetes, je suis d'accord : c'est logique de sortir les logs sur la sortie standard, et de laisser Kubernetes balancer tout ça vers un Elastic Search ou équivalent. Mais... Elastic Search, que c'est lent ! C'est pratique pour trouver des lignes de log corrélées entre plusieurs applications, mais pour explorer un simple fichier, j'ai du mal à trouver quelque chose d'aussi efficace que tail / grep / sed. Je me demande d'ailleurs si il serait possible d'avoir un volume NFS rien que pour les logs, et d'avoir l'application qui monte ce volume et qui logge dessus, afin de pouvoir taper dedans plus facilement ?
Bref, je cherche encore, et je suis preneur de conseils.
[^] # Re: Moui... mais...
Posté par small_duck (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 6. Dernière modification le 05 novembre 2022 à 23:14.
Merci de ta réponse !
Alors, 1 repo pour 1 app, c'est un truc qui me semble super sur le papier, mais je ne vois pas comment le faire fonctionner efficacement passé une certaine complexité. Les systèmes avec lesquels je travaille ont typiquement des dizaines d'applications. Une moitié sont des applications de type "service", et l'autre moitié de type "outil console" pour contrôler ou requêter les services. Chaque application est typiquement très petite, et dépend de 3 ou 4 grosses bibliothèques avec beaucoup de fonctionnalités communes. Est-ce donc qu'il me faut un dépôt par bibliothèque, et 25 dépôts supplémentaires pour chaque application ?
En fait, c'est là que je ne comprends plus. Par exemple, je change une API dans ma bibliothèque, faut-il que je déploie ma bibliothèque (tests, revue de code, fusion...), puis que j'aille dans chacun des 25 dépôts pour vérifier si ça compile, faire les changements, et faire 25 déploiements (tests, revue de code, fusion...) ? Et rebelotte si je me suis vautré au début ? Je ne comprends absolument pas en quoi séparer les dépôts aide à quoi que ce soit.
Mais j'aimerais savoir si il existe un meilleur modèle, parce que sur le principe, un peu de modularité dans mon monorepo, j'aime bien, avec principalement l'idée de réduire le temps de compilation / test.
Ensuite, sur les logs, en effet, dans un cloud Kubernetes, je suis d'accord : c'est logique de sortir les logs sur la sortie standard, et de laisser Kubernetes balancer tout ça vers un Elastic Search ou équivalent. Mais... Elastic Search, que c'est lent ! C'est pratique pour trouver des lignes de log corrélées entre plusieurs applications, mais pour explorer un simple fichier, j'ai du mal à trouver quelque chose d'aussi efficace que tail / grep / sed. Je me demande d'ailleurs si il serait possible d'avoir un volume NFS rien que pour les logs, et d'avoir l'application qui monte ce volume et qui logge dessus, afin de pouvoir taper dedans plus facilement ?
Bref, je cherche encore, et je suis preneur de conseils.