estrategias de paquete y versión en un entorno de repositorio múltiple

Somos una empresa pequeña con múltiples equipos que administran sus propios repositorios git. Esta es una plataforma web y los artefactos de cada equipo se implementan al final del día para las pruebas nocturnas. Estamos tratando de formalizar el proceso de versiones y empaques.

Cada equipo tiene una rama maestra donde realizan el desarrollo diario. Los miembros de control de calidad de cada equipo desean que los artefactos de los cambios de su equipo se implementen en un banco de pruebas donde el chef combine todos los componentes. Los artefactos son tarballs, pero me gustaría convertirlos en RPM para que podamos pensar y razonar sobre las versiones correctamente.

El proceso de lanzamiento implica cortar una rama de lanzamiento de la rama de desarrollo (maestra en la mayoría de los casos) de cada uno de los repositorios git. Esto se da luego a la garantía de calidad que realiza pruebas y firma en un conjunto de artefactos.

Por ejemplo, este es un repositorio git típico con sus ramas de lanzamiento asociadas:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Estoy atrapado tratando de encontrar un esquema para realizar versiones de paquetes provenientes de ramas de desarrollo. No queremos etiquetar excesivamente la rama maestra de cada repositorio y restringir las etiquetas para liberar solo ramas. Pero deberíamos poder consultar los paquetes desplegados en las máquinas de prueba utilizando la semántica estándar de yum / rpm. ¿Cómo se verían las versiones de desarrollo cuando la rama maestra no tiene etiquetas? Entiendo que git describepuede proporcionarme una representación útil de una versión de compilación, pero que funciona bien cuando se etiquetan varios puntos de lanzamiento en la rama.

EDIT1: en respuesta a la respuesta de @ Urban48

Pensé que debería explicar nuestro proceso de lanzamiento un poco más. Para los propósitos de esta discusión, supongamos que tenemos una sucursal masteren todos los repositorios. La masterrama se considera la rama de desarrollo y se implementa en un entorno de control de calidad habilitado para CI-CD automatizado. Aquí es donde se ejecuta un subconjunto de pruebas nocturnas para garantizar la estabilidad del maestro. Examinamos esta cartera de trabajos antes de cortar una rama de lanzamiento. Nuestras ramas de lanzamiento son de corta duración. Digamos, después de cortar una rama de lanzamiento (desde un maestro estable), se ejecuta una regresión completa, se realizan arreglos y se implementan en producción. Esto toma alrededor de una semana para hacerlo. Lanzamos casi cada dos semanas a la producción.

Nuestras ramas de características siempre se cortan del maestro y se someten a una cierta cantidad de pruebas de desarrollador antes de fusionarse con el maestro en el que se someten a las comprobaciones de estabilidad de CI-CD.

Las revisiones se realizan en ramas de revisión (cortadas de las ramas de lanzamiento) y se implementan con pruebas de impacto mínimas en la producción.

Nuestra estrategia de versiones para las ramas de lanzamiento y revisión sigue a semver. Las ramas de lanzamiento durante el ciclo de control de calidad pasan por versiones similares v2.0.0-rc1, v2.0.0-rc2y finalmente después de que se cierra la sesión de control de calidad v2.0.0.

A veces hacemos lanzamientos punteados para pequeñas características que se combinan para liberar ramas (y luego para masterizar) donde se convierten las versiones v2.1.0. Y las revisiones asumen el v2.1.1patrón.

Sin embargo, la pregunta no se trata de versionar estas ramas. Preferiría no cambiar este esquema de versiones por completo. El único cambio se produce para la rama de desarrollo, es decir. Maestro. ¿Cómo puedo indicar de manera confiable en el entorno de CI-CD qué versión existe con la versión anterior en producción? Idealmente, esto se haría mediante el etiquetado inteligente de git, pero se prefiere algo que no etiquete excesivamente la rama maestra.

Hmm, bueno, tengo un ejemplo de .net que podría ser independiente de la tecnología.

Solo haré un resumen rápido.

• repositorio de git por componente con estrategia de ramificación de gitflow

• todos se comprometen a desarrollar desencadenar un equipo de construcción de la ciudad

• teamcity build modifica la versión con manual mayor menor + el número de compilación en AssemblyInfo.cs es decir 1.1.hotfix.build

• teamcity desencadena el empaquetado nuget usando el mismo número de versión para las bibliotecas publicadas nuget

• Octopus implementa la compilación terminada en qa para pruebas manuales (suponiendo que todas las pruebas pasen)

