Somos una empresa pequeña con varios 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 en torno al versionado y empaquetado.
Cada equipo tiene una rama maestra en la que realizan el desarrollo del día a día. Los miembros de control de calidad de cada equipo quieren que los artefactos de los cambios de su equipo se implementen en un banco de pruebas donde el chef combina todos los componentes. Los artefactos son tarballs, pero me gustaría convertirlos en RPM para que podamos pensar y razonar acerca de las versiones correctamente.
El proceso de lanzamiento implica cortar una rama de lanzamiento de la rama de desarrollo (maestro en la mayoría de los casos) de cada uno de los repositorios git. Esto se otorga luego al control de calidad que ejecuta pruebas y firma en un conjunto de artefactos.
Por ejemplo, este es un repositorio git típico con sus ramas de versión asociadas:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Estoy atascado tratando de encontrar un esquema para realizar el control de versiones de paquetes provenientes de sucursales de desarrollo. No queremos etiquetar en exceso la rama maestra de cada repositorio y restringir las etiquetas para liberar ramas solamente. Pero deberíamos poder consultar los paquetes implementados 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 describe puede brindarme una representación útil de una versión de compilación, pero eso 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 fines de esta discusión, supongamos que tenemos la rama master en todos los repositorios. La rama master 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. Nos fijamos en este conjunto de trabajos antes de cortar una sucursal de lanzamiento. Nuestras sucursales de liberación son de corta duración. Por ejemplo, después de cortar una rama de lanzamiento (de 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 producción.
Nuestras ramas de características están siempre cortadas 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 verificaciones de estabilidad de CI-CD.
Las revisiones se realizan en sucursales de revisión (recortadas de sucursales de lanzamiento) y se implementan con pruebas de impacto mínimo en producción.
Nuestra estrategia de control de versiones para las sucursales de lanzamiento y revisión sigue a semver. Las ramas de lanzamiento durante el ciclo de control de calidad pasan por versiones como v2.0.0-rc1 , v2.0.0-rc2 y, finalmente, después de que el control de calidad se convierta en v2.0.0 .
A veces hacemos lanzamientos punteados para pequeñas características que se fusionan para liberar sucursales (y luego para dominar) donde las versiones se convierten en v2.1.0 . Y las revisiones asumen el patrón v2.1.1 .
Sin embargo, la pregunta no es sobre la versión de estas ramas. Preferiría no cambiar por completo este esquema de versiones. El único cambio que se produce para la rama de desarrollo es decir. dominar. ¿Cómo puedo indicar de forma fiable en el entorno de CI-CD qué versión existe con la versión anterior en producción? Esto se haría idealmente mediante el etiquetado inteligente de git, pero se prefiere algo que no etiquete excesivamente la rama maestra.
