¿Es una buena práctica almacenar tiempos de ejecución de framework bajo control de fuente?

9

Sé que muchas tiendas de software mantienen los archivos binarios bajo control de fuente . Sin embargo, nuestra tienda había venido a almacenar frameworks completos en el repositorio: DirectX runtime, CUDA, nVidia Optix, lo que sea.

Se dice que facilita la configuración de una máquina de desarrollo (supuestamente, obtenga la última versión y comience a codificar). Sin embargo, hincha considerablemente el repositorio y lo carga con una historia irrelevante.

Nunca he visto tal patrón de uso. ¿Lo consideras una buena práctica?

[EDITAR:] No tengo ningún problema con el control de origen de binarios de terceros aislados. La pregunta se refiere a tiempos de ejecución de framework completos, que generalmente consisten en más de 10 binarios. Como ejemplo extremo, tome el SDK de Windows (que no guardamos en el repositorio, gracias a Dios, pero no veo diferencias en principio).

Ofek Shilon
fuente
1
Puede crear un script que descargue los tiempos de ejecución de framework más recientes o relevantes, y poner ese script bajo control de versión.
Basile Starynkevitch
2
¿Por qué crees que carga [el repositorio] con una historia irrelevante ? Más específicamente, ¿por qué crees que la historia es irrelevante ? Si su código hace referencia a esos marcos y bibliotecas, es muy útil saber qué versiones se estaban utilizando en una revisión particular en el repositorio.
James McNellis
Estoy de acuerdo con la hinchazón (especialmente si esos tiempos de ejecución se comparten entre múltiples proyectos) pero no entiendo la parte sobre la historia irrelevante. Un cambio, por ejemplo, en qué versión de un tiempo de ejecución que está utilizando es bastante relevante ...
6502
¿No sería más fácil crear imágenes de la máquina del desarrollador a medida que salgan las actualizaciones?
Ramhound
@Ramhound: esa es la dirección exacta que estoy tratando de empujar. Me preguntaba si hay inconvenientes que me estoy perdiendo.
Ofek Shilon el

Respuestas:

6

Los binarios generalmente no son adecuados para el sistema de control de versiones porque:

  • no se benefician de las funciones de control de versiones (fusionar, diff)
  • aumentan el tamaño del repositorio ...
  • ... lo que importa porque no eliminas fácilmente una versión de un VCS (los VCS están hechos para mantener el historial), a diferencia de los repositorios de artefactos como Nexus , que son directorios compartidos simples (fáciles de limpiar: cd+ rm!)
  • deben ser referenciados en un VCS como un texto , una declaración de ruta + versión: puede mantener el historial relevante de esa manera , registrando cualquier cambio de versión binaria como un cambio en ese archivo de texto (como un pom.xml si está utilizando Nexus por ejemplo)
VonC
fuente
1
El último punto es muy valioso.
Noufal Ibrahim
¡Gracias! ¿Conoces un repositorio de artefactos similar para proyectos de C ++? Aún mejor, ¿tal vez uno que se integre con TFS?
Ofek Shilon
2
@OfekShilon: Nexus puede en teoría almacenar cualquier tipo de artefacto. Pero para el almacenamiento y la gestión de dependencias para .NET / C ++, también tiene NuGet: nuget.codeplex.com . Ejemplo para .Net: lostechies.com/derekgreer/2011/09/20/… . También debería ser compatible con proyectos C ++: nuget.codeplex.com/discussions/280649 .
VonC
@OfekShilon Puede vincular TFS con NuGet (por ejemplo: coolthingoftheday.blogspot.com/2011/08/… , hanselman.com/blog/… ). Ver también TFSNuGetter: nugetter.codeplex.com
VonC
6

Estoy de acuerdo con la versión que controla los activos binarios. Estoy en contra de la versión que controla los archivos generados .

Además, la configuración del entorno es algo diferente del desarrollo. Desarrollamos principalmente en Python y tiene una herramienta llamada virtualenv que le permite crear un entorno aislado liviano (incluidas las bibliotecas) para un proyecto. Cuando revisamos nuestras fuentes, tenemos un script de configuración que crea este virtualenv. Usando un manifiesto, esto especifica qué versiones de bibliotecas son necesarias y otras cosas similares. Nada de esto está controlado por la versión. Solo el script de configuración es.

