¿Depender del código fuente o del binario?

Tenemos dos proyectos internos, A y B, desarrollados por diferentes equipos con B dependiente de A. Dado que el código fuente de ambos proyectos se almacena en git, he incluido el proyecto A como un submódulo en el proyecto B y configuré el sistema de compilación para construir ambos en el orden correcto. Una solución alternativa sería consumir A a través de un administrador de repositorio binario como Artifactory o Nexus.

Me pregunto sobre los pros y los contras de depender del código fuente en comparación con los artefactos binarios. ¿Cuándo es uno mejor que el otro? Hasta ahora logré encontrar los siguientes factores, pero estoy realmente interesado en escuchar otras opiniones.

Dependiendo del código fuente es mejor

• si no tienes un administrador de repositorio binario
• si necesita depender de la versión preliminar de otro proyecto
• si necesita parchear otro proyecto
• porque es más fácil navegar por el código fuente de dependencia en IDE

Dependiendo de los binarios es mejor

• para minimizar el tiempo de construcción
• para evitar la molestia de configurar el entorno de construcción de otro proyecto

Siempre recomendaría dependencias binarias sobre dependencias de origen. La mayoría de los profesionales que enumera para el código fuente también se pueden incorporar fácilmente en dependencias binarias.

Primero, es muy rápido configurar un repositorio Nexus en algún servidor local. Los beneficios de tener un repositorio binario superan con creces el esfuerzo / costo de configuración. Esto es casi un requisito previo para el resto de mi respuesta :)

Para las versiones preliminares, sus proyectos deben implementar versiones -SNAPSHOT en el artefacto. Puede haber una distinción agradable y clara entre versiones, como:

• projectA-3.2.0-SNAPSHOT : Desarrollo activo, puede cambiar en cualquier momento
• projectA-3.2.0-RC1 : Candidato candidato
• projectA-3.2.0 : Lanzamiento de la producción

Todas estas versiones se pueden almacenar juntas en su artefacto. Sus proyectos sabrán exactamente contra qué están compilando.

Para parches, gites tu amigo. Bifurca el repositorio y pon un número de versión de parche, como projectA-3.2.1-FOR_PROJ_B. Observe que .1 muestra un lanzamiento de parche y también el descriptor. Esto también facilitará que el proyecto regrese esos cambios al maestro más adelante.

Para el código fuente, puede configurar su herramienta de compilación para generar un "archivo fuente" e implementarlo junto con el archivo binario en el artefacto. La mayoría de los IDE pueden buscar el nombre del jar de origen y descargarlo automáticamente.

Otra gran razón para mantenerse alejado del código fuente es que está vinculado al sistema de compilación, la cadena de herramientas y las dependencias de tiempo de compilación del Proyecto A. Si ve una falla de compilación en el Proyecto B, primero debe investigar si el Proyecto A o El proyecto B causó un error. Si fue el Proyecto A, debe localizar a las personas de ese proyecto para corregir su construcción. Esto agrega mucha sobrecarga a su ciclo de construcción.

Iría por la dependencia binaria, porque casi ninguna de sus consideraciones a favor de mí es sin crítica:

• si no tiene un administrador de repositorio binario: está bien, pero no creo que sea tan difícil establecer uno. En el nivel más básico, una carpeta compartida donde solo los responsables de decidir qué versión usar pueden escribir.

• si necesita depender de la versión preliminar de otro proyecto: metacubed ya lo cubrió. Ya sea con código fuente o dependencias binarias, debe apegarse a una versión bien establecida, incluso si es una versión preliminar. Por supuesto, cuando se desarrolla contra una versión preliminar, lo más probable es que necesite cambiar a una versión actualizada a menudo debido a la resolución de errores.

• si necesita parchear otro proyecto: ¿quiere decir que su equipo va a parchear el proyecto hecho por otro equipo en la misma casa? Yo diría que la estrategia más sensata es decirle al otro equipo los problemas que tiene con su proyecto.

• porque es más fácil navegar por el código fuente de la dependencia en IDE: no debería necesitar espiar el funcionamiento interno de sus dependencias, porque significará:

  • el proyecto A está mal documentado
  • sus codificadores terminarán usando "características no documentadas" del proyecto A que pueden desaparecer sin previo aviso en cualquier actualización.