meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:dat [2026/08/01 17:57] – [Gestion des sources et des versions] nicolascertif:dat [2026/08/11 14:34] (Version actuelle) – [Gestion des sources, des versions et dépôt] nicolas
Ligne 41: Ligne 41:
  
 ==== Gestion des sources, des versions et dépôt ==== ==== Gestion des sources, des versions et dépôt ====
 +
 Le code source est hébergé sur **GitLab**, qui a totalement remplacé l'ancien dépôt SVN. Les développeurs interagissent avec le dépôt via le client graphique **SourceTree**. Le code source est hébergé sur **GitLab**, qui a totalement remplacé l'ancien dépôt SVN. Les développeurs interagissent avec le dépôt via le client graphique **SourceTree**.
-La stratégie de branches suit un modèle **une branche par version** : chaque nouvelle version du logiciel est développée sur une branche dédiée. Lors de la mise en ligne (déploiement en production) d'une version, le numéro de version est incrémenté, formalisant le passage à la version suivante. Tous les clients sont maintenus sur la dernière version **Release** ; des écarts mineurs de **Build** peuvent exister suite à des correctifs ciblés (cf. [[certif:procedure:develop:gestionversion|procédure #06]]).+ 
 +La stratégie de branches suit un modèle **une branche par version** : chaque nouvelle version du logiciel est développée sur une branche dédiée. Lors de la mise en ligne (déploiement en production) d'une version, le numéro de version est incrémenté, formalisant le passage à la version suivante. Tous les clients sont maintenus sur la dernière version **Release** ; des écarts mineurs de **Build** peuvent exister suite à des correctifs ciblés. 
 L'usage de Git constitue également la méthode retenue pour répondre à l'exigence de preuve d'authenticité du logiciel audité (art. 4.3.6 "Dépôt des sources et preuve d'authenticité du logiciel audité") : à défaut de dépôt des sources auprès d'un tiers, chaque commit est identifié par une empreinte cryptographique (hash SHA) calculée sur l'ensemble du contenu et de l'historique, figeant de façon incontestable l'état exact des sources à un instant donné. Lors d'un audit, l'empreinte du commit correspondant à la branche de la version auditée peut être communiquée à l'organisme certificateur pour vérification de l'authenticité et de l'intégrité du code. L'usage de Git constitue également la méthode retenue pour répondre à l'exigence de preuve d'authenticité du logiciel audité (art. 4.3.6 "Dépôt des sources et preuve d'authenticité du logiciel audité") : à défaut de dépôt des sources auprès d'un tiers, chaque commit est identifié par une empreinte cryptographique (hash SHA) calculée sur l'ensemble du contenu et de l'historique, figeant de façon incontestable l'état exact des sources à un instant donné. Lors d'un audit, l'empreinte du commit correspondant à la branche de la version auditée peut être communiquée à l'organisme certificateur pour vérification de l'authenticité et de l'intégrité du code.
-NB : la [[certif:procedure:develop:gestionsvn|procédure #30]], qui décrit encore l'ancien processus SVN, doit être mise à jour ou remplacée par une procédure GitLab.+ 
 +**Pour en savoir plus : [[certif:questionnaire:procedure:develop:gestionversion]]**