¿Se debe almacenar CSS minificado en Git?

10

Uso Gulp para generar CSS minificado a partir de mi código SASS para un proyecto en el que estoy trabajando.

Me preguntaba si se considera la mejor práctica para regenerar este CSS minimizado cuando se empuja en vivo desde Git ...

o

¿Para almacenar los archivos CSS minificados en Git para que se envíen automáticamente a producción sin más trabajo por parte del servidor?

Agradecería las ideas de la gente sobre esto. ¡Gracias!

version-control git css deployment Connor Gurney
fuente
Solo hay un lugar css / js / etc minimizado. deben almacenarse: /dev/null.
R .. GitHub DEJA DE AYUDAR AL HIELO
(Eso se debe a que su servidor web es perfectamente capaz de utilizar el transporte comprimido).
R .. GitHub DEJE DE AYUDAR A HIELO el
Almacenar CSS comprimido y sin comprimir significa que ahora tiene dos versiones de lo mismo. ¿Cuál es la versión canónica? Es fácil imaginar el escenario en el que un desarrollador actualiza el CSS comprimido y otro actualiza el CSS sin comprimir. Sus dos activos ahora han divergido. Por supuesto, el proceso debería evitar esto, pero es una perspectiva realista con, por ejemplo, un nuevo desarrollador en el equipo.
Qwerky

Respuestas:

13

"Depende." Para el seguimiento normal del desarrollo, no. Sin embargo, para implementaciones en la nube y DevOps, a menudo es conveniente o incluso necesario.

La mayoría de las veces, @ptyx es correcto . De hecho, su "no" podría expresarse de manera algo más enfática. Algo así como "No. ¡No! ¡ OMG NO! "

¿Por qué no almacenar activos minificados o comprimidos en un sistema de control de código fuente como Git?

  1. Pueden ser regenerados casi trivialmente por su proceso de compilación sobre la marcha desde el código fuente. Almacenar activos comprimidos es básicamente almacenar el mismo contenido lógico dos veces. Viola el principio de "no te repitas" (también conocido como DRY ).

  2. Una razón menos filosófica pero más práctica es que los activos minificados / optimizados tienen una compresibilidad muy pobre cuando se almacenan en Git. Los sistemas de control de código fuente reconocen los cambios ("deltas") entre diferentes versiones de cada archivo almacenado. Para hacer eso, "difunden" el último archivo con la versión anterior, y usan estos deltas para evitar almacenar una copia completa de cada versión del archivo. Pero las transformaciones realizadas en el paso de minificar / optimizar a menudo eliminan las similitudes y puntos de referencia que utilizan los algoritmos diff / delta . El ejemplo más trivial es eliminar saltos de línea y otros espacios en blanco; El activo resultante es a menudo solo una larga línea. Muchas partes del proceso de compilación web: herramientas como Babel , UglifyJS , Browserify ,Less y Sass / SCSS : transforman activos de forma agresiva. Su producción es perturbable; pequeños cambios de entrada pueden conducir a cambios importantes en la salida. Como resultado, el algoritmo diff a menudo creerá que ve un archivo casi completamente diferente cada vez. Sus repositorios crecerán más rápidamente como resultado. Sus discos pueden ser lo suficientemente grandes y sus redes lo suficientemente rápidas como para no ser una gran preocupación, especialmente si existiera un valor para almacenar los activos minimizados / optimizados dos veces, aunque según el punto 1, las copias adicionales pueden ser solo 100% inútiles inflar.

Sin embargo, hay una gran excepción a esto: DevOps / implementaciones en la nube. Varios proveedores de nube y equipos de DevOps usan Git y similares no solo para rastrear actualizaciones de desarrollo, sino también para implementar activamente sus aplicaciones y activos en servidores de prueba y producción. En este rol, la capacidad de Git para determinar eficientemente "¿qué archivos cambiaron?" es tan importante como su capacidad más granular para determinar "¿qué cambió dentro de cada archivo?" Si Git tiene que hacer una copia de archivo casi completa para los activos minimizados / optimizados, eso lleva un poco más de tiempo de lo contrario, pero no es gran cosa ya que todavía está haciendo un excelente trabajo ayudando a evitar una copia de "cada archivo en el proyecto" en cada desplegar ciclo.

