Construire le versioning en livraison continue
J'ai des questions concrètes sur le versioning dans la livraison continue. Je pense que je comprends le flux de travail global qui est plus ou moins ceci:
1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment
Et le versioning? Comment gérer les versions de build?
Disons que nous travaillons sur un projet basé sur Maven avec le versionnage sémantique: major.minor.build.
Lorsque le développeur valide les modifications apportées au serveur VCS et CI pour effectuer une génération, le serveur CI doit-il incrémenter la version de génération et créer une balise dans VCS?
Cette version de build est-elle présente dans le code source? Si c'est le cas, après chaque Push to VCS, le développeur doit mettre à jour le projet, car le serveur CI a validé les modifications (incrément de version) sur le projet.
Je suis un peu confus et j'aimerais comprendre le flux de travail du CD de manière pratique.
En général, vous devriez avoir:
- Un numéro de version géré manuellement.
- N'importe quel nombre de numéros de "référence".
Le premier point est crucial si vous vous souciez de semver ou si vous devez fournir des informations de compatibilité pour d'autres outils/bibliothèques. C'est seulement vous qui pouvez dire si une nouvelle "version" casse quelque chose - le système d'indication le plus populaire suit les règles de version de semver.
Le deuxième point (numéro de "référence") peut ou non être important pour vous. Vous n'avez généralement pas besoin de plus d'un, le numéro de version de la build CI/CD (chaque service CI/CD populaire a un ID de numéro de version de build qui fait référence à cette "build" spécifique). Le point de ce nombre est que vous pouvez rapidement vérifier la construction/les journaux CI/CD associés d'un artefact si vous en avez besoin.
Comment fusionner les deux (ou plus) parties?
Il n'est pas rare d'avoir des numéros de "version" et de "build" séparés. En fait, tous les projets iOS ont cela par défaut. Dans ce cas, le numéro de "version" est géré manuellement et un numéro de "build" distinct est géré automatiquement. Le numéro de build peut être au nom de l'artefact, ou peut être imprimé lorsque quelqu'un récupère les informations --version Dans le cas d'un binaire (ex: $ brew info -> 0.9.5 (git revision 18c48; last commit 2015-11-02)
Alternativement, vous pouvez soit ajouter de nouveaux composants à semver (x.x.x.BUILDNUM), Utiliser le dernier composant de semver (x.x.BUILDNUM - Je ne le recommanderais pas si vous avez un BUILDNUM strictement incrémentiel ) ou incluez simplement le numéro "build" dans le nom de l'artefact.
Ce sont toutes des possibilités, vous devrez choisir la meilleure pour votre cas. Vous devez définir la signification de ces numéros et décider où le numéro doit être présenté (par exemple, doit-il faire partie d'un appel --version Ou doit-il simplement faire partie du nom de fichier).
edit : pour réfléchir à votre question sur "le serveur CI doit-il incrémenter la version de build et créer une balise dans VCS?" - Je ne recommanderais jamais ça. Un serveur CI peut également avoir des problèmes, vous ne devez jamais modifier votre code à partir d'un processus CI. L'écrasement accidentel (par exemple, une poussée forcée) peut être très dangereux. C'est pourquoi il est préférable d'utiliser simplement le numéro de build exposé par le service CI/CD.