• Si todo está bien, implemente manualmente la versión en producción a través de Octopus.

Ahora, esto significa que obtienes MUCHOS paquetes versionados flotando. Experimentamos con el uso del indicador de presentación, pero esto requería un paquete de traslado manual adicional desde el lanzamiento previo al paso 'normal' y un requisito para reconstruir los componentes que dependían de ellos.

La clave es versionar cada compilación de manera única a través de algún proceso central.

Entonces estás en la situación de 'hmm, ¿qué versiones quiero' en lugar de 'omg, qué versión tengo?'

Editar: re comentarios.

Solo para subrayar esa cosa clave realmente. Decida qué rama constituye el software completo y la versión que ALL se compromete con él. solo implemente software versionado desde esta rama.

Sin embargo, mi opinión es que debe abordar su estrategia de ramificación.

• no versión ramas de características (o cualquier desarrollador).
• hacer version master
• solo use paquetes de master

Permítame ofrecerle un flujo de trabajo alternativo, que puede resolver su problema de versiones o simplemente ayudarlo a pensar en más formas de encontrar la solución.

Un poco de filosofía primero ...
(Estoy haciendo algunas suposiciones sobre su flujo de trabajo, corríjame si me equivoco)

1. Las pruebas se ejecutan retroactivamente :

   Se bifurca masery se bifurca, luego se convierte en un artefacto para la prueba de control de calidad.
   el problema es : ¿qué pasa si las pruebas fallan, entonces masterpueden romperse?

   efectos secundarios:

   • Hace que los desarrolladores no confíen master

   • Dado que se ramifica desde el maestro para liberar ramas, ¿qué sucede si se rompe la versión anterior? detiene su nueva integración de funciones hasta que el maestro se repare nuevamente.

   • cuando se corrige el error en la rama de lanzamiento, la fusión de nuevo masterpuede crear conflictos de fusión. (y no nos gustan los conflictos)

2. pequeñas combinaciones y correcciones de código :

   Es difícil hacer un seguimiento de todo el código que se fusiona master, como pequeñas correcciones o cambios que no son parte de una determinada característica.

   efectos secundarios:

   • El desarrollador no está seguro de si debe corregir esta pequeña solución ahora o más tarde.

   • ¿Debería versionar esta nueva pequeña solución también?

   • En cualquier momento no está claro cuál es el estado de la masterrama y qué código está flotando allí

   • algo rompió la construcción, eso no es parte de la nueva característica. y es muy difícil rastrear de dónde vino

Mi idea para el flujo de trabajo de git es la siguiente:

ramifíquese para el desarrollo de masternuevas características como ya lo hace. pero ahora, en lugar de liberarse de esta rama recién creada, haga que esta característica sea seleccionada y fusionada en la releaserama.

Ahora tiene un mejor control sobre lo que está pasando en una determinada versión.
Ahora es muy fácil aislar versiones de desarrollo y versiones estables.

Puede seguir construyendo artefactos a partir de esas ramas de características para el control de calidad.
Si todo está bien, vuelva a fusionar esa función mastery seleccione esta función / corrección de errores / corrección en caliente en la rama de lanzamiento.

versionado
La versión de ramas de características puede usar alguna convención de nombres como1.2.3-rc.12345

las versiones en la releaserama solo usarán 1.2.3 ( 1.2.3> 1.2.3-rc.12345también una cosa menos de la que preocuparse)

Este flujo de trabajo corrige los problemas mencionados anteriormente y más.
También propone una estrategia de versiones sensata, y la mayor parte de este ciclo de lanzamiento puede automatizarse.

Espero que te ayude de alguna manera, con mucho gusto hablaré sobre cualquier caso límite que se te ocurra.

PD:
Pido disculpas por mi inglés, no es mi idioma principal.

Su proceso parece muy complicado y obtener un poco de etiquetas parece inevitable.

Se me ocurren dos ideas:

1. Usted trata la rama "maestra" como lo que típicamente tenemos en la rama "desarrollada". Esto contamina mucho la rama del mensaje.

2. Cuando el QA termina con su trabajo, puede hacer que el servidor de compilación / CI cree un informe (por ejemplo, un archivo de texto) con las etiquetas de todos los repositorios en uso. Ahora tendrá un archivo con las versiones que se pueden publicar en el repositorio. Luego etiqueta la rama solo con la versión de lanzamiento y si desea verificar las versiones de sus componentes individuales, puede verificar el informe.