¿Depender del código fuente o del binario?

7

Tenemos dos proyectos internos, A y B, desarrollados por diferentes equipos con B que dependen de A. Como el código fuente para ambos proyectos se almacena en git, he incluido el proyecto A como un submódulo en el proyecto B y lo he configurado. El sistema de compilación para construir tanto 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 las ventajas y desventajas de depender del código fuente y de los artefactos binarios. ¿Cuándo es mejor uno 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 tiene 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 examinar 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 compilación de otro proyecto
pregunta mkalkov 09.07.2014 - 08:32

2 respuestas

5

Siempre recomendaría dependencias binarias sobre dependencias de origen. La mayoría de las ventajas que enumera para el código fuente también se pueden incorporar fácilmente a las 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 deberían implementar versiones -SNAPSHOT en el artefacto. Puede haber una distinción agradable y clara entre las versiones, como:

  • projectA-3.2.0-SNAPSHOT : desarrollo activo, puede cambiar en cualquier momento
  • projectA-3.2.0-RC1 : candidato a lanzamiento
  • projectA-3.2.0 : lanzamiento de producción

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

Para los parches, git es tu amigo. Bifurque el repositorio y coloque un número de versión de parche, como projectA-3.2.1-FOR_PROJ_B . Observe que .1 muestra una versión de parche y también el descriptor. Esto también facilitará que el proyecto retorne esos cambios al maestro más adelante.

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

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

    
respondido por el metacubed 09.07.2014 - 09:44
1

Iría por la dependencia binaria, porque casi ninguna de sus consideraciones que me favorecen 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 pueden escribir las personas a cargo para decidir qué uso de la versión.

  • si necesita depender de la versión preliminar de otro proyecto: ya está cubierto por metacubos. Ya sea con el código fuente o las dependencias binarias, debe atenerse a una versión bien establecida, incluso si es una versión preliminar. Por supuesto, cuando se desarrolla contra una versión preliminar, es probable 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 explorar el código fuente de dependencia en el IDE: no debería necesitar entrometerse en el funcionamiento interno de sus dependencias, ya que esto 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.
respondido por el SJuan76 09.07.2014 - 10:27

Lea otras preguntas en las etiquetas