Malas prácticas: Binarios en Repositorios de Fuentes.

¿Por qué nos empeñamos controlar archivos binarios con un repositorio orientado específicamente para fuentes?

Hasta un tonto como yo sabe que hacer esto es una salvajada que puede causar todo tipo de problemas. Los más graves:

  1. Como haya varios proyectos que tiren de los mismos binarios vamos a cagar verdaderos ladrillos cada vez que toquemos algo. Consecuencia: el equipo desarrolla un miedo espantoso a tocar los binarios.
    Nada de actualizar ni de cambiar, ¡que se nos hunde la empresa como esto lo pasemos a de 1.2. a 2.0! Lamentable.
  2. Olvídate de la gestión automática de dependencias.
  3. Acaba transformándose en una pocilga infecta monolítica, una especie de tutti frutti del que van a acabar dependiendo todas y cada una de las aplicaciones de tu empresa. Una especie de ServiceLocator de binarios. Y ya sabéis lo que opino de ServiceLocator…
  4. La ruta relativa donde metas todos los binarios te va a provocar no pocos quebraderos de cabeza. Como muevas un proyecto de sitio va todo a tomar puer.
  5. Añadir referencias a pelote es un verdadero coñazo.

En resumen: FRAGILIDAD

En mi experiencia personal trabajando con Visual Studio la solución es clara:

¡¡usa NuGet, COPÓN BENDITO!! Que hasta viene integrado en el propio IDE con ventanicas, consola, iconos negrillos y toda clase de comodidades.

“NU GET”. Desde luego su nombre no es muy bonito y nos recuerda a cierto producto habitualmente de pollo rebozado.

¿Por qué cuesta tanto trabajo poner a punto un repositorio de binarios? Pero si es que hasta yo sé ponerlo, ¡incluso he creado paquetes de NuGet sin tener ni zorra!

A día de hoy todavía me encuentro gente que mira NuGet como si fuera una un invento de la abuela Tomasa que viene con Visual Studio de chiripa y que solamente utilizan esos punks que publican código en GitHub. Pues no, leches, es ni más ni menos que el gestor de paquetes OFICIAL de Microsoft para Visual Studio. Y si estás desarrollando en Visual Studio, cuya ventana principal ser un entorno de desarrollo integrado (de ahí que sea un IDE) sé por lo menos coherente y ¡úsalo! No esperes que te salgan cartelitos de neón o voces eróticas estilo Avast cuando añades una referencia a mano diciéndote que lo uses. Uno de los deberes de un desarrollador es conocer lo mejor posible sus herramientas.

Solamente se me ocurren 2 razones para no usar un repositorio de binarios:

a) por desconocimiento de las herramientas.

b) o por pasotismo, que es casi peor.

Así es que, ¿a qué estáis esperando? ¿a que os lo cuente un javero y os adelante por la derecha con Maven?

Ese listón bien alto, me kagunnn, ¡arriba .NET!

3 pensamientos en “Malas prácticas: Binarios en Repositorios de Fuentes.

  1. Hola,

    No entiendo parte de tus argumentos en contra de guardar dependencias en el control de código fuente.

    Que las almacenes en el VCS no quiere decir que las compartas entre proyectos (cada uno puede tener su propia copia) ni que renuncies a un gestor de dependencias (Nuget o lo que más te guste). Lo único que implica almacenarlas en el VCS es que tienes una copia “propia” de esas dependencias.

    El principal argumento que se puede esgrimir en contra de almacenarlas es que incrementa el tamaño del repositorio (algo importante si vas andar clonando repositorios a través de internet), pero a cambio a la hora de poder compilar tu aplicación no dependes de nada más que de tu propio repositorio “canónico”, así que puedes compilar aunque esté caído npm.org o nuget.org.

    Personalmente almaceno todas las dependencias, ya sean binarias o no, junto con el código fuente del proyecto. La idea es que si alguien tiene acceso a mi servidor de código fuente (que está en mi red local), pueda compilar el proyecto sin depender de servicios externos.

    No sé como será en otro tipo de negocios, pero si yo necesito sacar una versión nueva de mi aplicación o recuperar el tag de la versión 3.1.76 porque necesito hacer un hotfix, no quiero tener que depender de que la versión concreta del paquete que estaba usando siga disponible, un servicio externo esté levantado y mi conexión a internet funcione. Es verdad que los servidores suelen funcionar e internet no se suele caer, pero no veo necesidad de asumir ese riesgo que no me aporta nada.

    Por supuesto, ese es mi escenario. Entiendo que si vas a tener que clonar repositorios a través de internet continuamente, con binarios grandes (que además son malos para guardar deltas y consumen más espacio y, por tanto, más ancho de banda), puedan primar otros factores.

    Un saludo,

    Juanma.

  2. Pingback: El lado oscuro de los gestores de paquetes | Koalite

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s