¿Las bibliotecas en las que se basa la aplicación deben almacenarse 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 depende de un par de funciones de ella (aunque en gran medida). ¿Debería almacenar el jar / dll o tal vez incluso el zip / tar distribuido del proyecto?
¿Qué hacen otras personas?
Respuestas:
Además de tener bibliotecas de terceros en su repositorio, vale la pena hacerlo de tal manera que sea fácil rastrear y fusionar en futuras actualizaciones de la biblioteca fácilmente (por ejemplo, correcciones de seguridad, etc.). Si está utilizando Subversion, vale la pena utilizar una rama de proveedor adecuada .
Si sabe que sería un día frío en el infierno antes de que modifique el código de su tercero, entonces (como dijo @Matt Sheppard) un externo tiene sentido y le brinda el beneficio adicional de que se vuelve 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 los externos al actualizar la base de su código y guardar en el largo proceso de carga lenta si lo necesita.
@Stu Thompson menciona el almacenamiento de documentación, etc. en el control de fuente. En proyectos más grandes, he almacenado toda nuestra carpeta de "clientes" en el control de fuente, incluidas facturas / facturas / actas de reuniones / especificaciones técnicas, etc. Todo el partido de rodaje. Aunque, ejem, recuerde almacenarlos en un repositorio SEPARADO del que pondrá a disposición de: otros desarrolladores; el cliente; su "vista de la fuente del navegador" ... tos ... :)
almacenar todo lo que necesitará para construir el proyecto dentro de 10 años. Almaceno la distribución zip completa de cualquier biblioteca, por si acaso
Editar para 2017: esta respuesta no envejeció bien :-). Si todavía está usando algo antiguo como hormiga o hacer, lo anterior todavía se aplica. Si usa algo más moderno como maven o graddle (o Nuget en .net por ejemplo), con administración de dependencias, debería estar ejecutando 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 gestión de dependencias, consulte, por ejemplo, Sonatype Nexus o JFrog Artifcatory , entre muchos otros.
No almacene las bibliotecas; estrictamente hablando, no son parte de su proyecto e inútilmente ocupan espacio en su sistema de control de revisiones. Sin embargo, use maven (o Ivy para compilaciones de hormigas) para realizar un seguimiento de las versiones de bibliotecas externas que usa su proyecto. Debe ejecutar un espejo del repositorio dentro de su organización (que está respaldado) para asegurarse de tener siempre las dependencias bajo su control. Esto debería brindarle lo mejor de ambos mundos; frascos externos fuera de su proyecto, pero aún disponibles de manera confiable y accesibles de forma centralizada.
nunca almacene sus binarios de terceros en el control de código fuente. Los sistemas de control de fuente son plataformas que admiten el intercambio simultáneo de archivos, el trabajo en paralelo, los esfuerzos de fusión y el historial de cambios. El control de código fuente no es un sitio FTP para binarios. Los ensamblajes de terceros NO son código fuente; cambian tal vez dos veces por SDLC. El deseo de poder limpiar su espacio de trabajo, extraer todo desde el control de fuente y la compilación no significa que los ensamblajes de terceros deban estar atrapados en el control de fuente. Puede usar scripts de compilación para controlar la extracción de ensamblajes 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, también puede controlarlo a través de scripts de compilación. La gente ha mencionado Maven para Java, y puede hacer algo similar con MSBuild para .Net.
Generalmente los guardo en el repositorio, pero simpatizo con su deseo de reducir el tamaño.
Si no los almacena en el repositorio, es absolutamente necesario archivarlos y versionarlos de alguna manera, y su sistema de compilación debe saber cómo obtenerlos. Mucha gente en el mundo Java parece usar Maven para buscar dependencias automáticamente, pero yo no lo he usado, así que no puedo recomendarlo ni a favor ni 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, sugeriría mantener un servidor FTP anónimo interno (o similar) del que su sistema de compilación pueda obtener los requisitos automáticamente. Obviamente, querrá asegurarse de mantener todas las versiones antiguas de las bibliotecas y tener una copia de seguridad de todo lo que hay allí junto con su repositorio.
Lo que tengo es un repositorio de intranet similar a Maven donde se almacenan todas las bibliotecas de terceros (no solo las bibliotecas, sino su respectiva distribución de origen con documentación, Javadoc y todo). Las razones son las siguientes:
Puse todo excepto el JDK y el IDE en el 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 las wikis, solía almacenar nuestra documentación en el control de fuente.
Mi preferencia es almacenar bibliotecas de terceros en un repositorio de dependencias ( Artifactory con Maven, por ejemplo) en lugar de mantenerlas en Subversion.
Dado que las bibliotecas de terceros no se administran ni se versionan 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 desde cualquier número de repositorios públicos.
En un empleador anterior, almacenamos todo lo necesario para construir la (s) aplicación (es) en el control de fuente. Poner en marcha una nueva máquina de compilación era cuestión de sincronizar con el control de fuente e instalar el software necesario.
Almacene bibliotecas de terceros en el control de fuente para que estén disponibles si revisa su código en un nuevo entorno de desarrollo. Cualquier comando de compilación o "incluye" que pueda tener en los scripts de compilación también debe hacer referencia a estas copias "locales".
Además de garantizar que el código o las bibliotecas de terceros de los que depende estén siempre disponibles para usted, también debería significar que el código está (casi) listo para compilarse en una PC nueva o en una cuenta de usuario cuando 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 bibliotecas externas, querrá actualizar / verificar las versiones más nuevas de estas bibliotecas. De esa manera, podrá obtener la versión correcta para una instantánea anterior si tiene que parchear una versión anterior, etc.
Personalmente, tengo una carpeta de dependencias como parte de mis proyectos y almaceno bibliotecas de referencia allí.
Encuentro que esto hace la vida más fácil ya que trabajo en varios proyectos diferentes, a menudo con partes interdependientes que necesitan la misma versión de una biblioteca, lo que significa que no siempre es posible actualizar a la última versión de una biblioteca determinada.
Tener todas las dependencias utilizadas en el tiempo de compilación para cada proyecto significa que unos años después, cuando las cosas hayan avanzado, todavía 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 los componentes relacionados, no demasiado difícil de administrar si es necesario.
Habiendo dicho eso, encuentro que la mayoría de las bibliotecas a las que hago referencia son relativamente pequeñas y pesan alrededor de unos cientos de kb, rara vez más grandes, lo que hace que sea un problema menor para mí colocarlas en el control de fuente.
Use subproyectos de git y haga referencia al repositorio principal de git 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 que esté limitado a un solo repositorio de git, y no le recomiendo que use el proyecto de otra persona como simplemente un directorio en el suyo.
almacene todo lo que necesita para construir el proyecto, para que pueda verificarlo y construirlo sin hacer nada.
(y, como alguien que ha experimentado el dolor, guarde una copia de todo lo necesario para instalar los controles y que funcionen en una plataforma de desarrollo. Una vez obtuve un proyecto que podía compilarse, pero sin un archivo de instalación y claves de registro, no podría no realice ninguna alteración en el diseño de control de terceros. Fue una reescritura divertida)
Tienes que almacenar todo lo que necesitas para poder construir el proyecto. Además, diferentes versiones de su código pueden tener diferentes dependencias de terceros. Querrá bifurcar su código en la versión de mantenimiento junto con sus dependencias de terceros ...
Personalmente, lo que he hecho y hasta ahora me han gustado los resultados es almacenar bibliotecas en un repositorio separado y luego vincularlas a cada biblioteca que necesito en mis otros repositorios mediante el uso de la función svn: externals de Subversion. Esto funciona bien porque puedo mantener copias versionadas de la mayoría de nuestras bibliotecas (principalmente ensamblados .NET administrados) en control de fuente sin que aumenten el tamaño de nuestro repositorio principal de código fuente. Tener los ensamblados 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 lograr que una compilación tenga éxito en ausencia de Visual Studio fue una tarea ardua, pero ahora que lo hicimos funcionar, estamos contentos con él.
Tenga en cuenta que actualmente no usamos muchas suites de control comerciales de terceros o ese tipo de cosas, por lo 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 eso fácilmente podría convertirse en un problema. Desafortunadamente, no tengo una solución para eso y planeo abordarlo cuando lo encuentre por primera vez.