Perché la dimensione della costruzione è così preoccupante?

Spesso sento (dalle persone, ma anche dalle CLI informative) che "la dimensione di costruzione / lumaca è grande". Ciò è particolarmente vero quando la build ha una dimensione compresa tra 0,5 e 2 GB

Perché (o in quali circostanze) la dimensione della costruzione è così preoccupante?

Nota: il motivo per cui lo chiedo è perché vedo risorse come l'archiviazione e il calcolo come relativamente economiche rispetto al passato, quindi, semmai, mi aspetto che la dimensione della build sia meno problematica ora che in passato

Quando sollevo un problema relativo alle dimensioni della build, di solito non proviene da "è così grande, sarà costoso memorizzarlo".

I problemi principali con build di grandi dimensioni sono i seguenti:

• tempo di spedizione aumentato. spostare pezzi di grandi dimensioni da un posto all'altro richiede molto tempo.
• frequenti modifiche a grandi artefatti e un ampio periodo di conservazione della spesa rendono l'archiviazione di tali artefatti costosa, tanto meno con artefatti a strati come le immagini docker.
• la creazione di artefatti così grandi di solito richiede tempo, più che la creazione di artefatti molto più piccoli. l'automazione del processo per creare artefatti più piccoli potrebbe richiedere del tempo, ma l'automazione ripetibile dovrebbe essere il più breve possibile per consentire un feedback rapido.
• il ripristino da un errore (a seconda della configurazione) potrebbe richiedere più tempo con artefatti più grandi, specialmente quando è necessario riapplicare un artefatto più vecchio anziché uno nuovo difettoso.

Mi iscrivo alle quattro metriche devops:

• Tempi di consegna per le modifiche: abbrevialo
• Frequenza di distribuzione: aumenta la frequenza
• Tempo di ripristinare il servizio: abbreviarlo
• Cambia tasso di fallimento - riducilo a mai

Gli artefatti di grandi dimensioni di solito creano un problema in ciascuna di queste metriche, e nessuna di queste metriche è realmente interessata dal costo di archiviazione, perché è economico, il tempo è costoso.

Completando la risposta di Evgeny con qualche altro esempio.

Quello che intendi per dimensione della build può avere un po 'di importanza:

• se è la dimensione degli artefatti in costruzione (ciascuno individualmente o la loro dimensione combinata) - ciò potrebbe importare nella memorizzazione degli artefatti o nelle operazioni di utilizzo / distribuzione se tali operazioni hanno limiti di dimensione e vengono superate. Ad esempio, le app di Google App Engine hanno tali limiti di distribuzione , se le distribuzioni raggiunte falliscono, vedi Errore durante la distribuzione su Google App Engine .

• se è la dimensione dell'area di lavoro in cui si esegue la compilazione, può importare dal punto di vista della gestione dell'area di lavoro. Anche il 2G può essere significativo, ad esempio se stai costruendo in un filesystem RAM su una macchina con poca RAM. Ma alcune build potrebbero essere molto più grandi: ho dovuto occuparmi di spazi di lavoro 500G + (quando la maggior parte dei dischi del mio server erano inferiori a 1T).

Se la build fa parte della pipeline CI / CD, maggiore è la dimensione della build, maggiore sarà il tempo di esecuzione della pipeline (esecuzione della build effettiva e, se applicabile, archiviazione, distribuzione per test, analisi in caso di errore, pulizia, ecc.) - più lento / rischioso / costoso può essere lo sviluppo complessivo.

Se raggiungi un limite rigido, dovrai essere creativo per aggirare il problema (non sempre semplice / possibile). Se si tratta solo di un risultato in termini di prestazioni / costi, hai anche la possibilità di accettarlo e conviverci e / o affrontarlo parzialmente / gradualmente.

Potrebbe essere utile distinguere tra:

• build gonfiate - quando le dimensioni sono inutilmente aumentate - in genere è possibile risolvere il problema facendo cadere parti non necessarie
• i casi in cui il contenuto della build stessa è ciò che è veramente necessario - le dimensioni non contano tanto - è necessario, l'unico modo per affrontare potrebbe essere sacrificando alcune funzionalità

Aggiungerò un problema molto concreto in cui ci imbattiamo davvero. È un effetto collaterale della cattiva architettura che stiamo soffrendo attualmente:

Poiché la nostra build è di grandi dimensioni e dobbiamo caricare molte dipendenze, il semplice assemblaggio richiede molto tempo. Avremmo dovuto da tempo dividere la costruzione in numerose piccole build come approccio a un'architettura a microservizi anziché a un grande monolito.

L'esecuzione di tutti i test per il monolito richiede circa 45 minuti e blocca il nostro ambiente CI per il momento.

Dal momento che è così carico e richiede così tanto tempo attualmente non è possibile eseguire più build parallele tra loro.

Quindi, come hanno già affermato i poster prima di me a un livello più teorico, questo dovrebbe mostrare alcune potenziali (e probabili) implicazioni secondarie che una grande costruzione di solito ha al di fuori del bisogno di più spazio sul disco rigido.