Pourquoi la taille de la construction est-elle une telle préoccupation?

J'entends souvent (de la part de personnes, mais aussi de CLI informatives) que la "taille de build / slug est grande". Cela est particulièrement vrai lorsque la taille de la construction est de 0,5 à 2 Go.

Pourquoi (ou dans quelles circonstances) la taille de la construction est-elle une telle préoccupation?

Remarque: la raison pour laquelle je pose la question est parce que je considère que les ressources comme le stockage et le calcul sont relativement bon marché par rapport au passé, donc, je m'attends à ce que la taille de la construction soit moins problématique maintenant que par le passé.

Lorsque je soulève un problème de taille de build comme une préoccupation, cela ne vient généralement pas de "c'est si gros, il sera coûteux de le stocker".

Les principaux problèmes avec les grandes versions sont les suivants -

• augmentation du temps d'expédition. déplacer de gros morceaux d'un endroit à un autre prend beaucoup de temps.
• les changements fréquents de gros artefacts et une longue période de rétention enoug rendent le stockage de tels artefacts coûteux, moins avec les artefacts en couches comme les images docker.
• la création de tels grands artefacts prend généralement beaucoup de temps, plus que la création d'artefacts beaucoup plus petits. l'automatisation du processus pour créer des artefacts plus petits peut prendre du temps, mais l'automatisation qui est répétable doit être aussi courte que possible pour permettre un retour rapide.
• la récupération après un échec (selon la configuration) peut prendre plus de temps avec des artefacts plus importants, en particulier lorsqu'un ancien artefact doit être réappliqué au lieu d'un nouveau défectueux.

Je souscris aux quatre métriques devops:

• Délai pour les changements - raccourcissez-le
• Fréquence de déploiement - augmenter la fréquence
• Il est temps de restaurer le service - raccourcissez-le
• Modifier le taux d'échec - le réduire à jamais

Les gros artefacts créent généralement un problème dans chacune de ces mesures, et aucune de ces mesures ne concerne vraiment le coût du stockage - car c'est bon marché, le temps est cher.

Complétant la réponse d'Evgeny avec quelques autres exemples.

Ce que vous entendez par taille de construction peut avoir un peu d'importance:

• s'il s'agit de la taille des artefacts en cours de construction (chacun individuellement ou leur taille combinée) - cela pourrait avoir une importance dans le stockage des artefacts ou les opérations d'utilisation / de déploiement si ces opérations ont des limites de taille et qu'elles sont dépassées. Par exemple, les applications Google App Engine ont de telles limites de déploiement , si les déploiements atteints échouent, voir Erreur lors du déploiement sur Google App Engine .

• s'il s'agit de la taille de l'espace de travail dans lequel vous effectuez la génération, cela peut être important du point de vue de la gestion de l'espace de travail. Même la 2G peut être importante - par exemple si vous construisez un système de fichiers RAM sur une machine avec peu de RAM. Mais certaines versions pourraient être beaucoup plus grandes - j'ai dû gérer des espaces de travail de 500 G + (lorsque la plupart de mes disques de serveur étaient inférieurs à 1 T).

Si la construction fait partie de votre pipeline CI / CD, plus la taille de construction est grande, plus le temps d'exécution du pipeline sera long (exécution de la construction réelle et, le cas échéant, archivage, déploiement pour les tests, analyse en cas d'échec, nettoyage, etc.) - plus votre développement global peut être lent / risqué / coûteux.

Si vous atteignez une limite stricte, vous devrez faire preuve de créativité pour contourner ce problème (pas toujours simple / possible). Si ce n'est qu'un problème de performance / coût, vous avez également la possibilité d'accepter et de vivre avec et / ou de l'aborder partiellement / progressivement.

Il peut être utile de distinguer entre:

• constructions gonflées - lorsque la taille est augmentée inutilement - la résolution du problème est généralement possible en supprimant les pièces inutiles
• les cas dans lesquels le contenu de la construction lui-même est ce qui est vraiment nécessaire - la taille n'a pas autant d'importance - elle est nécessaire, la seule façon d'y remédier peut être de sacrifier certaines fonctionnalités

J'ajouterai un problème très concret que nous rencontrons en fait. C'est un effet secondaire d'une mauvaise architecture dont nous souffrons actuellement:

Comme notre build est volumineux et que nous devons charger un grand nombre de dépendances, le simple fait de tout assembler prend beaucoup de temps. Nous aurions dû depuis longtemps diviser le build-up en de nombreux petits builds comme une approche d'une architecture de microservice au lieu d'un grand monolithe.

L'exécution de tous les tests pour le monolithe prend environ 45 minutes et bloque notre environnement CI pour le moment.

Puisqu'il est si intensif en charge et prend tellement de temps, il nous est actuellement impossible d'exécuter plusieurs versions parallèlement les unes aux autres.

Ainsi, comme les affiches avant moi l'ont déjà déclaré à un niveau plus théorique, cela devrait présenter certaines implications secondaires potentielles (et probables) qu'une grande construction a généralement en dehors du besoin de plus d'espace sur le disque dur.