version-control - sistema - software para bibliotecas gratis en español

Almacenar bibliotecas de terceros en el control de código fuente (17)

¿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?

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 una rama adecuada 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 ... :)

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.

Almacene bibliotecas de terceros en el control de código fuente para que estén disponibles si revisa su código en un nuevo entorno de desarrollo. Cualquier "incluir" o comandos de compilación que pueda tener en las secuencias de comandos de compilación también debe hacer referencia a estas copias "locales".

Además de garantizar que el código de terceros o las bibliotecas de las que depende siempre estén disponibles, también debería significar que el código está (casi) listo para construir en una nueva PC o cuenta de usuario cuando los nuevos desarrolladores se unan al equipo.

Almacene las bibliotecas! El repositorio debe ser una instantánea de lo que se requiere para construir un proyecto en cualquier momento. Como el proyecto requiere una versión diferente de las bibliotecas externas, querrá actualizar / verificar las versiones más nuevas de estas bibliotecas. De esta forma, podrá obtener toda la versión correcta para ir con una instantánea anterior si tiene que parchar un lanzamiento anterior, etc.

En un empleador anterior almacenamos todo lo necesario para construir la (s) aplicación (es) en el control de la fuente. Hacer girar una nueva máquina de construcción era una cuestión de sincronización con el control de fuente e instalar el software necesario.

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.

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:

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

Mi preferencia es almacenar bibliotecas de terceros en un repositorio de dependencias ( Artifactory con Maven por ejemplo) en lugar de mantenerlas en Subversion.

Como las bibliotecas de terceros no se administran ni tienen versiones como el código fuente, no tiene mucho sentido mezclarlas. Los desarrolladores remotos también aprecian no tener que descargar grandes bibliotecas a través de un enlace WPN lento cuando pueden obtenerlas más fácilmente de cualquier cantidad de repositorios públicos.

No almacene las bibliotecas; no son estrictamente parte de su proyecto y ocupan inútilmente espacio en su sistema de control de revisiones. Sin embargo, utilice Maven (o Ivy 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.

Personalmente, lo que he hecho y hasta ahora me han gustado los resultados es almacenar bibliotecas en un repositorio separado y luego vincular a cada biblioteca que necesito en mis otros repositorios a través del uso de la función Subversion svn: external. Esto funciona bien porque puedo mantener copias versionadas de la mayoría de nuestras bibliotecas (principalmente ensamblados .NET administrados) en el control de código fuente sin que estas amplíen el tamaño de nuestro repositorio principal de código fuente. Tener los ensamblajes almacenados en el repositorio de esta manera hace que el servidor de compilación no tenga que tenerlos instalados para hacer una compilación. Diré que conseguir una versión para tener éxito en ausencia de la instalación de Visual Studio fue una tarea ardua, pero ahora que la hemos puesto en funcionamiento, estamos contentos con ella.

Tenga en cuenta que actualmente no utilizamos muchas suites comerciales de control de terceros o ese tipo de cosas, así que no nos hemos encontrado con problemas de licencia en los que puede ser necesario instalar un SDK en el servidor de compilación, pero puedo ver dónde podría convertirse fácilmente en un problema. Lamentablemente, no tengo una solución para eso y planeo abordarlo cuando me encuentre por primera vez.

Personalmente, tengo una carpeta de dependencias como parte de mis proyectos y bibliotecas de referencia de la tienda.

Encuentro que esto hace la vida más fácil ya que trabajo en una serie de proyectos diferentes, a menudo con partes interdependientes que necesitan la misma versión de una biblioteca, lo que significa que no siempre es factible actualizar a la última versión de una biblioteca determinada.

Tener todas las dependencias usadas en tiempo de compilación para cada proyecto significa que, dentro de unos años, cuando las cosas hayan cambiado, aún puedo construir cualquier parte de un proyecto sin preocuparme por romper otras partes. Actualizar a una nueva versión de una biblioteca es simplemente un caso de reemplazar el archivo y reconstruir componentes relacionados, no demasiado difícil de administrar si es necesario.

Una vez dicho esto, encuentro que la mayoría de las bibliotecas a las que hago referencia son relativamente pequeñas, con unos cientos de kb, rara vez más grandes, lo que hace que sea un problema para mí simplemente ponerlas en control de la fuente.

Pongo todo excepto el JDK y el IDE en control de fuente.

La filosofía de Tony es sólida. No olvide los scripts de creación de bases de datos y los scripts de actualización de la estructura de datos. Antes de que salieran los wikis, solía incluso almacenar nuestra documentación en control de fuente.

Tienes que almacenar todo lo que necesitas para construir el proyecto. Además, las diferentes versiones de su código pueden tener diferentes dependencias en terceros. Deseará ramificar su código en la versión de mantenimiento junto con sus dependencias de terceros ...

Utilice los subproyectos de git, y la referencia desde el repositorio de git principal de la biblioteca de terceros, o (si no tiene uno) cree un nuevo repositorio de git para cada biblioteca requerida. No hay ninguna razón por la cual esté limitado a un solo repositorio de git, y no le recomiendo que use el proyecto de otra persona como un simple directorio.

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, consulte, por ejemplo, Sonatype Nexus o JFrog Artifcatory , entre muchos otros.

almacene todo lo que necesitará para construir el proyecto, para que pueda verificarlo y construir sin hacer nada.

(y, como alguien que ha experimentado el dolor, conserve una copia de todo lo necesario para instalar los controles y trabajar en una plataforma de desarrollo. Una vez obtuve un proyecto que podría compilar, pero sin un archivo de instalación ni claves de registro, no podría No hagas ninguna modificación en el diseño del control de terceros. Fue una reescritura divertida.

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.