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

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).

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)

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.

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).

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.

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.

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.