Binarios en control de fuente

Al desarrollar dispositivos embebidos y otros mundos extraños, es muy probable que su proceso de compilación incluya múltiples binarios patentados, utilizando versiones muy específicas de ellos. Entonces la pregunta es, ¿son parte de su control de fuente? Mis oficinas siguen la regla de "retirar del control de fuente incluye todo lo que necesita para compilar el código" y esto ha llevado a algunos argumentos serios.

Los principales argumentos que veo en contra de esto son la hinchazón del DB de control de fuente, la falta de archivos binarios diferentes ( ver preguntas anteriores sobre el tema) . Esto va en contra de la capacidad de verificar, construir, sabiendo que tiene el entorno preciso que el desarrollador anterior pretendía y sin buscar los archivos apropiados (¡con versiones específicas, nada menos!)

La idea del CONTROL DE VERSIÓN (nombre inapropiado: control de fuente) es permitirle retroceder en el historial, recuperar el efecto de los cambios, ver los cambios y por qué se hicieron. Este es un rango de requisitos, algunos de los cuales necesitan cosas binarias, otros no.

Ejemplo: para el trabajo de firmware integrado, normalmente tendrá una cadena de herramientas completa: un compilador propietario que cuesta mucho dinero o alguna versión de gcc. Para obtener el ejecutable de envío, necesita la cadena de herramientas y la fuente.

Verificar las cadenas de herramientas en el control de versiones es una molestia, las utilidades de diferencia son horribles (si es que lo hacen), pero no hay alternativa. Si desea preservar la cadena de herramientas para el tipo que viene a ver su código dentro de 5 años para descubrir lo que hace, entonces no tiene otra opción: también DEBE tener la cadena de herramientas bajo control de versiones.

A lo largo de los años, he descubierto que el método más simple para hacer esto es hacer una imagen ZIP o ISO del CD de instalación y verificar esto. El comentario de registro debe ser el número de versión de los fabricantes específicos de la cadena de herramientas. Si es gcc o similar, agrupa todo lo que estás usando en un gran ZIP y haz lo mismo.

El caso más extremo que he hecho es Windows XP Embedded, donde la "cadena de herramientas" es una VM Windows XP en ejecución, que incluía (en ese entonces) SQL Server y una pila de archivos de configuración junto con cientos y cientos de archivos de parche. Instalar todo el lote y actualizarlo solía llevar unos 2-3 días. Preservar eso para la posteridad significaba registrar TODA la VM en el control de versiones. Al ver que el disco virtual estaba compuesto por unas imágenes de 6 x 2 GB, en realidad funcionó bastante bien. Suena exagerado, pero hizo la vida muy fácil para la persona que vino después de mí y tuvo que usarlo, 5 años después.

Resumen: el control de versiones es una herramienta. Úselo para ser efectivo, no se obsesione con cosas como el significado de las palabras y no lo llame "control de fuente" porque es más grande que eso.

Neal Ford argumenta en The Productive Programmer que debe mantener los binarios en el control de la fuente:

¿Por qué mantener binarios? Los proyectos actuales dependen de una serie de herramientas y bibliotecas externas. Digamos que está utilizando uno de los marcos de registro populares (como Log4J o Log4Net). Si no compila los archivos binarios para esa biblioteca de registro como parte de su proceso de compilación, debe mantenerlo en el control de versiones. Eso le permite continuar construyendo su software incluso si el marco o la biblioteca en cuestión desaparece (o, más probablemente, introduce un cambio importante en una nueva versión). Mantenga siempre todo el universo requerido para construir su software en control de versiones(menos el sistema operativo, e incluso eso es posible con la virtualización; consulte "Uso de la virtualización", más adelante en este capítulo). Puede optimizar la retención de binarios manteniéndolos en el control de versiones y en una unidad de red compartida. De esa manera, no tiene que lidiar con ellos cada hora, pero se guardan en caso de que necesite reconstruir algo un año después. Nunca se sabe si necesitará reconstruir algo. Lo construyes hasta que funciona, luego olvídalo. Es inductor de pánico darse cuenta de que necesita reconstruir algo de hace dos años y no tiene todas las piezas.

No podría estar mas de acuerdo; Si bien esto podría estar subvirtiendo el VCS para una tarea para la que no fue diseñado (mantener binarios), creo que los beneficios superan los posibles inconvenientes. Pero, como el autor señala más adelante, a veces mantener los binarios en VCS podría no ser una solución práctica, por lo que se deben considerar otras opciones, como mantenerlas en una unidad de red asignada.

