¿Cómo mantiene los binarios publicados bajo control de versiones?

14

¿Cómo mantiene los binarios publicados bajo control de versiones? Esto permite rastrear qué cosas se cambian entre cada lanzamiento. Me refiero a separar los binarios publicados del repositorio de origen. Los binarios lanzados se crean a partir del software de integración continua o se compilan manualmente.

version-control release-management

— linquizar
fuente

¿Qué quieres decir con "rastrear qué cosas han cambiado"? ¿Qué atributos de los binarios de lanzamiento está rastreando (o quiere)? Parece extraño, así que tengo curiosidad.

— Jeremy Heiler

por ejemplo, entre v1.0.0 y v1.0.1, solo se cambia ABC.exe, mientras que la dependencia DEF.dll permanece sin cambios

— linquize

1

¿Cómo se determina esto mirando los binarios?

— Jeremy Heiler

diff versión antigua y nueva del mismo archivo

— linquize

21

Dos opciones:

a) No lo hagas. Solo asegúrese de tener compilaciones deterministas reproducibles, es decir, construir la misma revisión de control de origen con la misma configuración siempre produce exactamente el mismo binario.

b) Designe un directorio en algún lugar como la fuente autorizada para las compilaciones publicadas. Haga que la carga de los archivos binarios sea parte del procedimiento de implementación / envío y asegúrese de que el directorio de compilación publicado esté cubierto por su plan de copia de seguridad. No necesita ningún control de versión aquí; las compilaciones son de escritura única, si necesita cambiar algo, crea una nueva compilación.

De cualquier manera, los binarios y otros resultados de compilación no pertenecen al control de origen, por numerosas razones.

— tdammers
fuente

77

a) a menudo no es posible, por supuesto, blogs.msdn.com/b/ericlippert/archive/2012/05/31/…

— jk.

@jk: buen enlace. Supongo que tener el código fuente y todos los archivos de entrada para la etapa de compilación totalmente bajo control de la fuente (y tener instalada la versión correcta del compilador) puede ser "lo suficientemente determinista" en muchos escenarios del mundo real (y no lo suficiente en otros, por supuesto). ) Depende de cada caso lo importante que es tener binarios reproducibles bit por bit.

— Doc Brown

10

Utilice un repositorio de artefactos para binarios, no un sistema de control de versiones. No se supone que una versión específica de un binario lanzado cambie con el tiempo, por lo tanto, el control de la versión no tiene sentido ya que los archivos no cambiarían.

Vea, por ejemplo, los repositorios de Maven como un repositorio para archivar / publicar / ofrecer versiones y otros binarios (por ejemplo, documentación)

— mhaller
fuente

tampoco se supone que una versión específica de un archivo fuente publicado cambie con el tiempo. SCM es un buen lugar para colocar el binario enviado, solo lo almacena junto con los archivos fuente utilizados para construirlo.

— gbjbaanb

2

gbjbaanb, SCM significa "Gestión del control de origen". Eso debería dar a cualquiera una pista de que estos sistemas no están diseñados para almacenar archivos binarios sino fuente. Si aún desea almacenar binarios, continúe. No lo haré

— mhaller

44

SCM significa "Software Control Management" pero buen intento. "código fuente" es a menudo no sólo los archivos de texto, sino imágenes, documentos, diagramas, etc.

— gbjbaanb

Normalmente, "Gestión de la configuración del software". Nunca he oído hablar de "Software Control Management".

— James McLeod

7

Simplemente colóquelos. No hay problema con eso, a menos que esté usando git (que no combina bien los binarios, por lo que tendrá que administrarlos usted mismo) o los está cometiendo demasiadas veces (solo se compromete cuando es listo para enviar, no cada vez que lo construyes).

La mayoría de los binarios delta SCMs bastante bien, solíamos poner un dll de recursos de 2Mb en nuestro SVN y cada vez delta a unos pocos kb.

Escucho muchos argumentos de que los SCM son para la fuente, no para los binarios, pero esto es simplemente falso cuando se considera que la mayoría del software consiste en imágenes, incluso si son solo archivos de iconos. Son binarios, pero son parte de la fuente, así que póngalos y no sea tan dogmático al respecto. También escuché que puedes reconstruir el binario cuando sea necesario, a menudo este es el caso, pero puede ser un gran esfuerzo para perder tiempo para sistemas más antiguos que ya no son compatibles. Si tiene que volver a crear un sistema con solo service packs o parches más antiguos para que se corresponda con el sistema que se utilizó para construir un binario hace 3 años, se alegrará de haber agregado el bin a su SCM en ese momento.

El único momento en que debe preocuparse por agregar compilaciones a su SCM es si lo hace automáticamente como parte del proceso del servidor de compilación; no haga esto. Completará su SCM con compilaciones que no tienen ningún beneficio para usted. En cambio, solo agrégalos cuando se publiquen. De esta manera, usted sabe exactamente qué tiene su cliente y puede reproducir cualquier problema informado por el cliente con los archivos binarios que está utilizando, y no los que ha reconstruido (utilizando, digamos, las últimas actualizaciones del compilador o el sistema operativo).

