stratégies de package et de version dans un environnement multi-référentiel

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é.

Hmm, j'ai un exemple .net qui pourrait être indépendant de la technologie.

Je vais juste faire un bref résumé.

• git repo par composant avec stratégie de branchement gitflow

• tous s'engage à développer déclencher une construction de la ville de l'équipe

• build teamcity modifie la version avec le mineur majeur manuel + le numéro de build dans AssemblyInfo.cs ie 1.1.hotfix.build

• teamcity déclenche l'empaquetage de nuget en utilisant le même numéro de version pour les bibliothèques publiées par nuget

• octopus déploie la version terminée sur qa pour les tests manuels (en supposant que tous les tests réussissent)

• si tout va bien, déployez manuellement la version en production via octopus.

Maintenant, cela signifie que vous obtenez BEAUCOUP de packages versionnés flottant. Nous avons expérimenté l'utilisation de l'indicateur -prerelease, mais cela nécessitait un autre package de déplacement manuel de l'étape de prélancement à l'étape «normale» et une nécessité de reconstruire les composants qui en dépendaient.

L'essentiel est de mettre à jour chaque version uniquement via un processus central.

Alors vous êtes dans la situation de "hmm quelles versions je veux" plutôt que "omg, quelle version ai-je?"

Edit: re commentaires.

Juste pour souligner vraiment cet élément clé. Décidez quelle branche constitue le logiciel terminé et quelle version TOUS s'y engage. déployer uniquement des logiciels versionnés à partir de cette branche.

Mon avis est cependant que vous devez aborder votre stratégie de branchement.

• ne pas versionner les branches (ou n'importe quel dev).
• faire version master
• utiliser uniquement les packages du maître

Permettez-moi de proposer un flux de travail alternatif, qui pourrait résoudre votre problème de versionnage, ou tout simplement vous aider à réfléchir à d'autres moyens de trouver la solution.

Un peu de philosophie d'abord ..
(Je fais quelques hypothèses sur votre workflow, corrigez-moi si je me trompe)

1. Les tests sont exécutés rétroactivement :

   Branchez-le pour en maserfaire une branche, puis transformez-le en artefact à tester par le contrôle qualité.
   le problème est : que faire si les tests échouent, alors ils masterpeuvent être cassés!

   Effets secondaires:

   • Cela fait que les développeurs ne font pas confiance master

   • Étant donné que vous passez de la branche principale à la version finale, que se passe-t-il si la version précédente est interrompue? il arrête l'intégration de vos nouvelles fonctionnalités jusqu'à ce que le maître soit à nouveau corrigé.

   • lorsque le bogue est corrigé dans la branche de publication, la fusion à nouveau masterpeut créer des conflits de fusion. (et nous n'aimons pas les conflits)

2. petit code fusionne et corrige :

   Il est difficile de garder une trace de tout le code qui est fusionné master, comme les petites corrections ou modifications qui ne font pas partie d'une certaine fonctionnalité.

   Effets secondaires:

   • le développeur n'est pas sûr s'il doit marge ce petit correctif maintenant ou plus tard.

   • devrais-je également mettre à jour cette nouvelle petite correction?

   • À tout moment, il n'est pas clair quel est l'état de la masterbranche et quel code flotte là-dedans

   • quelque chose a cassé la construction, cela ne fait pas partie de la nouvelle fonctionnalité. et c'est vraiment difficile de savoir d'où ça vient

Mon idée pour le flux de travail git est la suivante:

branchez-vous masterpour le développement de nouvelles fonctionnalités comme vous le faites déjà. mais maintenant, au lieu de sortir de cette branche nouvellement créée, cette fonctionnalité a été sélectionnée et fusionnée dans la releasebranche.

Maintenant, vous avez un meilleur contrôle sur ce qui se passe dans une certaine version.
Il est désormais très facile d'isoler les versions de développement et les versions stables.

Vous pouvez continuer à créer des artefacts à partir de ces branches de fonctionnalités pour le contrôle qualité.
Si tout va bien, fusionnez à nouveau cette fonctionnalité masteret choisissez cette fonctionnalité / correction de bogue / correction à chaud dans la branche de publication.

versioning
La version des branches de fonctionnalité peut utiliser une convention de nom comme1.2.3-rc.12345

les versions de la releasebranche n'utiliseront que 1.2.3 ( 1.2.3> 1.2.3-rc.12345aussi une chose de moins à se soucier)

Ce flux de travail résout les problèmes mentionnés ci-dessus, et plus encore.
Il propose également une stratégie de version saine, et la plupart de ce cycle de version peut être automatisé.

J'espère que cela vous aidera d'une manière ou d'une autre, je serai ravi de discuter de tous les cas marginaux que vous pourrez trouver.

ps:
Je m'excuse pour mon anglais, ce n'est pas ma langue principale.

Votre processus semble très compliqué et obtenir un petit nombre de balises semble inévitable.

Deux idées me viennent à l'esprit:

1. Vous traitez la branche "maître" comme ce que nous avons généralement dans la branche "développer". Cela pollue beaucoup la branche des messages.

2. Lorsque le contrôle qualité a terminé son travail, vous pouvez demander au serveur build / CI de créer un rapport (par exemple, un fichier texte) avec les balises de tous les référentiels utilisés. Maintenant, vous aurez un fichier avec les versions qui peuvent être publiées dans le repo. Ensuite, vous balisez la branche avec la version finale uniquement et si vous souhaitez vérifier les versions de leurs composants individuels, vous pouvez vérifier le rapport.