Si está utilizando Git como motor de implementación, el almacenamiento de activos minimizados / optimizados en Git puede cambiar de "¡no!" a deseable. De hecho, puede ser necesario, por ejemplo, si carece de oportunidades sólidas de compilación / posprocesamiento en los servidores / servicios en los que implementa. (La forma de segmentar los activos de desarrollo e implementación en ese caso es una lata separada de gusanos. Por ahora, es suficiente saber que se puede administrar de varias maneras, incluso con un único repositorio unificado, múltiples sucursales, subrepositorios o incluso múltiples repositorios superpuestos. )

Jonathan Eunice
fuente
1
¡Gracias por esto! Muy apreciado. En cambio, he marcado esto como la respuesta, ya que parece mucho mejor explicado.
Connor Gurney
1
git no almacena solo deltas. SVN lo hace, pero git usa un mecanismo mucho más complejo para almacenar archivos. Algunas personas te dicen que almacena una copia completa de cada archivo, pero por lo que entiendo, esto también es incorrecto. No intentaré entrar en lo que hace, ya que yo tampoco lo tengo completamente claro.
jpmc26
Creo que podría lograr el matiz simplemente cambiando "y almacenar solo los nuevos deltas" en algo similar a ", y usar estos deltas para evitar almacenar una copia completa de cada versión del archivo". Eso haría su punto de vista, sería fácticamente correcto y evitaría profundizar en el tema de cómo se hace para cualquier sistema de control de fuente dado.
jpmc26
¿Podría DevOps simplemente usar git hooks para activar automáticamente la minificación en el servidor implementado, obteniendo lo mejor de ambos mundos?
Buttle Butkus
@ButtleButkus Depende del servidor implementado. Para depender de los ganchos de publicación, debe 1 / asumir que los transpiladores, minificadores y optimizadores apropiados están presentes en el objetivo, o 2 / cargarlos antes de ejecutar los ganchos de publicación. 1 / es incierto. 2 / impone un costo de carga / latencia en cada implementación. También presenta nuevos modos de falla posibles y un requisito para depurar los ganchos de publicación en un entorno remoto, opaco y transitorio. No es ideal. Entonces los ganchos no son una bala de plata. La conversión previa / optimización de activos puede ser poco elegante, pero es robusta y pragmática.
Jonathan Eunice el
17

No.

El control de fuente solo debe contener la fuente. Si se genera desde la fuente, no pertenece allí, y debería ser generado por su proceso de compilación.

La razón fundamental por la que no desea controlar el origen de los artefactos de compilación intermedios es que si lo hace, es muy difícil confiar en si lo que está ejecutando proviene de la fuente que acaba de modificar o de un producto intermedio que no pudo reconstruir .

ptyx
fuente
3
Piense en el código generado de la misma manera que piensa en el código ejecutable.
candied_orange
3
Este principio no siempre es cierto. Si tiene archivos que se generan con herramientas pesadas que no puede esperar que tenga un usuario, puede tener sentido poner los archivos generados en git. Muchas personas incluso ponen configurescripts generados de autoconf en git por este motivo.
R .. GitHub DEJA DE AYUDAR AL HIELO
@R ..: Idealmente, mantienes un repositorio de artefactos separado para esas cosas, pero la realidad rara vez es ideal.
Kevin
@R puedes comprometerte, pero es solo eso. Y en el caso de la minificación CSS, no creo que las herramientas califiquen como 'pesadas' o 'lentas' o 'inconvenientes'. Además, existen mecanismos alternativos de inyección de dependencia (maven, hiedra ...) que funcionan bien y no requieren que coloque el código generado en su control de origen.
ptyx
1
@ButtleButkus No tengo mucha experiencia en el caso de devops. Lo que he visto es git usado como un mecanismo de transporte / liberación / implementación (muy conveniente y flexible), en lugar de simplemente como control de fuente. A menos que el git de 'fuente' y el git de 'entrega' estén separados (repositorios separados o ramas separadas), esto significa que debe comprometer un poco la cadena fuente-> compilación-> entregable, por ejemplo, terminará con producción que tiene código fuente y ramas adicionales por ahí, y desarrollo con productos binarios no utilizados. Es un compromiso pragmático, pero prefiero separar las preocupaciones cuando puedo.
ptyx