Est-ce une bonne pratique de stocker les numéros de version du logiciel dans VCS?

Une version de produit, telle que v1.0.0.100, représente non seulement une version de production unique du logiciel, mais aide à identifier les ensembles de fonctionnalités et les étapes du correctif pour ledit produit. En ce moment, je vois deux façons de maintenir la version finale du package / build / binaire d'un produit:

Contrôle de version. Un fichier quelque part stocke le numéro de version. Le serveur de construction d'intégration continue (CI) aura un script pour créer le logiciel qui utilise ce numéro de version enregistré pour l'appliquer à toutes les zones du logiciel nécessaires (binaires, packages d'installation, pages d'aide, documentation, etc.).
Paramètres d'environnement et / ou de construction. Celles-ci sont conservées en dehors du contrôle de version (c'est-à-dire qu'elles ne sont pas liées à l'instantané / balise / branche). Les scripts de build distribuent et utilisent le nombre de la même manière, mais ils obtiennent simplement la valeur différemment (il est fourni au script de build, au lieu d'avoir le script sait où l'obtenir par rapport à l'arborescence source).

Le problème avec la première approche est qu'elle peut compliquer les fusions entre les branches principales. Si vous conservez toujours 2 versions parallèles du même logiciel, vous résoudrez les conflits lors de la fusion entre les deux lignes principales si la version a changé sur les deux depuis la dernière fusion.

Le problème avec la deuxième approche est la réconciliation. Lorsque vous revenez à une version il y a 1 an, vous vous baserez uniquement sur les informations de balise pour identifier son numéro de version.

Dans les deux cas, certains aspects du numéro de version peuvent ne pas être connus avant la génération du CI. Par exemple, une construction CI peut mettre par programme dans un 4ème composant qui est vraiment le numéro de construction automatisé (par exemple 140ème génération sur la branche). Il peut également s'agir d'un numéro de révision dans VCS.

Quelle est la meilleure façon de suivre le numéro de version d'un logiciel? Les parties "connues" doivent-elles toujours être conservées dans VCS? Et si c'est le cas, les conflits entre les branches principales sont-ils un problème?

À l'heure actuelle, nous conservons notre numéro de version via des paramètres spécifiés et maintenus dans le plan de construction CI (Atlassian Bamboo). Avant de fusionner avec notre masterbranche, nous devons faire attention à ce que les numéros de version soient correctement configurés avant le démarrage de la construction de CI . En ce qui concerne le flux de travail Gitflow, je pense que si le numéro de version était suivi dans le contrôle de source, nous pourrions garantir qu'il est correctement configuré lorsque nous créons notre releasebranche en préparation de la sortie. QA effectuerait des tests finaux d'intégration / de fumée / de régression sur cette branche et, à la signature, une fusion aurait masterlieu qui signifierait l' engagement de libérer.

— void.pointer
source

Un conflit de fusion entre deux versions d'un fichier dans version.txtlequel une version contient la seule ligne 1.0.7et l'autre est-il 1.2.0vraiment difficile à résoudre? Si c'est le seul conflit à fusionner deux branches qui se sont séparées, je me considérerais très chanceux. Combien de fois cela se produit-il? Si cela se produit, n'est-ce pas une bonne chose que vous soyez obligé de réfléchir au numéro de version que la version fusionnée devrait avoir? (Désolé pour l'utilisation ambiguë du mot «version».)

— 5gon12eder

@ 5gon12eder Les difficultés ou les sentiments concernant la fusion elle-même ne sont pas pertinents. C'est juste un aspect négatif de la solution globale.

— void.pointer

Réponses:

Personnellement, je choisis l'option 3: conserver les informations de version dans les métadonnées VCS , en particulier les balises.

Git le rend très facile à faire, car il existe une commande git describe, qui peut décrire de manière unique un commit basé sur une balise. Voici comment cela fonctionne:

Si la validation actuelle est balisée, affichez le nom de la balise.
Sinon, marcher dans les arrière de l' histoire jusqu'à trouver une étiquette puis sortie une description dans le format suivant: <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
S'il y a des modifications non validées dans l'arbre de travail, ajoutez -dirty.

Donc, si vous effectuez une build de version et que le commit est balisé 1.2.3, il sortira 1.2.3. Si vous travaillez actuellement sur la version 1.2.4 et que vous avez effectué 4 validations depuis la version 1.2.3, et que vous avez apporté des modifications non validées dans l'arborescence, cela sortira 1.2.3-4-gdeadbee-dirty.

Ceci est garanti d'être unique et monotone, ainsi que lisible par l'homme, et peut donc être utilisé directement comme chaîne de version. La seule chose que vous devez vous assurer est une convention de dénomination appropriée pour les balises.

— Jörg W Mittag
source

J'adore vraiment cette idée, mais cela semble difficile à gérer avec JIRA + Bamboo. Bamboo ne fonctionne que sur les branches, pas sur les balises, vous devez donc vous assurer qu'une balise est poussée avant qu'une génération soit générée. Ceci est sujet aux erreurs.

— void.pointer

git describefonctionne également avec les branches: " --all - Au lieu d'utiliser uniquement les balises annotées, utilisez n'importe quelle référence trouvée dans l' refs/espace de noms. Cette option permet de faire correspondre n'importe quelle branche connue, branche de suivi à distance ou balise légère." Je ne sais pas comment cela fonctionne avec Bamboo, cependant. (Cela nécessitera bien sûr un nommage soigneux des branches, tout comme le mode normal avec les balises.)

— Jörg W Mittag

Je connais des gens qui font des versions complètement automatiques de Git. La chaîne de version est construite par git describe, le ChangeLog est généré à partir de git shortlog(enfin, en fait à partir d'un script qui analyse la sortie de git log --pretty=tformat:<some custom format string>), et les notes de version sont générées à partir de la description de la balise et git notesattachées aux validations de jalons importants.

— Jörg W Mittag

Mon point est que la balise devrait être créée avant la sortie afin que les validations soient correctement versionnées avec un numéro de base. Cela va à l'encontre du principe du marquage pendant ou au moment de la publication. Bamboo récupère automatiquement les builds en fonction des validations vers master(de develop, rappelez-vous que j'utilise gitflow). Et si quelqu'un pousse une fusion mastersans tag? Il n'utilisera pas la version appropriée (en fait, il utiliserait la version de la dernière version)

— void.pointer

Si vous utilisez un schéma comme celui-ci, le balisage est en cours de publication. Ah, je vois où tu veux en venir, je pense. Donc, actuellement, votre serveur CI est le pilote de version, et avec ce changement, le SCM est le pilote de version, mais vous souhaitez qu'il reste tel quel?

— Jörg W Mittag

Oui. Il est recommandé de conserver la plupart du numéro de version dans vcs. Si nous considérons le versioning sémantique semver.org où nous avons major.minor.patch.build, les trois premiers doivent vivre en vcs. Le dernier peut être un nombre incrémenté de votre serveur de build utilisé pour revenir en arrière sur la validation spécifique à partir de laquelle un binaire est créé.

Pour faciliter cela dans .NET, nous avons créé un petit exe de ligne cmd qui s'est engagé à git. Avec un événement pré-build, il récupère le numéro de build que teamcity a tagué pendant la build. Cet outil de ligne cmd génère automatiquement une classe avec une constante contenant le numéro de build. Le reste du numéro de version: major.minor.patch n'est qu'une constante normale dans un autre fichier. Ces deux fichiers partagés sont inclus dans chaque assemblage d'une solution sous forme de lien (alt + shift-glisser).

Cette approche est suffisamment puissante pour que nous puissions créer et tester notre code teamcity. Poussez vers azur et demandez à kudu de le reconstruire, mais avec le numéro de build teamcity comme version des DLL.

— Esben Skov Pedersen
source