Toute la confusion provient des différentes sémantiques que MS utilise pour "Numéro de construction" et en particulier "Révision". Les termes signifient simplement différentes choses.
La plupart des gens (moi-même inclus) utilisent un schéma de numérotation de version sémantique dans lequel vous obtenez simplement un numéro BUILD plus élevé chaque fois que vous devez créer une nouvelle version pour une raison quelconque. Pour nous, un correctif est considéré comme un simple changement de code et la partie BUILD augmente automatiquement à chaque exécution de CI. Les modules ayant le même MAJ.MIN.REV sont considérés comme interchangeables et le BUILD vous indique lequel est le plus récent.
Incrémenter REVISION, cependant, indique une nouvelle branche de publication permanente, c'est pourquoi nous la plaçons avant BUILD. L'inconvénient de cette approche est que nous pourrions obtenir la séquence d'événements suivante:
- numéro de commit 4711: ajout de la fonctionnalité A par Alice
- CI produit la version 1.2.3.100
- numéro de commit 4712: fonctionnalité modifiée par Bob B
- numéro de commit 4713: fonctionnalité fixe Alice A (le "correctif")
- CI produit la version 1.2.3.101
Comme vous pouvez le constater, le correctif logiciel n'est pas le seul changement contenu dans la prochaine version, la modification de Bob en fait également partie. Si vous souhaitez stabiliser la branche actuelle, vous risquez de rencontrer des problèmes, car vous ne pouvez jamais savoir avec certitude si Bob a simplement ajouté un tas de bugs.
MS utilise les deux termes différemment. Le numéro BUILD n’est pas automatiquement incrémenté; on peut plutôt le considérer comme une sorte de branche de publication, afin de geler le code utilisé pour une version particulière du code. La REVISION indique des modifications "à chaud" supplémentaires appliquées à cette branche BUILD. La séquence serait donc la suivante:
- numéro de commit 4711: Alice a ajouté la fonctionnalité A au trunk / master
- Carl crée une branche de construction
1.2.100
- CI produit la version 1.2.100.0
- numéro de commit 4712: Bob modifié fonctionnalité B dans le coffre / maître
- numéro de commit 4713: fonctionnalité fixe Alice dans la
1.2.100
branche
- CI produit la version 1.2.100.1
Le terme REVISION peut désigner
- une révision de produit (c'est comme ça que la plupart des gens l'utilisent)
- une révision d'un build quotidien particulier (c'est ce que fait MS)
La principale différence entre les deux processus réside dans le fait que vous souhaitiez ou non pouvoir appliquer des correctifs aux générations de CI et par conséquent à quel moment du processus la branche est créée. Cet aspect devient important lorsque vous souhaitez pouvoir sélectionner une version particulière à tout moment une fois tous les tests réussis et promouvoir exactement cette version dans la prochaine version officielle de votre produit.
Dans notre cas, l’outil CI crée une balise de référentiel, nous avons donc toujours les informations nécessaires prêtes à être utilisées, le cas échéant. Avec SVN, cela devient encore plus simple, car les balises et les branches sont mises en œuvre exactement de la même manière - une balise n’est autre chose qu’une branche située sous /tags
.
Voir également
Dans la section FAQ de la stratégie de création de branche TFS :
Dans quelle succursale dois-je réparer le ticket P1 (correctif)?
Le fichier P1 doit être corrigé dans la branche la plus proche de la base de code exécutée dans Production. Dans ce cas, le P1 doit être fixé dans la branche Prod. En appliquant le correctif dans toute autre branche et en appliquant les modifications apportées à la production, vous risquez de libérer du code semi-fini ou non testé lors des itérations suivantes.
Vous pouvez maintenant affirmer que s'il est sûr de travailler directement avec la branche Prod, détrompez-vous, un P1 qui requiert une attention immédiate ne devrait pas être un problème fondamental du système. S'il s'agit d'un problème fondamental, il convient de l'ajouter au carnet de produit car il peut nécessiter une analyse plus approfondie et une discussion avec le client.
Une autre bonne lecture est le guide de branchement TFS