Nous sommes une petite entreprise avec plusieurs équipes qui gèrent leurs propres dépôts git. Il s'agit d'une plateforme Web et les artefacts de chaque équipe sont déployés à la fin de la journée pour des tests nocturnes. Nous essayons de formaliser le processus de versioning et de packaging.
Chaque équipe a une branche principale où elle fait le développement au jour le jour. Les membres de l'assurance qualité de chaque équipe souhaitent que les artefacts des changements de leur équipe soient déployés dans un banc d'essai où tous les composants sont combinés par le chef. Les artefacts sont des tarballs mais je voudrais les convertir en RPM afin que nous puissions penser et raisonner correctement sur les versions.
Le processus de publication implique de couper une branche de publication de la branche de développement (maître dans la plupart des cas) de chacun des référentiels git. Ceci est ensuite donné à l'assurance qualité qui exécute des tests et approuve un ensemble d'artefacts.
Par exemple, il s'agit d'un référentiel git typique avec ses branches de publication associées:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Je suis coincé à essayer de trouver un schéma pour effectuer le versionnement des packages provenant des branches de développement. Nous ne voulons pas baliser excessivement la branche principale de chaque dépôt et restreindre les balises aux versions uniquement. Mais nous devrions pouvoir interroger les packages déployés dans les machines de test en utilisant la sémantique standard yum / rpm. À quoi ressembleraient les versions de développement lorsque la branche principale n'a pas de balises? Je comprends que cela git describepeut me fournir une représentation utile d'une version de build, mais cela fonctionne bien lorsque divers points de publication sur la branche sont marqués.
EDIT1: En réponse à la réponse de @ Urban48
J'ai pensé que je devrais expliquer un peu plus notre processus de sortie. Aux fins de cette discussion, supposons que nous avons une branche masterdans tous les référentiels. La masterbranche est considérée comme la branche de développement et est déployée dans un environnement QA automatisé compatible CI-CD. C'est là qu'un sous-ensemble de tests nocturnes s'exécute pour assurer la stabilité du maître. Nous examinons ce pipeline d'emplois avant de supprimer une branche de publication. Nos branches de publication sont de courte durée. Supposons qu'après avoir coupé une branche de publication (à partir d'un maître stable), une régression complète soit exécutée, des correctifs soient effectués et déployés en production. Cela prend environ une semaine. Nous sortons presque toutes les deux semaines en production.
Nos branches de fonctionnalités sont toujours coupées du maître et subissent une certaine quantité de tests de développeur avant de fusionner avec le maître sur lequel elles subissent les contrôles de stabilité CI-CD.
Les correctifs sont créés sur des branches de correctifs (coupés à partir des branches de publication) et déployés avec un test d'impact minimal en production.
Notre stratégie de versioning pour les branches de publication et de correctifs suit semver. Les branches de publication au cours du cycle d'assurance qualité passent par des versions telles que v2.0.0-rc1, v2.0.0-rc2et finalement, après la validation de l'assurance qualité v2.0.0.
Nous faisons parfois des versions en pointillés pour les petites fonctionnalités qui sont fusionnées pour libérer les branches (puis les maîtriser) où les versions deviennent v2.1.0. Et les correctifs assument le v2.1.1modèle.
La question n'est cependant pas de versionner ces branches. Je préférerais ne pas modifier complètement ce schéma de version. Le seul changement se produit pour la branche de développement à savoir. Maître. Comment puis-je indiquer de manière fiable dans l'environnement CI-CD quelle version existe par rapport à la version précédente en production. Idéalement, cela se ferait grâce au balisage intelligent git, mais quelque chose qui ne balisait pas excessivement la branche principale est préféré.
rcsuffixe? Cela dicterait la major.minorversion de développement. rcet le numéro de build ne peut être obtenu que sur cette base. Également rcsur master n'a pas de sens car nous ne sortons jamais de master. Nous marquons nos candidats à la sortie aujourd'hui sur les branches de sortie comme faisant partie du cycle de sortie
rcsuffixe.
