OK Pascal, dis moi...
(Mon petit wiki sur la toile)

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== DO178B/DO254 et "subversion" ======

Utilité du gestionnaire de version "Subversion" pour des développements DO178B et DO254

Parution initiale : 25 juillet 2009

=====Prérequis=====

L’application des normes RTCA/EUROCAE DO-178B/ED-12B et DO-254/ED-80 en développement logiciel et électronique par une équipe de développeurs nécessite un suivi des modifications des codes sources et autres documents de gestion de projet.
Un gestionnaire de version concurrentiel permet de simplifier cette gestion.

Cette page présente les avantages qu'apporte le gestionnaire de configuration "subversion" à de tels développements, sans présenter de "solution clé en main" (je n'ai rien inventé de particulier, cette page n'est qu'un regroupement d'informations et possibilités). Libre à chacun de s'inspirer des idées évoquées ici.

=====Besoins DO254/DO178=====
Ces normes imposent la gestion des révisions et contrôle des modifications sur les éléments suivants :
  * code source,
  * rapports de revues,
  * documentation,
  * spécifications,
  * tests et résultats de tests,
  * procédures de réplication,
  * rapports d’anomalies,
  * plans des cartes électroniques concernées,
  * outils de développement.

Chaque élément est géré suivant une « Control Category » :
    * CC1/HC1, changements « incrémentaux » des éléments design (changement des données par petites portions de façon continue dans le temps),
    * CC2/HC2, une gestion par écrasement des anciennes données,
Les données doivent être obligatoirement archivées,
Les données ne sont pas obligatoirement diffusées.

Parfois une indépendance entre les équipes de développement et test est demandée. Il faut alors s’assurer que les versions testées sont figées, et qu’elles puissent être récupérées à tout instant par l’équipe de test. Les tests et leurs résultats pour chacune des versions de développement testées doivent figés, enregistrés, et éventuellement récupérés par la suite.

Cette gestion doit se faire pour toute configuration du produit testée, qualifiée ou produite.

Certaines exigences de suivi de configuration de ces normes sont déjà incluses dans d'autres normes moins spécifiques (type ISO9001:2000 et surtout AS/EN9100), et peuvent donc être couvertes par les procédés d'assurance qualité quand ils existent. Ces procédés d'assurance qualité peuvent aussi bénéficier des avantages d'un système de gestion de versions.

=====Définition d’un « gestionnaire de version »=====
Un gestionnaire de versions est un outil permettant de conserver les versions successives d'un même document. Il est essentiel dans au moins deux activités qui nous intéressent : 
    * Le développement de code, 
    * La gestion documentaire. 
Conserver des versions successives signifie au moins deux fonctionnalités : 
    * Mémoriser l'état d'un document à un instant t. L'enregistrement d'une version s'accompagne en général de méta-données comme : un commentaire, une date etc. 
    * Retrouver l'état d'un document à un instant ancien.

À l'aide de ceci, on peut construire différents services complémentaires comme 
    * donner les différences entre deux versions, 
    * afficher la liste des modifications entre deux versions, 
    * afficher l'historique d'un document etc. 

Une fonctionnalité supplémentaire classe les gestionnaires de versions en deux catégories : 
    * les gestionnaires de versions concurrents qui supportent bien l'usage par plusieurs - différents utilisateurs, le plus souvent à travers un réseau, qui travaillent en même temps sur les mêmes documents. 
    * les autres réservés à un seul utilisateur voire plusieurs utilisateurs mais jamais simultanément. 

====Gestionnaires de versions sans concurrence====

Des logiciels comme Word ((il semble que cette fonction ai été supprimée dans Office 2010, à date de rédaction en 2020, Office 365 semble posséder quelques options sur ce sujet)) ou OpenOffice.org/LibreOffice.org intègrent aussi des gestionnaires de version. Il est possible de les tester en réalisant les manipulations suivantes : 
    * Créer un document et l'enregistrer. 
    * Dans le menu Fichier/Versions enregistrer une nouvelle version 
    * Apporter des modifications, et enregistrer à nouveau. 
    * Voir les effets lors de l'enregistrement d'une nouvelle version 
