Versiones con un sistema de compilation automático

Recientemente nos mudamos a un sistema de compilation automático (algo interno, no Hudson o Teamcity, aún).
Nuestra versión se almacena en un file de cabecera y está incluida en algunos files cpp y de resources. También lo usa el instalador.

Su formatting es ABCD donde:

  • A no cambió en años.
  • B cambia raramente (versión principal).
  • C cambia con versiones menores.
  • D cambia cuando se entrega una nueva versión menor (corrección de errores) a QA.

Hasta ahora, el único responsable de build una nueva versión, incrementó C/D a mano ( D es el más común) antes de comenzar la compilation, verificó el cambio y luego comenzó la compilation. La versión se mantuvo igual hasta que esa persona construyó la aplicación con éxito.

Naturalmente, con el cambio a un sistema de compilation automático, me gustaría deshacerme del paso manual de cambiar el número de versión.

¿Cómo se debe abordar esto?

  • ¿Incremento D cada vez que se realiza una nueva compilation, ya sea una compilation de QA o una compilation de testing interna (es decir, estoy trabajando en alguna function y me gustaría probar que no he roto nada)?
  • ¿El incremento es una tarea en el sistema de compilation automática?
  • Después de incrementar, ¿debo confirmar el file de versión?
  • ¿Cómo evito tener mucho ruido en el control de mi versión? No quiero toneladas de confirmaciones de "versión incrementada".
  • ¿Qué hago si la compilation falla? ¿Todavía incrementa la versión y confirma?

¿Incremento D cada vez que se realiza una nueva compilation, ya sea una compilation de QA o una compilation de testing interna (es decir, estoy trabajando en alguna function y me gustaría probar que no he roto nada)?

La Eclipse Foundation agrega un elemento E, la date y la hora de la compilation. Creo que es una buena idea para las versiones de testing interna. Depende de usted si quiere usar E para las versiones de QA.

¿El incremento es una tarea en el sistema de compilation automática?

Parece lógico, pero tienes que tener alguna forma de decirle a esa tarea qué tipo de construcción estás haciendo.

¿Cómo evito tener mucho ruido en el control de mi versión? No quiero toneladas de confirmaciones de "versión incrementada".

Confirme el file de control de versión con el código fuente.

Básicamente, su process de desarrollo debe desarrollarse en el siguiente order.

  • Construye el producto desde el código fuente de desarrollo.
  • Si la construcción tiene éxito, incremente el número de versión.
  • Confirme el código fuente y el file de control de versión.
  • Construya el producto nuevamente desde su sistema de control de versiones.
  • Si la compilation falla, restituya el código fuente y el file de control de versión commit.

Esto testing tu compilation y tu process de compilation. La segunda compilation nunca debe fallar, pero si lo hace, hay un problema en el process.

Su process de creación de producción comenzaría en el 2 ° paso, omitiendo el 3er paso.

¿Qué hago si la compilation falla? ¿Todavía incrementa la versión y confirma?

Mi E se autoincrementa. 🙂 Diría que no a los otros elementos A, B, C o D.

¿Incremento D cada vez que se realiza una nueva compilation, ya sea una compilation de QA o una compilation de testing interna (es decir, estoy trabajando en alguna function y me gustaría probar que no he roto nada)?

Sí, cambie su process para que D se incremente con cada construcción (exitosa o no) en lugar de con cada entrega a QA.

Puede ser bastante frustrante tener varias comstackciones, algunas no y no poder distinguirlas porque la compilation fallida es la misma que la buena, con el time. Entonces ni siquiera tiene que considerar si fue el mismo día o en la misma hora.

¿El incremento es una tarea en el sistema de compilation automática?

Me gustaría que el sistema de compilation aumente automáticamente el número de compilation (D) solamente.

Después de incrementar, ¿debo confirmar el file de versión? ¿Cómo evito tener mucho ruido en el control de mi versión? No quiero toneladas de confirmaciones de "versión incrementada".

El almacenamiento de control de versiones se trata de grabar el ruido detallado.

Me gustaría tener la actualización de la versión marcada, esto puede hacer que una label razonable sea visible en SVN en donde se incluyeron los cambios anteriores, hacer que el sistema de compilation ignore los checkins por el sistema de compilation, o aquellos identificados como la actualización de la versión checkin.

Luego, para ver el historial de versiones, debe tener una herramienta adecuada que le permita filtrar el historial para mostrarle la vista que necesita, en algunos casos excluyendo las tags de confirmación de la versión.

Si decide no comprometer el número de versión de cada compilation, puede ser una buena idea mantener el número de versión en un file separado para evitar actualizaciones accidentales.

¿Qué hago si la compilation falla? ¿Todavía incrementa la versión y confirma?

Aún boost el número de versión, no comprometería el número de versión a less que fuera una compilation exitosa. Puede tener una variedad de fallas fuera del cambio de fuente en el control de la versión que no necesita registrarse: comstackr server fuera de disco, locking del server, el comstackdor se tambaleó en las rodillas construyendo 32 y 64 bits, depurar y lanzar aix, Linux y Windows construye al mismo time …

Podría considerar utilizar la convención para ensamblados .NET, como se describe en la documentation para la class System.Version . Citar:

  • Construya [su C]: una diferencia en el número de compilation representa una recompilation de la misma fuente. Se pueden usar diferentes numbers de compilation cuando el procesador, la plataforma o el comstackdor cambian.
  • Revisión [su D]: Asambleas con los mismos numbers de versión principal y secundaria, pero las diferentes revisiones tienen la intención de ser completamente intercambiables. Se podría usar un número de revisión más alto en una compilation que corrige un agujero de security en un ensamblaje lanzado anteriormente.

¿Cómo vas a automatizar esto? Quiero decir, ¿qué sistema sabría que "esta construcción es la versión de lanzamiento"? Me parece que todos tus dígitos en una versión son relevantes. Si la próxima versión (D + 1) requiere dos comstackciones, ¿ABCD + 2 sería la próxima versión? Suena sospechoso para mí. Preferiría agregar el número de compilation en la parte superior de la versión, si es realmente necesario tener esta información en los files DLL y EXE.

No creo que el número de compilation sea una información relevante para adjuntar al binary, a less que distribuyas files de la versión ABCD de diferentes comstackciones (¡lo cual no debes hacer de todos modos!)

Me gustaría configurar el server de compilation para almacenar los artefactos (DLL, EXEs, MSI, PDB, etc.) en un directory, cuyo nombre incluye el número de compilation y la versión, y luego grabar DVD / lo que sea desde allí. Si alguna vez necesita realizar una copy de security de una versión a una compilation específica, puede usar esta información, siempre que conserve un file de sus publicaciones (¡recomendado!).

Yo recomendaría el uso de la autorevisión .

Aún podría conservar el formatting ABCD para sus tags y usar la secuencia de commands para crear files de encabezado que se generan en el momento de la compilation y que contienen la información necesaria.