Lanzar todo el marco bajo su proyecto principal desordenará su historial y ensuciará seriamente las cosas. No es parte de su proyecto y debe tratarse de manera diferente.

Noufal Ibrahim
fuente
3

En general, es una buena idea hacer la gestión de la configuración con versiones de framework. Si su código necesita una versión específica de DirectX, esa versión debería estar fácilmente disponible, y si revisa una versión anterior de su software, debería ser fácil determinar qué dependencias externas tiene.

Lo que no creo que sea una buena idea aquí es usar su típico sistema de control de versiones para almacenar esos archivos binarios. En nuestra empresa, almacenamos todas las versiones de frameworks, bibliotecas y herramientas externas en una estructura de subcarpetas en una unidad de red. Cuando creemos que tiene sentido, tenemos archivos Léame para documentar qué versión de herramienta pertenece a qué versión de software o, si es posible, tenemos scripts para instalar o usar una versión específica. Solo esos archivos y scripts readme van al control de versiones.

También mantenemos versiones anteriores de herramientas y bibliotecas siempre que pensemos que existe la posibilidad de que debamos reconstruir y versiones anteriores dependiendo de esas herramientas. De esa forma, nos da la posibilidad de eliminar algunas de las antiguas bibliotecas y herramientas de nuestra unidad de red cuando quedaron obsoletas (por supuesto, en caso de que tengamos archivos en medios externos).

Doc Brown
fuente
2

Creo que los binarios deberían ser tiendas en algún lugar. Sugeriría almacenarlos fuera de un repositorio, especialmente si son grandes y conducen a tiempos de salida grandes. No voy a ver que es una mala práctica, pero tampoco es una que haya visto.

Esto puede ser una buena idea si su organización tiene muchos proyectos que apuntan a diferentes versiones de tiempo de ejecución. Asegura que tiene el binario de tiempo de ejecución correcto cuando trabaja en los proyectos correctos.


fuente
He aclarado la pregunta para abordar esto.
Ofek Shilon
1

Personalmente considero que esta es una muy mala práctica. Prefiero configurar un wiki con instrucciones de instalación y cargar los binarios necesarios. Estos archivos solo son necesarios para los nuevos desarrolladores, no hay necesidad de aumentar los repositorios de todos los demás.

Sergio Tulentsev
fuente
1

Hay una buena razón para hacerlo, es decir, que tiene todo lo que necesita en una única ubicación, sin dependencias externas.

Esto es mucho más importante de lo que piensas. Básicamente, garantiza que no confíe en un artefacto en un servidor de proveedor que puede desaparecer después de unos años, ya que tiene todo en la empresa.

En cuanto a la hinchazón del repositorio. Esto es solo un problema si su VCS mantiene una copia local completa (git hace esto, cvs no) ya que la clonación y / o actualización será lenta. A cambio, tendrá copias en cada máquina de desarrollo, lo que puede salvar a su empresa si su esquema de respaldo central por alguna razón falla algún día.

Es una cuestión de prioridad o política. Mientras la decisión sea deliberada, estaría bien con esto.


fuente
2
Si almacena su biblioteca de terceros en un repositorio de artefactos como su propio servidor Nexus o NuGet, no tendrá que temer que un servidor "vendedor" desaparezca. Entonces, por supuesto, almacénelos localmente. Simplemente no use un VCS. No están destinados a mantener ese tipo de archivo.
VonC
@VonC depende de su infraestructura y metodología de trabajo. Para "simplemente almacenar un solo binario una vez", un VCS puede ser tan bueno como un repositorio completo de artefactos. También mantiene la infraestructura simple. No estoy abogando: el OP preguntó si alguien había visto ese patrón de uso.
Okay. He visto tal patrón de uso. Y tuve que administrar tales repositorios (Centralice VCS como SVN o ClearCase principalmente, nunca vi ese uso para DVCS como Git). Y esto es generalmente un desastre. Al considerar las bibliotecas de proveedores, rara vez se almacena un solo binario una vez. Tienes que lidiar con parches. Muchos de ellos. Además, el almacenamiento no es el único objetivo (si lo fuera, VCS podría ser una posible solución). La gestión de dependencias es. Y eso es lo que ofrece Nexus o NuGet (además de un almacenamiento fácil de administrar y limpiar).
VonC