Ils permettent aussi de suivre les modifications apportées à un document en cours d'édition, et de fusionner des documents.

==== Entre deux gués... ====
Microsoft Sharepoint permet dans une certaine mesure la modification simultanée par plusieurs utilisateurs, et un contrôle d'accès. Owncloud/Nextcloud sont assez similaires.
Par rapport à un gestionnaire de versions, la différence majeure est que ces systèmes peuvent **oublier** les anciennes versions.

  * Sharepoint dans sa version de 2012 environ :
Les contrôles d'accès étaient précis, à la manière de l'explorateur de fichiers : gestion par utilisateur, par groupes et par fichier et répertoire. L'interface était un peu lourde.

La modification simultanée par plusieurs utilisateurs était possible, il fallait alors gérer les écrasements et les conflits sur les fichiers.

  * Sharepoint depuis sa version de 2015 environ :
le contrôle d'accès a été très simplifié, il apparaît très compliqué de gérer des accès différents d'un répertoire à un autre pour un grand nombre d'utilisateurs (exemple accès interdit à "brouillon" et autorisé en lecture seule au répertoire "en production". D'autre part de mon expérience il est très difficile de supprimer l'accès octroyé à un fichier.

Le seul moyen de contourner cela est de travailler sur des espaces Sharepoint différents, ce qui implique une duplication du volumes de données, et quelqu'un pour réaliser les copies...

Les modifications sont tracées, il est possible de suivre les différentes versions d'un fichier. Cette fonction a cependant une limite, dès que le fichier est supprimé suffisamment de temps, tout l'historique est perdu. L'édition simultanée des fichiers en mode collaboratif peut être appréciable.
====Gestionnaires de versions avec concurrence====

Plusieurs logiciels permettent à plusieurs utilisateurs de travailler simultanément sur les mêmes documents en mémorisant les versions successives.
Ces systèmes sont indispensables pour les projets mettant à contribution de nombreux utilisateurs ou développeurs comme par exemple les projets open source.

On peut citer parmi les logiciels libres : 
    * cvs : le plus ancien et très répandu 
    * svn (subversion) : développé pour remplacer cvs et certaines de ses limitations, c'est un système centralisé sur un serveur
    * arch : supporté par le projet gnu, mais peu répandu sur plateforme Microsoft. 
    * git : un système décentralisé, permettant à chacun de récupérer l'intégralité des données, que j'apprécie pour les développements

Svn existe maintenant depuis quelques années, possède une large publicité et documentation sur l'Internet, et est très bien intégré dans MS Windows Explorer une fois le logiciel libre TortoiseSVN installé.
D'autres interfaces graphiques existent pour les systèmes Linux (par exemple).

La présentation est donc orientée sur SVN+TortoiseSVN, mais bien sur les concepts de la gestion de version restent similaires de l'un à l'autre des logiciels.


====Le référentiel====

L'accès simultané aux documents suppose la définition d'un référentiel : c'est l'endroit où seront enregistrés les documents, leurs versions, les méta-données les accompagnant. Les utilisateurs ne travaillent jamais directement dans le référentiel. Ils demandent des copies et les manipulent dans un répertoire de travail. Ils soumettent ensuite leurs modifications pour enregistrer une nouvelle version dans le référentiel.
Les éléments situés dans le référentiel sont les « ressources » (ou URL).
Les copies des ressources par l'utilisateur sur son poste de travail sont les « copies locales »

====Présentation de « subversion »====

Subversion est un système de gestion de versions avec concurrence.
Il permet de gérer n’importe quel type de document.

