Docker qui prolifère jusqu'à neuf fichiers
Nine Dockerfiles across five apps with dev and prod variants, consolidated to two by selecting the app through build args.
Deux copies ont divergé
Une idée tenue à la main à deux endroits — schéma et migration, dev et prod, app et app.
Aucune mauvaise décision isolée, juste des décisions raisonnables qui s'empilent. Cette application a besoin de son propre Dockerfile. Le dev a besoin d'arguments de build différents de la prod, alors on ajoute une variante .dev. Répète pour web, admin, super-admin, mobile et back-end et tu as 9 fichiers, et le moindre changement de build partagé implique d'en éditer la moitié.
Il y en a 2 maintenant — un back-end, un front-end — avec des arguments de build qui sélectionnent l'application. Les trois applications front-end partagent presque toute leur chaîne et n'ont jamais eu besoin de fichiers séparés. Dans un monorepo où plusieurs choses partagent un processus de build, prends par défaut un Dockerfile paramétré par composant logique plutôt qu'un par déployable. Ça découle du fait de ne pas avoir planifié la forme de l'infra d'entrée.