Si los binarios no son demasiado grandes, definitivamente los mantendría en VCS. Esto parece ser aún más cierto en su caso, ya que los binarios son probablemente pequeños, y usted trabaja con versiones muy específicas. También pueden ser difíciles de encontrar, debido a una variedad de razones (los autores cerraron su sitio web, o la versión que necesita ya no figura en la lista para descargar). Aunque es poco probable, nunca se sabe lo que sucederá en unos años.

Me gustaría leer este libro hace unos años, cuando estaba trabajando en un juego usando una biblioteca de gráficos (que era un archivo dll); Interrumpí el desarrollo por un tiempo, y cuando quise continuar no pude encontrar el dll nuevamente porque el proyecto murió.

En principio, agradezco el campo "verifique todo lo que necesita para construir en el control de código fuente", pero la administración de dependencias ha evolucionado bastante en los últimos años, con herramientas como Maven, Ivy y NuGet.

Además, en la práctica, encuentro el registro de binarios para crear una serie de efectos secundarios desagradables. Git / Mercurial no está realmente ajustado para ello, por ejemplo, y Subversion y Perforce pueden volverte loco al fusionar ramas que contienen binarios.

Con una solución de administración de dependencias, usted especifica en un archivo controlado por fuente en su proyecto de qué nombres de paquetes y de qué versiones depende su proyecto. Casi todas las herramientas de administración de dependencias le permiten crear un repositorio privado de sus dependencias, siguiendo algún tipo de convención de versiones y nombres; cuando realiza una compilación, la herramienta de administración de dependencias resolverá todas sus dependencias de código abierto y de propiedad de una lista de fuentes aprobadas, luego las guardará en su caché local. La próxima vez que construya con las mismas dependencias de versión, todo ya estará allí y será mucho más rápido.

Su repositorio privado puede ser respaldado con herramientas de respaldo de sistema de archivos convencionales.

Esto evita las ralentizaciones que he experimentado cuando se extraen un montón de binarios del árbol de origen y evita que su repositorio tenga muchos archivos difíciles de diferenciar. Solo hay una ubicación para cada dependencia, por nombre y número de versión, por lo que no hay conflictos de fusión con los que lidiar, y el almacenamiento en caché del sistema de archivos local significa que no tiene que lidiar con el costo de evaluar si su copia local ha cambiado cuando Usted saca actualizaciones.

El control de la fuente es para las fuentes. Las fuentes son lo que no puedes construir a partir de otras cosas. Algunos archivos que califican como fuentes resultan ser binarios.

Mi VCS tiene muchos binarios registrados, pero cada uno es la unidad de lanzamiento de algún producto que no escribí y que no mantengo. Esto podría ser algo como GNU ccRTP, que se lanza como un tarball comprimido. Ese tarball es mi fuente, y se registra junto con cualquier infraestructura que necesite para convertirlo en un producto terminado (un Makefile y una especificación RPM en mi caso) en un solo paso automatizado. Cuando hay una nueva versión de ccRTP, trato el nuevo tarball como fuente modificada: entra en una copia desprotegida, se construye, se prueba y se devuelve al VCS. He hecho lo mismo con productos comerciales que no se envían con fuente (compiladores, bibliotecas, etc.) y funciona de la misma manera. En lugar de unpack-configure-compile-package, es solo unpack-package. El software que hace las compilaciones nocturnas nomake y obtener productos terminados.

La mayoría de los VCS tienen características que hacen que la fuente legible para humanos sea más fácil de tratar y más eficiente de almacenar, pero decir que no son adecuados para los archivos binarios no es realmente cierto si los archivos binarios vuelven a ser molestados. La forma en que un VCS trata con los archivos binarios depende internamente de si sus autores pensaron que valía la pena intentar almacenar solo las diferencias. Personalmente, creo que almacenar copias completas de una distribución de ccRTP a 600K por pop está más que compensada por la capacidad de etiquetar una versión junto con todas mis otras fuentes.

Esto me recuerda el problema de los "frascos en el repositorio" que Java tenía hace algún tiempo. Las personas que construían aplicaciones Java se usaban para insertar sus dependencias (archivos jar binarios) en repositorios. Todos estaban contentos con esto, porque tendríamos un sistema de compilación de "un clic" y el espacio en disco es barato, así que a quién le importa. Luego vino Maven y podría deshacerse de todo ese binary cruft y con el repositorio local solo de caché aún mantener las construcciones de bala-prof. Aún tiene el sistema de compilación de "un clic", pero el control de código fuente no tiene que barajar los archivos binarios que no tienen sentido allí.