Il repose sur différents éléments :
Sur le serveur informatique contenant le référentiel :
    * svnserve : le service logiciel qui gère les accès des utilisateurs au référentiel
    * svnadmin : l'outil d'administration des référentiels (création, maintenance)
    * un répertoire sur le disque du serveur, qui content la base de données (et donc les données), Il ne faut pas manipuler ce répertoire, car il s'agit d'une base de données, et les données n'y sont pas « en clair ».

Sur le poste des utilisateurs :
    * svn : il gère les accès avec svnserve, via l'utilisation d'URL et de la ligne de commande,
    * un outil « graphique » pour éviter l’usage de la ligne de commande. TortoiseSVN est l'un de ces outils.

En tant que système de gestions de versions, subversion permet (commandes svn en italiques) :
    * création de ressources à partir de données locales (//import//, //add//)
    * récupération de ressources pour archivage //export//,
    * récupération de ressources pour travail //checkout// – création d'une copie locale d'une ressource,
    * puis validation des modifications effectuées //commit//,
    * synchronisation des copies locales par rapport aux ressources //update//,
    * gestion des métadonnées et verrous sur les ressources,
    * copie, déplacement, et effacement des ressources à l'intérieur du référentiel //move//, //copy//…,
    * gestion des droits d'accès (lecture, écriture) sur chaque ressource, en fonction des utilisateurs,
    * lors de toute opération de modification du référentiel, leur auteur est identifié, et il est possible d'indiquer le motif de la modification. Cette possibilité peut être rendue obligatoire.

    * //checkout// et //commit// sont les opérations les plus utilisées (récupération de ressources, modification et validation.

====Métadonnées====

Des métadonnées (mots clefs) peuvent être associées à chaque ressource. L'évolution de ces métadonnées est aussi « versionnée ». Elles sont particulièrement utilisées pour indiquer les corrections de bugs.

====Verrous====

Les verrous sont un type de métadonnée. Ils permettent à un utilisateur de verrouiller des ressources dans le référentiel, indiquant aux autres utilisateurs que modifier ces ressources n'est pas souhaitable car un travail est en cours.
Attention, il est possible de passer outre les verrous, et de les « voler », de telles possibilités peuvent être éliminées par légère reconfiguration de subversion.

====TortoiseSVN====

Il permet l’accès à toutes les fonctions de SVN via menu contextuel dans l'explorateur Windows (dossiers, fichiers).
L'état de mise à jour des fichiers est indiqué par une icône dans la fenêtre de l’explorateur.
Il est possible d'obtenir un historique des révisions d'une ressource dans le temps, et aussi sous forme de graphe, ce qui permet d'identifier les origines et dépendances entre versions et projets.
Possibilité « d'explorer » un référentiel via son URL : svn\\serveur\nom_référentiel

====Exemple d'utilisation (svn + TortoiseSVN)====

On suppose que le projet en question contient 3 modules, 1 cahier des charges, 1 revue de validation.
On suppose que lors de l'utilisation des opérations suivantes ''add'', ''commit'', ''copy'', les utilisateurs en question indiquent à SVN la raison des opérations effectuées.

  * 1) Création d'un référentiel « PROJETS » par l'administrateur et de droits d'accès types :
    * répertoire « */encours » en lecture/écriture pour l'équipe de développement
    * répertoire « */à valider » en lecture/écriture pour l'équipe de développement
    * répertoire « */Validé » en lecture/écriture uniquement pour le chef de projet
    * répertoire « */Production » en lecture seule pour la production, et en lecture/écriture pour le chef de projet

Configuration du référentiel : voir la rubrique « administration »

  * 2) Chef de projet (CP) crée un répertoire « PROJET1 » sur son disque local, tel qu'indiqué (droits d'accès entre parenthèses, qui sont prédéterminés dans le serveur) :
    * PROJET1/
      * encours/
      * à valider/
      * Validé/
      * Production/

  * 3) Le chef de projet « importe » ce répertoire dans le référentiel. Le référentiel est désormais à l'indice 1.
  * 4) Le cahier des charges est placé par le chef de projet dans le référentiel et le répertoire « Validé ». 

