version control - usados - ¿Cómo almacena bibliotecas de terceros en su control de código fuente?
sistemas de control de versiones mas usados (15)
¿Cómo almacena las bibliotecas de terceros que utiliza en su proyecto en el control de origen?
Como binario o fuente o ambos. Depende de la biblioteca.
¿Cuándo almacenarías binarios en tu control de código fuente?
Una biblioteca de terceros para la cual no tenemos la fuente o una biblioteca interna a la que no hemos hecho ningún cambio o la biblioteca es demasiado grande para ser construida alrededor.
¿Cuándo almacenarías el código en tu control de código fuente?
Por ejemplo, utilizamos una biblioteca interna A, pero hemos corregido algunos errores específicos del producto X. Luego, el depósito del producto X conservará la fuente y la compilará.
¿Alguna vez almacenarías ambos? ¿En qué situaciones harías esto?
Sí, todos los últimos binarios se almacenan en control de código fuente.
Así el árbol se ve así:
producto
|-- src
|-- build
|-- lib
|- 3rdparty
|- internal
...
¿Cómo almacena las bibliotecas de terceros que utiliza en su proyecto en el control de origen?
¿Cuándo almacenarías binarios en tu control de código fuente?
¿Cuándo almacenarías el código en tu control de código fuente?
¿Alguna vez almacenarías ambos? ¿En qué situaciones harías esto?
(Por cierto, estoy usando .NET pero realmente no importa para esta pregunta)
Conceptualmente, debe almacenar al menos los archivos binarios (y los encabezados si hace C / C ++). Esta suele ser la única forma de obtener bibliotecas de terceros en las que no tiene la fuente.
Si tiene la fuente, puede optar por almacenar la fuente y construir las bibliotecas de terceros en su proceso de compilación.
Debería poder instalar un sistema operativo nuevo, obtener sus fuentes desde el control de fuente, crearlas y ejecutarlas. Así que sí, deberías ponerlos en control de código fuente.
Depende de lo grandes que sean. Cuando los binarios o los instaladores son demasiado grandes, puede causar estragos en los usuarios remotos. La ventaja de almacenar binarios e instaladores es que todo lo que un desarrollador necesita para comenzar a trabajar está en el control de código fuente y las versiones son correctas. Si tiene una ubicación de instalación separada, las versiones se pueden desordenar. Entonces, en general me gusta almacenar binarios pequeños o moderados en el control de código fuente, pero los más grandes los dejo fuera.
Edit: Ah, y llamo al mío "BinRef" :)
El control de fuente se denomina control de "fuente", porque se supone que controla las fuentes.
En Java es un patrón común usar algún sistema de control de versiones para almacenar fuentes y otros recursos como archivos o imágenes XML de configuración, y usar una herramienta de administración de dependencias como Apache Maven, que almacenará, descargará y administrará las dependencias de su proyecto en bibliotecas de terceros. . Luego, cuando reinstale su sistema operativo, Maven puede descargar automáticamente sus dependencias desde el repositorio central (o también sus propios repositorios privados) y almacenarlos en un caché local en su disco. Ni siquiera tienes que saber dónde está el caché :)
Maven también se puede usar con otros idiomas y, por lo que sé, los complementos para .net y C / C ++ están disponibles, pero no lo he usado con nada más que Java.
En el código fuente y las bibliotecas compiladas (lo más probable es que sean independientes):
Si no uso los componentes de terceros (bibliotecas compiladas) o la fuente provista para crear componentes de software internos, simplemente los saco del estante e los instalo según lo prescrito (que podría incluir un código comp / pl, sql, por ejemplo). No los instalaría en un repositorio de administración de dependencias ni en ningún sistema de control de fuente por la sencilla razón de que no quiero que se incorporen accidentalmente o de otra manera en los componentes que estoy creando y no quiero rastrearlos en ningún ciclo de software. Este es un activo (activo de software) que debe ser seguido con otras herramientas. Si no los uso para el desarrollo de software, no los veo y no debería verlos en las herramientas que uso para el desarrollo de software.
Si dependiera de ellos para construir mi propio software, los almacenaría durante todo el día.
En términos generales, haría más o menos lo que me han recetado otros usuarios.
En el caso de Subversion, y admito que no puedo hablar sobre la inclusión de la función en el caso de otros sistemas, se puede usar un enlace externo en un repositorio mantenido en otro lugar. En un proceso de pago / exportación, obtendrá una copia completa de la fuente, incluido el código actualizado de ese repositorio externo, todo de una vez.
Esto fue particularmente bueno para mí con el desarrollo de PHP / JS, ya que no hay ningún problema con respecto al almacenamiento de binarios. Mantendría un externo de Zend Framework, Doctrine ORM y jQuery en una carpeta / lib / del proyecto. Cada actualización me proporcionaría una copia completa y actualizada de todos los archivos necesarios sin más trabajo que agregar la URL del repositorio a una propiedad svn.
En un proyecto reciente de Java, cambié a usar Maven; fue bastante bueno ya que significaba que no necesitaba almacenar ningún archivo de terceros en un directorio lib /. En el momento de la compilación, Maven tiraría de las dependencias. Un efecto positivo es que los frascos tienen el número de versión en su nombre de archivo.
Mi experiencia ha sido crear una carpeta "lib" y mantener todos los binarios de terceros allí. Crearé un árbol totalmente separado para el Código fuente para estos terceros si está disponible.
Algunos lugares donde esto podría ser diferente es si está utilizando un código abierto frente a un tercero minorista minorista, con soluciones de código abierto que tiendo a incluir el código en mis proyectos y no a los binarios.
No es necesario que almacene bibliotecas de terceros en su repositorio de control de origen. Esas bibliotecas (piense en SDL, libcurl, etc.) siempre deben estar disponibles en la web.
Sólo dos raccomandations:
- asegúrese de indicar claramente en su código la versión de la biblioteca con la que debe compilar
- Asegúrese de que esa versión específica siempre esté disponible en la web.
No pongo fuentes de terceros o binarios en SC. Mi razonamiento fue que no tendría que actualizar SC solo para actualizar las bibliotecas. Estoy empezando a lamentar esto sin embargo. Cuando he tenido que recrear el proyecto, me encuentro corriendo buscando fuentes de lib en lugar de solo sincronizar con SC.
Si está utilizando git (que recomiendo), y tiene la fuente de la biblioteca de terceros, entonces almacenar la biblioteca en su propio repositorio de git e incluirla como un submódulo es una excelente configuración.
Si la biblioteca de origen también utiliza git, puede clonar su biblioteca y enviarla a su propio servidor para que nunca la pierda.
Los submódulos de Git le permiten especificar qué revisión de una biblioteca se requiere para un proyecto, lo cual es excelente para mantener la compatibilidad.
Suponiendo que está utilizando .Net:
Creo una carpeta "Bibliotecas" en mi proyecto y control de código fuente que contiene ensamblajes de terceros.
Mi solución luego hace referencia a esos ensamblajes y mi proceso de compilación arrastra esa carpeta a nuestro servidor de compilación.
Cualquiera que extraiga su código del control de código fuente debería poder compilarlo sin tener que buscar referencias y ensamblajes.
¿Cuándo almacenarías binarios en tu control de código fuente?
Almaceno binarios en el control de código fuente cuando quiero que puedan volver rápidamente a la versión anterior de una aplicación. Hay varias razones por las que haría esto, que incluyen lo siguiente:
- Las pruebas de aplicación en un entorno que coincide exactamente con la producción no siempre es posible.
- Es posible que el programador anterior no haya usado el control de código fuente o que lo haya usado incorrectamente. Por lo tanto, puede ser difícil asegurarse de que el código fuente que está cambiando sea la versión que coincida con lo que el usuario está trabajando.
Cómo: una sucursal de proveedor es generalmente un buen enfoque
Cuándo (terceros) : para minimizar el número de referenciales involucrados: puede agregar esas bibliotecas a un referencial externo separado (como Maven), pero eso significa que necesita acceder a ese referencial adicional para cada uno de sus entornos (desarrollo - integración - homologación - preproducción - producción)
Cuándo (código) : para administrar la complejidad de los cambios, cuando sepa que se necesitarán actualizaciones y correcciones para las versiones actuales que se ejecutan en producción mientras se está desarrollando un nuevo desarrollo.
Por qué (almacenar ambos) : por el motivo de la deployment : puede administrar una configuración completa (lista de elementos que necesita) en un referencial y consultarla donde y cuando lo necesite para:
- desarrollo (usted consulta lo que necesita para desarrollar y ejecutar su código, incluidos los terceros necesarios para la compilación / ejecución)
- pruebas (integración, homologación): consulta las etiquetas de los extractos con los que desea actualizar su área de trabajo de prueba
- producción: identifica exactamente lo que entra en producción de una fuente: su SCM.
Para entornos de prueba y producción, eso también significa que su propio producto (el resultado empaquetado de lo que está construyendo) también debe incluirse en su SCM (solo los lanzamientos oficiales, no los intermedios utilizados internamente).
Si otros proyectos dependen de su producto, construirán su propio proyecto contra su versión empaquetada almacenada en el SCM, no contra su código fuente que de alguna manera recompilaron.
¿Por qué esto es importante?
Porque al final, lo que se ejecutará en producción es esa versión empaquetada de su producto, no su "código fuente compilado nuevamente". De ahí la importancia de realizar todas las pruebas con la forma final de destino de su producto, claramente almacenadas y etiquetadas en su SCM.
Martin Lazar plantea un punto legítimo en su respuesta.
El control de fuente se denomina control de "fuente", porque se supone que controla las fuentes.
Si bien eso puede haber sido históricamente cierto, cada RCS actual ha evolucionado hacia SCM ( Source Code Management ), que no solo controla las fuentes, sino que también administra los cambios en los documentos, programas y otra información almacenada como archivos de computadora.
Los binarios se pueden almacenar (incluso almacenados con binary-delta)
Además, permite que algunos de esos SCM propongan la función S "C" M (como en Source Configuration Management ).
Ese SCM (Configuración) no solo almacena cualquier tipo de "conjunto de archivos", sino también sus relaciones (también conocidas como dependencias ) entre esos conjuntos, para que pueda consultar un conjunto de archivos y "extraer" todas las demás entregas en las que ese conjunto depende de (construir, desplegar o ejecutar)