continuous integration - que - Construir versiones en entrega continua

integración continua aws

Question

Tengo algunas preguntas concretas sobre las versiones en Continuous Delivery. Creo que entiendo el flujo de trabajo global que más o menos es esto:

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

¿Qué pasa con las versiones? ¿Cómo gestionar versiones de compilación?

Digamos que estamos trabajando en un proyecto basado en Maven con versiones semánticas: major.minor.build .

Cuando el desarrollador realiza cambios en VCS y el servidor de CI realiza una compilación, ¿debería el servidor de CI incrementar la versión de compilación y crear una etiqueta en VCS?

¿Esta versión de compilación está presente en el código fuente? Si es así, después de cada envío a VCS, el desarrollador debe actualizar el proyecto, ya que el servidor CI confirmó los cambios (incremento de versión) en el proyecto.

Estoy un poco confundido y me gustaría entender el flujo de trabajo del CD de una manera práctica.

Answer 1

En general deberías tener:

1. Un número de versión gestionado manualmente.
2. Cualquier número de números de "referencia".

El primer punto es crucial si se preocupa por semver o en caso de que tenga que proporcionar información de compatibilidad para otras herramientas / librerías. Es solo usted quien puede saber si un nuevo "lanzamiento" rompe algo: el sistema de indicación más popular es seguir las reglas de control de versiones de semver.

El segundo punto (número de "referencia") puede o no ser importante para usted. Por lo general, no necesita más de uno, el número de versión de la compilación de CI / CD (cada servicio popular de CI / CD tiene un número de identificación de versión de compilación que se refiere a esa "compilación" específica). El punto de este número es que puede verificar rápidamente los registros / compilación de CI / CD relacionados de un artefacto si lo necesita.

¿Cómo fusionar las dos (o más) partes?

No es raro tener números separados de "versión" y "compilación". De hecho, todos los proyectos iOS tienen eso por defecto. En ese caso, tiene el número de "versión" administrado manualmente, y un número de "construcción" separado administrado automáticamente. El número de compilación puede estar en el nombre del artefacto, o puede imprimirse cuando alguien recupera la información de --version en caso de un binario (por ejemplo: $ brew info -> 0.9.5 (git revision 18c48; last commit 2015-11-02)

Alternativamente, puede agregar nuevos componentes a semver ( xxxBUILDNUM ), usar el último componente de semver ( xxBUILDNUM - No recomendaría esto si tiene un BUILDNUM estrictamente incremental) o simplemente incluir el número de "construcción" en el nombre del artefacto .

Estas son todas las posibilidades, tendrás que elegir la mejor para tu caso. Debe definir el significado de estos números y decidir dónde se debe presentar el número (por ejemplo, debe ser parte de una llamada a la --version o debe ser solo parte del nombre de archivo).

edit : para reflexionar sobre su pregunta sobre "¿debería el servidor de CI incrementar la versión de compilación y crear una etiqueta en VCS?" - Nunca recomendaría esto. Un servidor de CI también puede tener problemas, nunca debe modificar su código de un proceso de CI. Accidentalmente sobrescribir (por ejemplo, forzar el empuje) algo puede ser realmente peligroso. Por eso es mejor usar el Número de compilación expuesto por el servicio de CI / CD.