Pour cela il doit d'abord créer une copie locale du référentiel (''checkout''), y placer son cahier des charges, ajouter ce fichier au contrôle de version (''add'') et ensuite valider le document (''commit'') ((Si c'est le répertoire « Validé » qui est validé en entier, il n'est pas nécessaire d'utiliser la fonction « add » pour chaque fichier, la fonction « commit »  du répertoire dans son ensemble suffit.)). Version référentiel = 2

  * 5) Le développeur 1 (DEV1) crée une copie contrôlée du dossier « PROJET1 » sur son disque (''checkout'').
  * 6) Il crée le module 1 du projet dans « encours », et l'ajoute au gestionnaire de version (''add'').
  * 7) Il valide ensuite son module (''commit''). Référentiel indice 3.
  * 8) Le développeur 2 (DEV2) crée aussi une copie contrôlée du dossier « PROJET1 » sur son disque.
  * 9) Il crée le module 2 du projet dans « encours », et l'ajoute au gestionnaire de version (''add'').
  * 10) Le développeur 1 ajoute un 3ème module (''add'', et ''commit''). Référentiel indice 4.
  * 11) Le développeur 2 met à jour sa copie locale (''update'')
  * 12) Le développeur 2 vérifie son travail et ajoute le 2nd module (''commit'')
  * 13) Le travail est alors considéré prêt à être validé. Le développeur 1 en place une copie dans le répertoire "PROJET1\à valider" du référentiel,
  * 14) Le projet est validé par une réunion. Le chef de projet récupère donc une copie locale des éléments du projet : code source des modules, cahier des charges, et compte rendu de validation. Ces éléments sont placés dans un nouveau répertoire du référentiel "PROJET1\validé\PROJET1 version 1\",
  * 15) Le projet 1 en version 1 est mis en production. Le chef de projet créé donc une copie du projet 1 version 1 dans le répertoire "production" du référentiel.

====Questions tests====

Que contient la copie du développeur 2 suite à l'étape 11) ?

Quel est l'indice du référentiel suite à l'étape 14) ?

====Remarque====

Dans l'exemple donné ici, il y a une faille. Par erreur, ou précipitation, le chef de projet peut déplacer les données directement dans le répertoire de production. Cela peut-être pallié en ajoutant des utilisateurs "différents" au référentiel pour chaque étape de contrôle, chacun de ces utilisateurs ayant juste les droits d'accès nécessaires pour valider une seule étape.

=====Fonctions SVN vs. Besoins DO178B/DO254=====
Les normes DO254 et DO178B contiennent une table décrivant les catégories de contrôle pour chacun des objectifs de suivi de configuration. La table ci-après en est un résumé.
    * CC1/HC1 : suivi des changements incrémentiels
    * CC2/HC2 : suivi des changements par écrasement

(M) indique dans le tableau ci-dessous les opérations manuelles.
(A) indique les opérations automatisées.


**Exigences DO178B/DO254 et fonctions SVN, table résumant les avantages de SVN par rapport aux exigences DO178B/DO254**

