La dette technique est une idée lumineuse de Ward Cunningham en 1992, qui a comparé le développement logiciel à un prêt bancaire.
Sauf que les intérêts, c'est du code bancal difficile à maintenir, des bugs récalcitrants, et des délais qu'on ne maîtrise plus.
Votre projet ressemble à une longue partie de Whac-A-Mole : vous corrigez un bug, deux autres surgissent et ça finit par rattraper l'équipe, qui s'épuise à éteindre des incendies au lieu d'innover.
Git est puissant pour sa gestion des branches. Pour Git, une branche est juste un pointeur vers un commit de référence, représenté par un hash SHA-1.
Mais pas facile de se souvenir d’un hash, et encore moins de le partager à son collègue en lui disant : “tu peux valider la merge request de 34ac2 vers 98ca9 ?”
Très vite on peut se perdre avec les références de commit où l’historique du dépôt peut ressembler à un plat de spaghettis.
Docker se distingue par sa flexibilité et ses possibilités de personnalisation. Cette liberté, si elle n'est pas gérée avec prudence, peut mener à des pratiques suboptimales, compromettant la performance et la sécurité de vos systèmes. Dans cet article, nous vous présentons notre méthodologie, rigoureuse, pour minimiser ces risques, assurer la maintenabilité et optimiser vos applications sur nos infrastructures Docker.
Nous gérons pour nos clients des centaines de plateformes, il nous arrive donc souvent de devoir assister au débogage ce qui peut impliquer de valider si les réponses d'un site/API sont bien cohérentes avec les requêtes qu'il reçoit.
Si le gros du travail de débogage se fait du côté de la réponse, il est parfois utile de vérifier en premier lieu que la requête est correctement formée.
