¿Qué tan lejos tomas el control de versiones?

Question

La teoría de que el "disco" es barato se ha salido un poco de control últimamente. Hay algunos aspectos poderosos del control de versiones que nos han permitido incorporar nuevos desarrolladores con algunos archivos de arranque y un comando simple para tirar de la cadena de herramientas.

Recientemente, las actualizaciones de los sistemas han provocado solicitudes para almacenar binarios construidos. A esto siguió una solicitud para versionar todo el sistema de compilación virtualizado. Cada capa añadida en la parte superior crea relaciones importantes entre repositorios y es necesario un buen diseño fundamental para gestionarla.

El almacenamiento de la cadena de herramientas trajo beneficio instantáneo mientras que el almacenamiento de los binarios construidos pasa a ser responsabilidad instantánea. Git, lamentablemente, tiene algunos problemas fundamentales cuando se trata de grandes archivos binarios.

¿Dónde dibuja las líneas para usar VC de la manera correcta y cuándo comienza a investigar soluciones más apropiadas?

Answer 1

Probablemente no deba almacenar el "sistema completo de construcción virtualizada" como un binario gigante. Si desea versionar su aplicación, debe versionar el código fuente, no el binario compilado.

Lo que muchas tiendas hacen es almacenar en control de versión los pasos para recrear el servidor de compilación. Luego necesita una imagen fija (una instalación estándar y lista para usar del sistema operativo), además de una pequeña cantidad de archivos (qué instalar en él y cómo). Algunos lugares incluso tienen su servidor reconstruir la aplicación desde el origen, en una instalación limpia del sistema operativo, para cada implementación/reinicio.

La versión de la imagen del sistema operativo en sí misma como un binario gigante no es tan útil. No puedes ramificar. No puedes fusionarte. No puedes dif. ¿Cuál es el punto de? Puede ahorrar espacio si su VCS puede hacer diferencias binarias, pero eso probablemente requiera una tonelada de CPU y memoria, y si están en un "disco es barato", entonces no hay razón para que la vida sea dolorosa solo para ahorrar Espacio del disco.

Almacene sus scripts/bibliotecas de instalación en VC y reconstruya la imagen de VM según sea necesario, o simplemente almacene imágenes de VM en archivos normales. No veo ningún sentido al poner las imágenes en VCS.

Answer 2

Yo diría que hay una orden de operaciones aquí:

Si necesitan para almacenar archivos, utilice un sistema de archivos.

Si necesitan realizar un seguimiento de los cambios, use el control de versión.

Si necesitan rastrear las relaciones con los datos, use una base de datos.

Cuanto más complicados sean los requisitos, más complicada será la solución. Pero la disciplina está en orden para aquellos que quieren la solución más complicada; en estos tiempos de incertidumbre uno debe evitar perder el tiempo.

Answer 3

Me atengo a la clásica respuesta de almacenar todo lo que se necesita para construir el producto final. Los archivos binarios y los archivos intermedios no son necesarios, pero se incluyen los scripts que se utilizan en la compilación.

Utilizo mis repositorios git como copias de seguridad, almacenando clones desnudos en al menos dos lugares, así que trato de no dejar nada que sea necesario para una compilación, pero no me molesto en almacenar nada transitorio.

Answer 4

Control de versiones que no se puede volver a crear sin él. Por lo tanto, la cadena de herramientas no se puede recrear fácilmente; hay sentido en la versión que lo controla. Con la cadena de herramientas (y el código fuente) bajo control de versión, no hay necesidad de archivar los productos de compilación, o al menos, no después de que se completen las pruebas de compilación.

Answer 5

El sentido común, en lugar de la irritabilidad de TI, debe guiar la forma de controlar y configurar su cadena de herramientas. Si tiene hardware estándar y a menudo está agregando desarrolladores, almacenar su cadena de herramientas construida como imágenes tiene sentido; pero las imágenes no tienen que estar bajo control de versión. Si tiene 50 desarrolladores, un sistema de gestión de configuración para su cadena de herramientas reducirá los gastos generales; si tienes 5 desarrolladores, es más sobrecarga, otro sistema para aprender.

Entonces, ¿se está metiendo Git en el camino de lo que quiere hacer? ¿O está recibiendo solicitudes porque los usuarios están tratando de decir que debe hacer que su sistema sea más complicado porque podría hacerlo?

Si sus herramientas de compilación están maduras, entonces la fecha de compilación puede ser suficiente para determinar las versiones de las herramientas que se utilizaron. Puede hacer que su encuesta de script de compilación escriba un archivo de texto de sus herramientas de compilación y sus versiones, similar a una lista de dependencias.

Si está utilizando herramientas internas que cambian rápidamente, o versiones alfa/beta de proyectos en desarrollo activo, entonces habría una buena razón para poner las herramientas de compilación bajo control de versiones, pero sería resolver el problema incorrecto. problema. ¿Por qué construirías con una herramienta inestable?

Answer 6

Para una aproximación bastante extrema echa un vistazo Vesta.

De Allan Heydon, Roy Levin, Timothy Mann, Yuan Yu. The Vesta Approach to Software Configuration Management:

El enfoque Vesta se basa en los siguientes fundamentos:

• inmutable, inmortal, almacenamiento versionado de todas las fuentes y herramientas. A diferencia de ClearCASE, Vesta utiliza números de versión explícitos en lugar de vistas.