— gbjbaanb
fuente

1

@ MarnenLaibow-Koser obviamente no ha trabajado en la industria por mucho tiempo. Los entornos de construcción cambian con el tiempo, por lo que si bien podría reconstruir uno antiguo, es probable que tenga que pasar días recreando el entorno con las herramientas y SDK antiguos adecuados. Lo cual espero que hayas versionado ...

— gbjbaanb

1

Me imagino que sería capaz de construir un viejo binario VC6 que se compiló en una máquina XP utilizando un SDK antiguo que Microsoft ya no considera adecuado lanzar. Si alguien solicita ese binario, es fácil simplemente tomarlo del mismo lugar donde se almacena todo lo demás. El costo de administrar eso es enorme en comparación con el dolor de tener que reconstruir, y el costo de almacenarlo con la fuente es insignificante. He estado allí (con una aplicación VB6 hecha con un control de terceros cuando el cliente informó un error: obtener el binario y ejecutarlo fue mucho más fácil que reconstruirlo, lo que resultó ser imposible)

— gbjbaanb

1

@gjbaanb Admitiré también que estás en una situación diferente a la mía de otra manera: todas mis dependencias externas son OSS, por lo que no pueden desaparecer solo porque alguna compañía ya no considera conveniente liberarlas.

— Marnen Laibow-Koser

1

Mi punto es que los SCM pueden almacenar todo, por lo que no hay necesidad de no almacenar el binario por separado de su fuente. Es conveniente y fácil y le garantiza que sabe lo que años después. No hay inconveniente en hacerlo. Cualquier versión en sí misma solo está sincronizada con una confirmación de fuente particular también. No veo el problema, excepto que algunas personas piensan que SCM significa solo texto de código fuente. No, úselo para almacenar casi todo (a veces, incluso herramientas de compilación o libs si no son enormes), la vida se vuelve mucho más fácil.

— gbjbaanb

1

@gjbaanb Y mi punto es que te equivocas al respecto. :) Claro, los VCS pueden almacenar todo, pero no están bien configurados para almacenar archivos que solo viven para una confirmación (después de todo, no desea que su r500 se compile en el repositorio en r550; será confuso) . El problema fundamental con el almacenamiento de artefactos de compilación en el repositorio no es que sean binarios , sino que son datos derivados y que no estarán sincronizados con su fuente en el mismo repositorio. Los mismos argumentos que estoy usando se aplicarían a los archivos de texto generados.

— Marnen Laibow-Koser

5

No mantengo los binarios de lanzamiento bajo control de versiones. En cambio, los publico en una ubicación bien definida para que otras herramientas los inspeccionen y los usen. Hago mucho trabajo en Java, lo que significa que publico Jars en repositorios locales de Maven. Sin embargo, no uso estas herramientas para rastrear lo que ha cambiado por lanzamiento. Después de todo, son binarios y realmente no hay mucho que rastrear aparte del conteo de archivos.

Para realizar un seguimiento de los cambios entre lanzamientos, etiquetaría o etiquetaría lanzamientos en mi sistema de control de versiones con el número de versión del lanzamiento. Pero esto es solo para rastrear los archivos fuente, no los binarios. Los binarios son artefactos de la compilación y no necesitan estar bajo control de versión.

— Jeremy Heiler
fuente

1

La mejor solución es hacer un uso exclusivo de su sistema CI para todas las compilaciones organizativamente significativas (lanzamientos, lanzamientos de candidatos, etc.).

Esto vincula sistemáticamente los binarios liberados al contenido del repositorio sin tener que almacenar realmente los binarios en el repositorio.

Por ejemplo, si está utilizando SVN, use el esquema organizativo de rama principal; realice todo el desarrollo diario en / trunk y cree una etiqueta / para cada versión una vez que esté lista.

Configure su sistema CI para construir desde etiquetas y desde troncal, y haga que escriba la salida en un directorio de red cuya estructura refleje la estructura de nivel superior del repositorio:

/ builds / trunk / [rev] [fecha] [build_id] /
/ builds / tags / release_0_1_3beta4 / [rev] [fecha] [build_id] /

El sistema de compilación deberá tratar el directorio / builds / trunk / como un búfer circular, almacenando las últimas n compilaciones, eliminando las compilaciones antiguas a medida que avanza.

El directorio / builds / tags / , por otro lado, es una tienda permanente. Los artefactos de compilación se almacenan en directorios con nombres generados de acuerdo con el siguiente esquema:

[rev] [fecha] [build_id]

donde [rev] es el ID de revisión SVN, [fecha] es la fecha en formato AAAAMMDD y [build_id] es un contador único de 3 dígitos, que se incrementa desde la primera compilación en adelante, haciendo que cada directorio de compilación sea único.

El proceso detallado anteriormente le brinda los siguientes beneficios:

Los artefactos de construcción están vinculados sistemáticamente a la fuente que los generó, por lo que puede encontrar la fuente de un artefacto de construcción particular muy fácilmente (y viceversa).
Esto forma la base para una mayor automatización de versiones. Por ejemplo, generación automática de documentos de liberación, etc.

— William Payne
fuente