¿Para integrar versiones de git como números de compilación o no?

Un colega y yo nos hemos turnado para debatir / discutir los problemas / ventajas de integrar una versión derivada del repositorio git actual en nuestro código cada vez que se construye.

Creemos que los méritos incluyen:

• No necesita preocuparse por errores humanos al actualizar un número de versión
• Trazabilidad entre lo que encontramos en un dispositivo y el código fuente del que se deriva

Los problemas que han surgido (para nosotros) incluyen:

• Los sistemas de compilación derivados de IDE (por ejemplo, MPLABX) pueden dificultar la idea de dónde colocar este tipo de ganchos (y al final puede resultar bastante cursi)
• Más trabajo para integrar esto realmente en los scripts / makefiles de compilación
• Acoplarse a un enfoque de compilación particular (p. Ej., Si una persona construye con XCode y la otra MPLABX) puede crear sorpresas posteriores

Así que tenemos curiosidad sobre dónde otros han aterrizado en este debate. Es realmente fácil que la discusión se vuelva anecdótica. Hay muchas personas que insisten en la automatización de extremo a extremo, cuelgan la cantidad de trabajo inicial y el acoplamiento que crea. Y hay muchos otros en el otro lado del debate, que simplemente hacen lo más fácil que funciona y viven con los riesgos.

¿Hay una respuesta razonada a qué lado es mejor aterrizar?

Usamos git describe con etiquetas de versión. El flujo es básicamente:

• crear etiqueta para la versión en la que estamos trabajando (por ejemplo, v1.1.2)
• cada ejecución de construcción git describe
• cuando enviamos, use el nombre de la etiqueta

git describeproporciona el nombre de la etiqueta, el número de confirmaciones desde la etiqueta y el hash de la etiqueta. Una etiqueta de muestra se ve así:

v1.1.2-6-a3b27gae

Esto tiene el beneficio de que los desarrolladores obtienen hashes, por lo que si algo se rompe entre compilaciones, el desarrollador puede diferenciar fácilmente los cambios. También es estúpido simple de administrar; solo haga que su líder de equipo cree y presione la etiqueta en una nueva rama de corrección de errores y su sistema de compilación se encargará del resto.

Eliminamos el hash (y el número de compilación) porque facilita a los usuarios comprender nuestros números de versión. Descubrimos que esto nos brinda lo mejor de ambos mundos, a la vez que proporciona suficiente información relevante al diseñar una versión.

Actualmente, tenemos una versión un poco más complicada de esto, pero la idea sigue siendo.

Solíamos ser una tienda de SVN, por lo que esta matemática fue fácil: el número de compilación fue la revisión de SVN y eso fue todo. Intentamos mantener esto en marcha cuando comenzamos a movernos a DCVSes y descubrimos que fallaba por varias razones.

Primero, ¿quién sabe si rev 69bc333bc8d8 es anterior, posterior o concurrente con rev 25b0f0d1052c? Hay muy poco contexto en comparación con el sistema SVN cuando al menos sabías que 101 era después de 100. Segundo, la naturaleza del control de fuente DCVS hace que las cosas no sean lineales de muchas maneras cuando las construcciones posteriores podrían no avanzar la misma bola.

Finalmente decidimos usar un servidor de compilación para distribuir los números de compilación a las cosas, ya que tenía la visibilidad y la capacidad adecuadas para manejarlo.

Utilizo el siguiente esquema para un sistema de compilación de Visual Studio de una DLL de C # para generar automáticamente números de versión (históricamente hemos tenido problemas con las implementaciones que no se realizaron correctamente, por lo que necesitábamos una manera limpia de garantizar que se implementara la versión correcta).

• Mayor: codificado 1, generalmente determinado por el lado comercial
• Menor: 0 codificado, típicamente determinado por el lado comercial
• Revisión: número de días desde el 1 de enero de 2010 (o cualquier otra fecha de inicio arbitraria)
• Compilación: la mitad del número de segundos desde la medianoche (ya que es un número sin signo de 16 bits)

Tenga en cuenta que esto supone que tiene 2 números fungibles de 16 bits sin signo para jugar. También se podría crear un sistema equivalente que use números más pequeños.

También tenga en cuenta que los campos no numéricos pueden ser útiles si puede adjuntarlos como metadatos. Por ejemplo, agregar el número de versión de git como número de versión informativa.

Estoy directamente vinculando la salida del estado de git, log y diff en el ejecutable. Entonces hay una opción para imprimir eso. La ventaja es que no solo puede averiguar desde qué rama se compiló su binario, sino también qué cambios de código fuente no confirmados están incluidos. Por favor mira:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Debería poder usar esos 3 archivos para crear su propia biblioteca SCM state lib.

Recomendaría el uso de Autorevision .

Se puede obtener una salida en una variedad de formatos, por ejemplo, una cabecera de estilo c .

También hay algunos ejemplos (en el directorio contribs) de cómo puede conectar las cosas para que, sin importar quién esté construyendo y cómo lo estén haciendo, siempre obtendrán la misma información de versión, incluso si están construyendo desde un tarball.

Además, dado que además de gitAutorevision funciona svny hges más fácil cambiar de svn sin tener que cambiar demasiado una vez que lo tiene configurado.