Gestion des versions dans un environnement d'intégration continue

Question

Comment gérez-vous les versions dans un environnement d'intégration continue comportant une branche de développement et une branche de version? J'utilise git donc il n'y a pas de version de dépôt incrémentielle à utiliser. On dirait qu'il y aura des versions qui se chevauchent comme 1.1.0 sur la branche dev et 1.1.0 sur la branche release. Est-ce que vous venez d'ajouter le texte "dev" ou "release"?

De même, lorsque vous créez une branche de publication, incrémentez-vous immédiatement la branche de développement au numéro de version "proposé" suivant? Vous ne connaissez peut-être pas encore le prochain numéro de version, mais si vous ne l'incrémentez pas, alors vous avez 1.1.0 dev contenant un nouveau travail non inclus dans la version 1.1.0. Donc, ma question principale est quelle est la relation dans les séquences de versions entre ces deux branches? N'oubliez pas, je ne vous demande pas comment décider des numéros de version à utiliser. J'ai essayé de demander ceci avant et ai continué à recevoir des commentaires comme "incrément majeur pour briser des changements" etc.

Answer 1

Je ne versionne pas la branche de dev. Le devline est le tronc et je branche périodiquement de dev à un nouveau dossier de version. Ainsi, la branche de publication est pleine de dossiers qui sont essentiellement des instantanés de la déviation.

IE, sous la racine j'ai/dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.

Je ne sais pas si cela répond vraiment à votre question.

Answer 2

Je vous recommande de définir une activité finale pour votre environnement CI pour créer des tags. Je crois que la commande git ressemble à ceci: git tag -a nommer

Nous utilisons Major.Minor.Release.BuildNumber

bien que certains endroits utilisent Major.Minor.Release.CheckinNumber

Donc, si vous vouloir utiliser cela alors je voudrais version votre branche de développement, sinon juste la version de la branche de sortie.

Answer 3

Si vous ne disposez que d'une branche de développement, il est plus efficace d'en faire le tronc et la branche d'une branche de publication à chaque fois que vous voulez simplement stabiliser pour la publication. Si vous avez plusieurs projets de fonctionnalité, vous pouvez avoir une branche pour chacun d'entre eux avec la configuration de CI sur ceux-ci. Une fois qu'ils ont terminé, vous les fusionnez un par un dans le tronc et une fois que tous sont fusionnés, vous arrivez au premier scénario, où vous branchez à nouveau une branche de relâchement du tronc.

Dans tous les cas, vous ne gardez pas la branche de développement entre les versions. Vous voulez le terminer et en commencer un nouveau pour le développement de la prochaine version. De cette façon, certaines fonctionnalités peuvent être bifurquées pendant plusieurs versions si elles prennent plus de temps. Mais aussi vous n'avez pas trop de désordre sur vos branches de développement.

Vous pouvez ramifier les branches de développement pour la prochaine version dès que vous avez dérivé la branche de publication ou même avant si vous le souhaitez, mais il est généralement préférable de fusionner les modifications de la branche de publication vers le coffre. et de là dans les branches de développement si vous faites cela. Si vous attendez avec la dérivation après la libération, vous évitez quelques fusions là, mais vous ralentissez le développement.