• Descripciones completas de la configuración basada en el origen. Por completo, nos referimos a que las descripciones nombran todos los elementos que contribuyen a una construcción. Cada aspecto del entorno informático, incluidas herramientas, bibliotecas, archivos de encabezado, y variables de entorno, está completamente descrito y controlado por Vesta. Por basado en fuente, nos referimos a que las descripciones de configuración especifican cómo crear un sistema desde cero utilizando solo fuentes inmutables (es decir, archivos no derivados). Las descripciones en sí mismas son versiones y fuentes inmutables, y su significado es constante; una descripción particular de nivel superior siempre describe con precisión la misma compilación utilizando las mismas fuentes, incluso después de que se hayan creado nuevas versiones de las fuentes y descripciones .

• Gestión automática de archivos derivados. El almacenamiento y la denominación de los archivos derivados se gestiona automáticamente en el depósito de almacenamiento de Vesta, lo que facilita la carga de para crear múltiples versiones o crear múltiples plataformas de destino.

• Almacenamiento en caché de todo el sitio de todos los trabajos de construcción. Vesta presenta un caché compartido en el sitio de los resultados de compilación para que los desarrolladores puedan beneficiarse de las compilaciones de los demás.

• Detección automática de dependencias.El generador de Vesta detecta dinámicamente y registra todas las dependencias, por lo que ninguna puede ser omitida por error humano. Dinámicamente, nos referimos a que el constructor detecta qué fuentes se usan realmente en el proceso de construcción de un resultado de compilación y registra dependencias solo en ellas. El análisis de dependencia de Vesta no utiliza ningún conocimiento de cómo funcionan las herramientas de compilación; por lo tanto, es semántica independiente en la terminología de Gunter [7]. Por ejemplo, si un compilador lee el archivo foo.h en el proceso del archivo de compilación foo.c, Vesta asumirá que la salida del compilador depende en todos los foo.h, aunque una herramienta con conocimiento de C podría ser capaz de encuentre elementos individuales en foo.h que podrían cambiarse sin cambiar el resultado de la compilación.

Answer 7

Lo que siempre tenga el control de versión:

• código fuente y los archivos make: el mínimo necesario para generar los binarios.
• pruebas suites

Lo que nunca he puesto en el control de versiones:

• binarios construidos: pueden recrearse de control de código fuente, y si sé que puedo necesitar una versión específica de inmediato, me almacenarlos en el sistema de archivos de una manera similar al núcleo de Linux.

lo que puse en el control de versiones en función del proyecto:

• cadena de acumulación: No pongo en el control de versiones cuando confío el proveedor o cuando puedo recrear el ambiente (Xcode de Apple, herramientas de código abierto como gcc o doxygen, ...). Lo pongo en control de versiones cuando está específicamente dedicado para el proyecto (por ejemplo, una cadena de compilación cruzada hecha en casa) y cuando necesito recrear un binario exactamente como fue construido para la entrega (para encontrar heisenbugs cuando cualquier componente puede estar involucrado, desde el código para el sistema operativo o el compilador).

Answer 8

He estado usando el control de fuente para toda mi cadena de herramientas. Como se mencionó anteriormente, esto tiene grandes beneficios:

• Todos usan las mismas herramientas, por lo que nunca tenemos que preocuparnos por las incompatibilidades.
• La máquina de compilación produce los mismos artefactos que los desarrolladores.
• Siempre podemos volver a crear cualquier artefacto en cualquier punto en el futuro, porque la cadena de herramientas está completamente versionada.

Dibujé la línea en algún lugar sobre el sistema operativo; algo de lo que he presentado es:

de Windows

• SDK de la plataforma (ahora Windows SDK)
• Visual C++ Toolkit, y más tarde con licencia Visual C++, ahora el SDK de Windows incluye compiladores.

Linux

• gcc
• hacer
• glibc

Tanto

• JDK

Algunos de los problemas que he encontrado al intentar hacer esto fueron:

• En cosas como Linux y gcc Perl incrustar su directorio de instalación en sus ejecutables. Esto significa que los desarrolladores y la máquina de compilación tienen una secuencia de comandos posterior a la finalización de la sesión que se ejecutará para actualizarlos mediante un ataque directo en los archivos binarios.
• En cualquier plataforma tiene una lista de opciones de compilación mucho más larga y complicada para especificar cada cabecera y directorio de la biblioteca; ese tipo de cosas es automático con una instalación "normal". Una de esas cosas que no es obvia es que crti.o y amigos es algo que se encuentra en /usr/lib de forma predeterminada y es propiedad de glibc-devel (o libc6-dev), por lo que no está en el sistema de archivos a menos que glibc-devel esté instalado.
• Para Windows, los compiladores posteriores a 2003 usan todos los ensambles uno al lado del otro, así que para evitar un procedimiento de instalación en la máquina objetivo, tuve que desenterrarlos y colocarlos junto a los ejecutables del compilador en control de fuente.
• Windows SDK v6.1 con compiladores (y sin ayuda/muestras) es enorme: 427MB si conté bien.

he empezado a tratar de utilizar Apache Ivy (similar a Maven) para ayudar a manejar las herramientas principales, pero todavía no he visto ningún ejemplo de hiedra o Maven que se utiliza para gestionar algo que no es una aplicación Java .jar archivo. No sé si podré administrar cosas como el compilador de C.

Lo ideal es que desee una comprobación de control de fuente o resolver Ivy o Maven para tener todas las herramientas y la biblioteca en el sistema de archivos del desarrollador, listo para usar. Pero estoy empezando a pensar que requerir que el desarrollador instale un pequeño número de cosas críticas, como el SDK de Windows, o los paquetes gcc y glibc-devel no es una mala idea. Como se mencionó anteriormente, se trata de 5 o 50 desarrolladores, y el tiempo involucrado en la creación de dicha solución.