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:

1. 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.).

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

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.

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.