Entonces, sí, puede obtener archivos binarios fuera del control de origen, pero esto requerirá que modifique el sistema de compilación, para obtenerlos en el momento de la compilación. Sin un software dedicado (como Maven), esto podría ser un gran esfuerzo para sacarlos.

Su control de fuente mantiene las fuentes de lo que hace. Si un blob binario determinado puede reconstruirse a partir de las fuentes, no es una fuente y no debe ir al repositorio de código fuente. Solo los blobs no recreables deberían hacerlo en el control de origen.

Por lo general, tiene otra carpeta de red de repositorio de blobs binarios que ha creado a través del tiempo de las fuentes. Estos pueden implementarse en los clientes o usarse en proyectos (en lugar de construir todo desde cero todo el tiempo).

Entonces, ponlo si es una fuente. No, si no.

El objetivo es poder obtener el último código y compilarlo sin tener que instalar / configurar nada (por lo tanto, una compilación de "un solo clic").

En muchos lugares en los que he estado, eso significa registrar binarios de dependencias. En otros, esto significa que los scripts de compilación descargan y obtienen las dependencias automáticamente.

Vea esta publicación de blog de Derek Greer sobre el tema.

Estoy trabajando en un proyecto con dos etapas de construcción diferentes.

• la "compilación del programa principal" necesita solo unos pocos archivos binarios, en comparación con los miles de archivos de texto de código fuente, por lo que los archivos binarios se registran en el repositorio. Esto funciona bien

• la compilación del instalador necesita muchos componentes de terceros (algunos de ellos simplemente se copian en el CD de instalación, como Adobe Reader). No los estamos poniendo en el repositorio. En cambio, esos componentes residen en una unidad de red (incluso versiones anteriores de ellos), y los scripts de compilación los copian en el lugar correcto. Por supuesto, para tener compilaciones reproducibles, cualquiera debe tener cuidado de no cambiar ninguna carpeta donde se almacenan los componentes de terceros.

Ambas estrategias funcionan bien y cumplen con el requisito de "verificar desde el control de origen que incluye todo lo que necesita para compilar el código".

Debe conservar todo lo necesario para reconstruir versiones específicas del producto en algún momento en el futuro.

Sin embargo, no tiene que mantener todo en Control de código fuente.

Una compañía mantuvo un rack de servidores congelado (porque el sistema operativo solo se ejecutaba en ese hardware específico, y la cadena de herramientas solo se ejecutaba en ese sistema operativo, y la fuente dependía de esa cadena de herramientas). No se puede verificar eso en el control de origen.

Si necesita dividir los requisitos para una compilación, entonces tiene el problema contable de mantener sincronizados dos sistemas de control de versiones. por ejemplo, la caja de hardware en este armario, o la máquina virtual o los archivos binarios en este volumen de copia de seguridad conservado, vaya con esta revisión de código fuente SVN, etc. Esto es más complicado que usar un solo sistema de control de fuente, pero solucionable.

En mi mente, es muy caótico registrar binarios en SCM. Había ejecutado un proyecto muy complejo, que tiene muchas dependencias con bibliotecas de terceros. Los principios que adoptamos:

1. Todo el código fuente se gestiona con SCM
2. Todas las dependencias se gestionan con Ivy, que tiene una gran integración de eclipse.

Esto funciona bastante bien. Tenemos un archivo de configuración sobre la versión de cada biblioteca externa con la que se puede compilar el código fuente. Este archivo de configuración se registra en SCM, por lo que evoluciona a medida que evoluciona el código fuente. Al aplicar este enfoque, podemos reproducir exactamente una compilación sin alterar la versión de las bibliotecas externas.

Personalmente, filosóficamente, me inclino a permitir que el control de origen verifique los punteros a los archivos binarios grandes (los recursos binarios pequeños están bien), y no el contenido del archivo. Este puntero contendría un hash del contenido del archivo binario.

El archivo binario en sí no sería administrado por el control de origen. Se almacenaría en algún tipo de biblioteca donde se puede recuperar utilizando el puntero, o el hash específicamente.

Git LFS y git annex hacen eso, pero también intentan administrar los archivos binarios hasta cierto punto, no quiero que lo hagan. Quiero que Git almacene sumas de verificación solamente y que me diga si mis archivos binarios han cambiado o no, pero no quiero que intente administrarlos y almacenarlos. Quiero hacer esto yo mismo.

Creo que git puede manejar archivos binarios pequeños y medianos, pero no estoy seguro de que sea la herramienta adecuada para administrar archivos binarios grandes.