meta données pour cette page
Ceci est une ancienne révision du document !
 Retour au Dossier Organisationnel |
|
 Sujets connexes | Cartographie fonctionnelle de LoGeAs Procédure de gestion des versions de LoGeAs (procédure #06) Procédure de dépôt des codes sources (procédure #09) |
Procédure de versionning des codes sources (procédure #30)
Informations qualité
| Suivi des modifications majeures | été 2026 - Nicolas Marchand - migration sur Git 03 Décembre 2015 - Guillaume Natali- Création |
| Suivi des approbations | Cartographie fonctionnelle |
| Objet | L'objet de ce document est de définir l'action à mener pour enregistrer les versions du logiciel dans l'entrepôt. |
| Destinataires | - Validation des modifications : Gérant - Approbation du document : Equipe DEV |
Objet
Cette procédure décrit les actions à mener pour enregistrer une version du logiciel dans le dépôt de code source (GitLab), en garantissant son identification unique et son authenticité.
Prérequis
- Les développements de la version sont finalisés et mergés sur la branche dédiée.
- Le numéro de version (Majeur.Mineur.Release.Build) a été déterminé conformément à la procédure #06.
Étapes
- Vérification de la branche : s'assurer que la branche GitLab correspondant à la version contient l'ensemble des commits validés pour cette livraison.
- Étiquetage (tag) : créer, via SourceTree, un tag Git sur le dernier commit de la branche, nommé selon le numéro de version (ex. v11.0.3.1).
- Publication du tag : pousser (push) le tag vers le dépôt distant GitLab, afin de le rendre visible et immuable pour l'ensemble de l'équipe.
- Relevé de l'empreinte : noter le hash SHA du commit tagué — cette empreinte constitue la preuve d'authenticité de la version (cf. Gestion des sources, des versions et dépôt dans le DAT).
- Archivage : conserver la référence du tag et de son empreinte dans le suivi de version associé (cartographie fonctionnelle).