^ DO178B ^ DO254 ^ Objectif du processus de gestion de configuration matériel ou logiciel ^ C1 ^ C2 ^ Gestion via système de fichier classique ^ Gestion via SVN ^
| X | X | Identification de configuration | X | X | (M) Listing du contenu des versions validées | (A) Listing d’une révision du référentiel |
| X | X | Spécifications | X |  | (M) Enregistrement manuel de toutes les révisions | Document intégré au référentiel / Meta-tags |
| X | X | Traçabilité | X | X | (M) Enregistrement manuel de toutes les révisions | Document intégré au référentiel / Meta-tags |
| X | X | Rapports d’anomalies | X |  | (M) Enregistrement manuel de toutes les révisions
| Document de suivi intégré au référentiel / Meta-tags |
| X | X | Intégrité et identification de la gestion des modifications | X | X | (M) Indication manuelle lors de chaque modification | (A) Commentaires et Historique |
| X | X | Suivi de la gestion des modifications | X |  | (M) Enregistrement manuel de toutes les révisions | (A) Historique |
| X |  | Revues des modifications | X |  | (M) Enregistrement manuel de toutes les révisions
| Rapports de revues intégrées au référentiel |
| X |  | Suivi des états de configuration | X |  | (M) Enregistrement manuel de toutes les révisions | (A) Historique |
| X | X | Mise à disposition | X |  | (M) Répertoire en lecture seule | (A) Copy |
| X | X | Restauration | X | X | (M) Sauvegarde sur un autre support | (A) Export / Checkout |
| X | X | Conservation des données | X | X | (M) Sauvegarde sur un autre support | Sauvegarde référentiel / Export |
| X | X | Protection contre les modifications non autorisées | X | X | (M) Protéger en écriture les versions validées | Droits d'accès / Annulation des opérations non autorisées |
| X | X | Choix des supports, rafraîchissement, copie | X |  | Assurance qualité | Sauvegarde référentiel / Export |

Les avantages de SVN pour une gestion en DO254 HC2 : suivi des documents tels que les cahiers des charges, et le suivi des modification automatique. Il y a en plus un aspect sécurité, car toute action peut être retracée, alors qu'un effacement d'un fichier sur un système de fichier classique peut s’avérer catastrophique.

En HC1, les gains sont encore supérieurs à cause des changements « incrémentiels » qui alourdissent encore le process de gestion suivi et validation des modifications.

=====Administration d’un référentiel=====
Seules les tâches les plus courantes sont listées ci-après.

====Configuration des droits d’accès :====

Édition dans un éditeur de texte des fichiers suivants dans le sous-répertoire « \conf\ » du répertoire du référentiel :
        * ''svnserve.conf'' : configuration du dépôt
        * ''passwd'' : utilisateurs et mots de passe
        * ''authz'' : droits d’accès par répertoire

Ces fichiers sont commentés, et leur édition ne pose pas de problème particulier.

====Sauvegarde :====
Commande ''export'' (pour sauvegarder une révision particulière), ou copie intégrale du répertoire contenant le référentiel (après avoir arrêté le serveur svn). Il existe aussi la commande ''svnadmin hotcopy'' pour dupliquer intégralement un référentiel.

====Ménage (espace disque) :====

  * Les fichiers « log » : Ils peuvent être retirés lorsqu’ils ne sont pas utilisés. Voici la commande pour obtenir la liste des « logs » non utilisés :
    ''svnadmin list-unused-dblogs /référentiel''

La commande ''svnadmin hotcopy'' réalise une copie à l’identique du référentiel, en supprimant tous les fichiers « logs ».

  * Suppression de ressources :
Tel que le site SVN l’indique, la suppression est possible MAIS, tel qu’indiqué par ses concepteurs : 
> SVN est délibérément conçu pour ne jamais perdre d’information. Les révisions sont des arbres immuables, greffés les uns sur les autres. Retirer une révision pourrait causer un effet « domino », résultant en un chaos dans tous les révisions qui lui sont consécutives, et pouvant donc invalider toutes les copies de travail.

Si toutes les précédentes révisions d’un référentiel (dans son ensemble) sont inutiles, il est donc conseillé d’exporter le référentiel, de le supprimer du serveur, et d’en recréer un à partir de la sauvegarde.

=====Sites à consulter pour davantage de précisions=====
Des sites officiels :
    * [[https://subversion.tigris.org/|Site officiel de Subversion]]
    * [[http://tortoisesvn.net/docs/release/TortoiseSVN_fr/|Documentation de subversion en français]]

Des sites parlant des thèmes abordés :
    * [[https://fr.wikipedia.org/wiki/DO-178|DO-178 sur Wikipedia]]
    * [[https://fr.wikipedia.org/wiki/Apache_Subversion|Subversion sur Wikipedia]]