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

12

Un colega y yo nos hemos estado turnando debatiendo / discutiendo los problemas / méritos de integrar una versión derivada del repositorio de git actual en nuestro código cada vez que se crea.

Creemos que los méritos incluyen:

  • No hay necesidad de preocuparse por un error humano al actualizar un número de versión
  • La trazabilidad entre lo que encontramos en un dispositivo y el código fuente del que se derivó

Los problemas que han surgido (para nosotros) incluyen:

  • Los sistemas de compilación derivados de IDE (por ejemplo, MPLABX) pueden hacer que sea difícil averiguar dónde colocar este tipo de ganchos (y puede terminar bastante cursi al final)
  • Más trabajo para integrar realmente esto en los scripts de compilación / makefiles
  • El acoplamiento a un enfoque de compilación particular (por ejemplo, si una persona construye con XCode y el otro MPLABX) puede crear sorpresas posteriores

Entonces, tenemos curiosidad por saber dónde otros han llegado a este debate. Es realmente fácil para la discusión volverse 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, quienes simplemente hacen lo más fácil que funciona y viven con los riesgos.

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

    
pregunta Travis Griggs 25.03.2013 - 16:38

5 respuestas

15

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

  • crear una etiqueta para la versión en la que estamos trabajando (por ejemplo, v1.1.2)
  • cada compilación se ejecuta git describe
  • cuando enviemos, use el nombre de la etiqueta

git describe proporciona el nombre de la etiqueta, el número de confirmaciones desde la etiqueta y el hash de la etiqueta. Una etiqueta de muestra se parece a:

v1.1.2-6-a3b27gae

Esto tiene la ventaja 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 manejar; simplemente haga que el líder de su equipo cree y empuje la etiqueta en una nueva rama de corrección de errores y su sistema de compilación se encarga del resto.

Eliminamos el hash (y el número de compilación) porque facilita que los usuarios entiendan nuestros números de versión. Descubrimos que esto nos brinda lo mejor de ambos mundos, a la vez que proporcionamos 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.

    
respondido por el beatgammit 25.03.2013 - 19:34
6

Solíamos ser una tienda SVN, por lo que esta matemática era fácil: el número de compilación era la rev. SVN y así era. Tratamos de mantener esto en marcha cuando empezamos a cambiarnos a DCVS y encontramos que falló por varias razones.

Primero, ¿quién sabe si rev 69bc333bc8d8 es antes, después 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. En segundo lugar, la naturaleza del control de fuente DCVS hace que las cosas no sean lineales de muchas maneras cuando las siguientes compilaciones no avanzan 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.

    
respondido por el Wyatt Barnett 25.03.2013 - 18:20
2

Estoy vinculando directamente la salida del estado de git, el registro y la diferencia en el ejecutable. Entonces hay una opción para imprimir eso. La ventaja es que no solo es capaz de averiguar de qué rama se construyó su binario, sino también qué cambios de código fuente no comprometidos están incluidos. Por favor vea:

enlace

Debería poder usar esos 3 archivos para crear su propio archivo de estado SCM.

    
respondido por el colding 04.04.2013 - 13:15
1

Utilizo el siguiente esquema para que un sistema de compilación de Visual Studio de un C # DLL genere automáticamente números de versión (históricamente hemos tenido problemas con implementaciones que no se realizaron correctamente, por lo que necesitaba una forma clara de garantizar que se implementó la versión correcta) .

  • Major - Hard coded 1, típicamente determinado por el lado comercial
  • Menor: 0 codificado, generalmente 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)
  • Generar: 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 sin signo de 16 bits 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, agregando el número de versión de git como un número de versión informativa.

    
respondido por el Guvante 25.03.2013 - 19:07
0

Recomendaría el uso de Autorevision .

Puede obtener resultados en una variedad de formatos, por ejemplo, un encabezado de estilo c .

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

Además, dado que además de git , Autorevision funciona con svn y hg , hace que sea más fácil cambiar de svn sin tener que cambiar demasiado una vez que lo haya configurado.

    
respondido por el dak180 24.01.2015 - 20:51

Lea otras preguntas en las etiquetas