¿Por qué el tamaño de construcción es tan preocupante?

A menudo escucho (de personas, pero también de CLI informativas) que el "tamaño de compilación / slug es grande". Esto es particularmente cierto cuando la construcción tiene un tamaño de 0.5 - 2 GB

¿Por qué (o bajo qué circunstancias) es el tamaño de construcción una preocupación?

Nota: la razón por la que pregunto es porque veo que los recursos como el almacenamiento y la computación son relativamente baratos en comparación con el pasado, por lo que, en todo caso, esperaría que el tamaño de la construcción sea un problema menor ahora que en el pasado

Cuando planteo el problema del tamaño de la compilación como una preocupación, generalmente no proviene de "es tan grande que será costoso almacenarlo".

Los principales problemas con las grandes construcciones son los siguientes:

• Mayor tiempo de envío. mover pedazos grandes de un lugar a otro con frecuencia lleva mucho tiempo.
• Los cambios frecuentes en los artefactos grandes más un período de retención de enoug grande hacen que el almacenamiento de dichos artefactos se vuelva costoso, menos aún con artefactos en capas como las imágenes de la ventana acoplable.
• crear artefactos tan grandes generalmente lleva mucho tiempo, más que crear artefactos mucho más pequeños. La automatización del proceso para crear artefactos más pequeños puede llevar tiempo, pero la automatización que se puede repetir debe ser lo más breve posible para permitir una retroalimentación rápida.
• recuperarse de una falla (dependiendo de la configuración) puede tomar más tiempo con artefactos más grandes, especialmente cuando se necesita volver a aplicar un artefacto más antiguo en lugar de uno más nuevo y defectuoso.

Me suscribo a las cuatro métricas de devops:

• Tiempo de espera para cambios: acortarlo
• Frecuencia de implementación: aumente la frecuencia
• Hora de restaurar el servicio: acortarlo
• Cambiar la tasa de fallas: reducirla a nunca

Los artefactos grandes generalmente crean un problema en cada una de estas métricas, y ninguna de estas métricas está realmente preocupada por el costo de almacenamiento, porque eso es barato, el tiempo es costoso.

Complementando la respuesta de Evgeny con algunos ejemplos más.

Lo que quieres decir con tamaño de construcción puede importar un poco:

• si es el tamaño de los artefactos que se están construyendo (cada uno individualmente o su tamaño combinado), eso podría importar en el almacenamiento de artefactos o en las operaciones de uso / despliegue si esas operaciones tienen límites de tamaño y se exceden. Por ejemplo, las aplicaciones de Google App Engine tienen tales límites de implementación ; si las implementaciones alcanzadas fallaran, consulte Error al implementar en Google App Engine .

• si es el tamaño del espacio de trabajo en el que realiza la compilación, puede ser importante desde la perspectiva de gestión del espacio de trabajo. Incluso 2G ​​puede ser significativo, por ejemplo, si está construyendo en un sistema de archivos RAM en una máquina con poca RAM. Pero algunas compilaciones podrían ser mucho más grandes: tuve que lidiar con espacios de trabajo de 500G + (cuando la mayoría de los discos de mi servidor estaban por debajo de 1T).

Si la compilación es parte de su canalización de CI / CD, cuanto mayor sea el tamaño de la compilación, mayor será el tiempo de ejecución de la canalización (realizar la compilación real y, si corresponde, archivar, implementar para probar, analizar en caso de falla, limpiar, etc.): cuanto más lento / riesgoso / costoso sea su desarrollo general.

Si alcanza un límite difícil, tendrá que ser creativo para solucionarlo (no siempre es simple / posible). Si es solo un golpe de rendimiento / costo, también tiene la opción de aceptarlo y vivir con él y / o abordarlo parcial / gradualmente.

Puede ser digno de distinguir entre:

• construcciones hinchadas: cuando el tamaño se incrementa innecesariamente, la solución del problema generalmente es posible al soltar partes innecesarias
• los casos en los que el contenido de la compilación en sí es lo que realmente se necesita (el tamaño no importa tanto) es necesario, la única forma de abordarlo es sacrificando alguna funcionalidad

Agregaré un problema muy concreto con el que realmente nos encontramos. Es un efecto secundario de la mala arquitectura que estamos sufriendo actualmente:

Dado que nuestra compilación es grande y necesitamos cargar muchas dependencias, simplemente armarlo todo lleva mucho tiempo. Deberíamos haber dividido la compilación en numerosas compilaciones pequeñas como un enfoque para una arquitectura de microservicio en lugar de un monolito grande.

Ejecutar todas las pruebas para el monolito toma alrededor de 45 minutos y por el momento bloquea nuestro entorno de CI.

Dado que requiere mucha carga y lleva tanto tiempo, actualmente es imposible para nosotros ejecutar múltiples compilaciones paralelas entre sí.

Entonces, como los pósters antes que yo ya han declarado en un nivel más teórico, esto debería mostrar algunas implicaciones laterales potenciales (y probables) que una construcción grande generalmente tiene fuera de necesitar más espacio en el disco duro.