Pregunta Almacenar bibliotecas de terceros en el control de código fuente


¿Las bibliotecas de las que depende la aplicación se almacenan en el control de código fuente? Una parte de mí dice que debería y otra parte dice que no. Se siente mal agregar una biblioteca de 20 MB que empequeñece toda la aplicación solo porque dependes de un par de funciones (aunque bastante). ¿Debería simplemente almacenar el jar / dll o quizás incluso el zip / tar distribuido del proyecto?

¿Qué hacen otras personas?


74
2017-09-08 05:25


origen


Respuestas:


Además de tener bibliotecas de terceros en su repositorio, vale la pena hacerlo de tal forma que sea fácil seguir y fusionar en futuras actualizaciones de la biblioteca fácilmente (por ejemplo, soluciones de seguridad, etc.). Si está utilizando Subversion usando un rama de vendedor vale la pena

Si sabes que sería un día frío en el infierno antes de que modifiques el código de tu tercero, (como dijo @Matt Sheppard), un elemento externo tiene sentido y te da el beneficio adicional de que es muy fácil cambiar a la última versión de la biblioteca en caso de que las actualizaciones de seguridad o una nueva característica imprescindible lo hagan deseable.

Además, puede omitir las opciones externas al actualizar el ahorro de la base de códigos en el proceso de carga larga y lenta en caso de que lo necesite.

@Stu Thompson menciona el almacenamiento de documentación, etc. en el control de fuente. En proyectos más grandes, he almacenado toda la carpeta de "clientes" en el control de fuente, incluidas facturas / recibos / minutos de reuniones / especificaciones técnicas, etc. Todo el juego de disparos. Aunque, ejem, recuerda guardarlos en un repositorio SEPARADO del que estarás poniendo a disposición: otros desarrolladores; el cliente; su "vista de fuente del navegador" ... tos ... :)


25
2017-09-08 08:48



almacena todo lo que necesitarás para construir el proyecto dentro de 10 años. Guardo la distribución zip completa de cualquier biblioteca, por si acaso

Editar para 2017: Esta respuesta no envejeció bien :-). Si todavía está utilizando algo antiguo como hormiga o marca, lo anterior aún se aplica. Si utiliza algo más moderno como maven o graddle (o Nuget en .NET por ejemplo), con administración de dependencias, debe ejecutar un servidor de administración de dependencias, además de su servidor de control de versiones. Siempre que tenga buenas copias de seguridad de ambos, y su servidor de administración de dependencias no elimine las dependencias antiguas, debería estar bien. Para ver un ejemplo de un servidor de administración de dependencias, vea por ejemplo Sonatype Nexus o JFrog Artifcatory, Entre muchos otros.


45
2017-09-08 05:28



No almacene las bibliotecas; no son estrictamente parte de su proyecto y ocupan inútilmente espacio en su sistema de control de revisiones. Haz, sin embargo, uso Maven (o Hiedra para compilaciones de ant) ​​para realizar un seguimiento de las versiones de bibliotecas externas que utiliza su proyecto. Debe ejecutar un espejo del repositorio dentro de su organización (del que se realiza una copia de seguridad) para garantizar que siempre tenga las dependencias bajo su control. Esto debería darte lo mejor de ambos mundos; jarras externas fuera de su proyecto, pero aún confiablemente disponibles y centralmente accesibles.


20
2017-09-15 16:46



Almacenamos las bibliotecas en control de fuente porque queremos poder construir un proyecto simplemente revisando el código fuente y ejecutando el script de construcción. Si no puede obtener lo último y construir en un solo paso, entonces solo se encontrará con problemas más adelante.


15
2017-09-08 05:41



nunca almacene sus binarios de terceros en control de fuente. Los sistemas de control de origen son plataformas que admiten el uso compartido simultáneo de archivos, el trabajo paralelo, la fusión de esfuerzos y el cambio de historial. El control de fuente no es un sitio FTP para binarios. Las asambleas de terceros NO son código fuente; cambian tal vez dos veces por SDLC. El deseo de poder limpiar su espacio de trabajo, eliminar todo desde el control de origen y la compilación no significa que los ensamblajes de terceros deben estar atascados en el control de la fuente. Puede usar scripts de compilación para controlar la extracción de conjuntos de terceros desde un servidor de distribución. Si le preocupa controlar qué rama / versión de su aplicación utiliza un componente de terceros en particular, puede controlarlo también a través de los scripts de compilación. La gente ha mencionado Maven para Java, y puedes hacer algo similar con MSBuild para .Net.


11
2018-01-05 20:24



Generalmente los guardo en el repositorio, pero simpatizo con tu deseo de mantener el tamaño reducido.

Si no los almacena en el repositorio, es absolutamente necesario archivarlos y versionarlos de alguna manera, y su sistema de compilación necesita saber cómo obtenerlos. Mucha gente en el mundo de Java parece usar Maven para buscar dependencias automáticamente, pero no he usado I, así que no puedo recomendarlo a favor o en contra.

Una buena opción podría ser mantener un repositorio separado de sistemas de terceros. Si está en Subversion, puede usar el soporte externo de subversion para verificar automáticamente las bibliotecas del otro repositorio. De lo contrario, te sugiero que mantengas un servidor FTP anónimo interno (o similar) del que tu sistema de compilación pueda obtener requisitos automáticamente. Obviamente, querrás asegurarte de mantener todas las versiones anteriores de las bibliotecas y tener todo respaldado junto con tu repositorio.


7
2017-09-08 07:58



Lo que tengo es un repositorio intranet de Maven donde se almacenan todas las bibliotecas de terceros (no solo las bibliotecas, sino también su respectiva distribución de fuente con documentación, Javadoc y todo). La razón es la siguiente:

  1. ¿Por qué almacenar archivos que no cambian en un sistema específicamente diseñado para administrar archivos que cambian?
  2. fija dramáticamente los check-outs
  3. cada vez que veo "something.jar" almacenado bajo control de fuente, pregunto "¿y qué versión es?"

5
2017-09-15 22:01