formation sourcesup base - renater · fichiers php et autres ! utilisez un éditeur qui colorise !...

Découverte des technologies de la forge Formateur : Sébastien Médard

Forma&on CIREN SourceSup – Mars 2016 1

Formation SourceSup - Base

31/03/16

RENATER

•  Opérateur réseau enseignement et recherche •  Sécurité

–  Le CERT RENATER –  Animation réseau des RSSI –  Certificats TCS –  Fédération Education-Recherche

•  Services applicatifs –  Eduroam, eduspot –  RENAvisio, Rendez-vous –  Universalistes, FileSender, Partage, Antispam –  Sympa, Sourcesup

Forma&on CIREN SourceSup – Mars 2016 2 31/03/16

RENATER

•  Autres activités –  Formations (Fédération, IPv6, Sympa) –  Organisation des JRES –  Relations internationales (GEANT, TERENA)

•  En savoir plus –  http://www.renater.fr

•  Newsletter de RENATER –  https://listes.renater.fr/sympa/info/renater-actualites

•  Contact –  [email protected]


Déroulement de la formation


La formule

•  2 jours –  Jour 1 : Subversion + Tests + Bugs –  Jour 2 : Git + Intégration continue + Qualité de code

•  Fonctionnement –  TP par binômes –  Entrecoupé par des présentations

•  Objectif –  Comprendre les principes de base de ces outils –  Présenter la forge


Timing

•  jeudi 16 mars : –  9h30-12h –  14h-17h

•  vendredi17 mars –  9h30-12h –  14h-17h


Les postes de travail

•  Postes seront numérotés au début du premier jour •  XXX = 11->20

•  Environnement •  CentOS 6.5

•  Comptes •  eleveX / cirenunx

•  Root / cirenadmin


Le support de formation https://services.renater.fr/sourcesup/

formation/index


l  La forme l  Wiki avec une variable (XXX pour le numéro du poste) l  Permet le copier/coller l  Si rechargement de la page

l  => ressaisir le numéro du poste

l  éditeur de texte l  fichiers PHP et autres l  utilisez un éditeur qui colorise

l  vim, emacs ou komodo edit

31/03/16

Le tour de table…


La plateforme SourceSup


Service SourceSup

•  Opéré par RENATER depuis 2004 •  Basé sur FusionForge v 5.3 •  Ouvert à toute la communauté Enseignement

supérieur et Recherche –  Via la fédération d’identité Education-Recherche

•  Ainsi qu’aux externes grâce aux comptes CRU –  Ils peuvent collaborer sur un projet –  Seule restriction, ils ne peuvent créer de projet

•  5757 utilisateurs travaillent sur 1772 projets actifs


Service SourceSup

•  Outils présents sur la forge sous forme de plugins –  Bug tracker (intégré, Mantis) –  Forum –  Gestionnaire de tâche (gestion de projet) –  Gestionnaires de sources (SVN/Git) –  Wiki (dokuwiki) –  Listes de diffusion (Sympa) –  Intégration continue (Jenkins, Sonar et Nexus) –  Nuxéo (GED)


Pages personnelles

•  « mon compte » –  Liste /ajoute les clés SSH –  Récupération de mot de passe –  Présence du nom du compte (= login utilisé pour SVN)

•  « ma page » –  Personnalisable, ensemble de ‘widgets’ donnant un aperçu des

éléments concernant l’utilisateur •  Tableau de bord de suivi

–  Tous les bugs/tâches de tous les projets dont fait parti l’utilisateur

•  Enregistrement d’un projet –  Forcément rattaché à un établissement –  Extraction des établissement de PASS à la prochaine version de

la forge


Gestions des droits

•  Chaque projet utilise 5 rôles prédéfinis •  Chaque rôle possède un ensemble de

permissions –  Donnent des droits sur les différents outils de la forge

•  Des rôles spéciaux –  ‘Tout utilisateur connecté’

•  Donne des droits aux autres utilisateurs de la forge

–  ‘Anonyme’ •  Donne des droits même à ceux qui ne sont pas authentifiés

– à rend le projet public


Listes de diffusion

•  Plugin activable pour chaque projet •  Permet de créer une liste de diffusion

–  Composée de la liste des membres du projet •  Création sur le serveur Sympa de RENATER

–  https://groupes.renater.fr •  Affiche toutes les listes attachées au projet

–  Permet d’en affecter une pour recevoir les commits si un hook (SVN/Git) a été paramétré

–  Permet de créer une liste spéciale pour les commits en un clic

•  Chaque liste peut aussi être close via le plugin


Wikis

•  Utilisation de Dokuwiki •  Création d’un espace wiki pour chaque projet •  Les pages du wiki sont par défaut accessibles

aux membres du projet •  L’authentification est automatique

–  via la fédération d’identité


Collaboration avec l’AMUE en 2015

•  Pour répondre aux besoins de certains établissement

•  Développement de plugins pour intégrer des outils –  TestLink –  Mantis –  Intégration continue

•  Jenkins, Sonar et Nexus –  Nuxéo

•  Sur tous ces outils : –  Authentification via la fédération –  Synchronisation des droits de la forge vers les outils –  Des interactions entre outils développées


Démo…


Subversion


Sans gestionnaire de

sources •  Pas de notion de status des sources

–  Difficile de savoir quelles modifications ont été faites et dans quels fichiers

•  Concurrence entre développeurs pour la modification d’un même fichier–  Risque d’écrasement des modifications des autres développeurs

•  Pas de mise à jour pratique de l’environnement–  Remplacement de toutes les sources nécessaires pour ne pas oublier de fichier

–  Risque de pertes de modifications


Gestionnaire de sources

•  Besoins :–  Collaboration simple entre développeurs–  Stockage des sources du projet sur un dépôt–  Possibilité d’annuler ses modifications–  Intégration avec d’autres outils–  Gestion de droits d’accès aux utilisateurs et groupes


Subversion

•  Implémentation de la notion SCM (software configuration management)

•  Liste les changements éffectués sur les fichiers et dossiers

•  Gestionnaire centralisé –  Un dépot unique sur un serveur contenant les fichiers, leurs versions et les branches

–  Chaque utilisateur à une copie locale d’une version du dépôt

–  Les modifications sont transmises sur le serveur centrales

–  Les développements concurrent sur un même fichier sont gérés


Subversion

•  Gestionnaire de sources open source•  Créé en 2000•  Projet Apache software foundation•  Dernière version : 1.9.3 publiée en décembre 2015

•  L’un des SCM les plus utilisés au monde •  Continue d’évoluer mais perd en utilisateurs face

à git


Propriétés de Subversion

•  Garder un historique de tous les changements–  Récupération de n’importe quelle version des fichiers–  Historique des suppressions ou renommage des fichiers

•  Faciliter la coopération entre développeurs–  Transmission des modifications aux autres développeurs–  Récupération sur la copie locale des mises à jours

•  Utilisation de branches–  Plusieurs versions maintenues en parallèle–  Test de fonctionnalités sans impacter la version principale–  Capaciter de reporter le code d’une branche à une autre

•  Gestion des accès–  Droit en lecture et/ou écriture pour des groupes ou utilisateurs–  Permissions applicables sur le repository ou sur les branches


Architecture


Client svn

Serveur Apache +

mod_dav_svn

dépôt Serveur svnserve

sshd

DAV

SVN

SSH

Protocoles

Copie locale

31/03/16

Processus de Subversion


Serveur Client

commit

update

Checkout Récupération d’une version ‘n’

Récupération des dernières modifications

Envoie des changements au serveur

Modifications de fichiers

Résolution de conflits

31/03/16

SVN: opérations de base

•  Checkout : –  crée une copie locale d’une version du dépôt (par défaut la dernière)

•  Add:–  Marque un fichier ou un dossier “pour ajout”

•  Commit: –  Propage les modifications/ajouts/suppressions au dépôt central

•  Status: –  donne l’état de chaques fichiers/dossiers de la copie de travail


Subversion: opérations •  Update:

–  télécharge les dernières modifications du repository sur la copie locale

•  Resolved:–  lors d’un conflit, indique que celui-ci a été résolu

•  Revert:–  reviens à la dernière version du repository local

•  Log:–  affiche les messages de commits associés aux révisions

•  Diff:–  Affiche les différences entre deux révisions sur des fichiers


Alias de révision

•  Une révision possède un numéro (ID)•  Les numéros sont utilisés dans les commandes svn–  Exemple : svn diff –r 40:35

•  Des alias existent pour les cas courants :–  HEAD: révision la plus récente du dépôt–  BASE: numéro de la révision locale d’un élément tel qu’il a été récupéré du dépôt

•  (sans prendre en compte les modifications locales) –  COMMITTED: dernière revision pour laquelle un fichier a été commité

–  PREV: révision précédente de COMMITTED


Alias de révision

•  Commandes pratiques :–  svn diff –r PREV:COMMITTED fichier

•  Affiche si des modifications ont été efffectuées sur un fichier lors de la dernière validation

–  svn diff –r BASE:HEAD fichier•  Permet de voir si des modifications ont été validées sur le fichier depuis que la dernière fois que l’utilisateur a mis à jour sa copie de travail.


collaboration


Développeur 1

Développeur 2

Dépôt central Commit et résolution de conflits

CheckoutVersion N

Checkout version N

31/03/16

Fusion de

développements •  SVN gère la modification d’un même fichier par différents développeurs

•  La fusion peut se faire de deux manières :–  Sans conflit :

•  Les développeurs n’ont pas modifié les mêmes fichiers•  Certains fichiers ont été modifiés par différents utilisateurs, mais pas les mêmes parties de ces fichiers

•  SVN fusionne toutes les modifications effectuées dans le fichier

–  Avec conflit : •  les développeurs ont modifiés les mêmes parties de certains fichiers

•  SVN ne peut déterminer seul comment fusionner les développements

•  Edition du fichier local pour résoudre le conflit


Processus de fusion


SVN commit

Erreur : Fichiers non à jour

Svn update

Résolution de conflits

31/03/16

Conflits

•  Conflit sur un fichier : –  Une version plus récente que celle sur laquelle travaille le développeur a été propagée

–  Les mêmes portions de code du fichier ont été modifiés•  Résolution :

–  Récupérer la dernière version–  Edition du fichier local–  Prendre en compte les modifications commitées auparavant par les autres développeurs

–  Marquer le fichier en tant que ‘conflit résolu’ pour SVN–  Commiter le fichier


Conflit


<?phpEcho “Hello”;?>



Dépôt central : version A

Copie de travail 1Version A


checkout

31/03/16

Conflit


<?phpEcho “Bye”;?>

<?phpEcho “Hi”;?>


Edition locale

Dépôt central : version A



31/03/16

Conflit





Dépôt central : version B



31/03/16

Conflit








Commit non possible

31/03/16

Conflit


<?phpEcho “Hi”;Echo “Bye”;?>






update

Conflit

31/03/16

Conflit





Copie de travail 1Version B



Résolution

31/03/16

Conflit





Copie de travail 1Version B

Dépôt central : version C


31/03/16

Conflit •  Possible de résoudre le conflit lors du commit

–  Si le conflit n’est pas compliqué–  Si l’utilisateur choisi d’écraser la version publiée par la sienne

•  Résolution possible plus tard, 3 fichiers supplémentaires sont alors créés :–  Fichier contenant la fusion entre la révision du dépôt et la révision locale

–  Révision actuelle du dépôt–  Révision locale–  Révision précédente

•  Une fois les corrections apportées au fichier, il doit être marqué comme “conflit résolu”–  Il pourra alors être commité


Arborescence SVN

•  3 éléments sont distingués :–  Trunk

•  Branche principal•  a toujours la dernière version des sources•  Pas forcément la version la plus stable

–  Branches•  Développement de grosses fonctionnalités•  Anciennes versions déployées

–  Tags•  Instantané du dépôt•  Créer lors d’une release


Les branches •  Au sens SVN, une branche = un embrenchement du trunk (ou d’une autre branche) à un instant donné–  svn copy URL/trunck URL/branches/ma_branche

•  Les développeurs peuvent passer d’une branche à une autre–  svn checkout URL/branches/ma_branche

•  Une branche peut être re fusionnée avec le trunk–  svn merge --reintegrate URL/branches/ma_branche .

•  Lors d’une fusion, des conflits peuvent être présents–  Gestion semblable à celle des conflits lors d’un commit


Branches : développement de fonctionnalités

•  Objectif : –  développement d’une évolution complexe–  Ne pas interférer avec le code du trunk

•  Durée de vie courte–  La branche sera fusionnée au trunk à la fin du développement

–  Si durée de vie trop longue, gros risque de conflits lors de la fusion sur le trunk

•  Avantages–  Si l’évolution est annulée, il est facile de supprimer la branche.


Branches : versions

•  Publication d’une version stable d’un logiciel–  création d’une branche à trunk n’est pas bloqué–  Permet de corriger les bugs trouvés sur cette version

–  Durée de vie longue•  tant que la version est supportée par les développeurs

–  Pour publier le code corrigé de la version •  Création d’un tag


Cycle


Trunk Branches tags

Rev 1

Rev 8

Rev 5

Rev 12

Rev 15 Rev 14

Rev 10

Rev 20

Rev 6

Rev 18

Rev 25

Rev 7

Rev 23

Rev 17

Rev 11

Rev 19

merge

31/03/16

Tags •  Un tag est une image d’une branche à un instant donné.

•  Similaire à la notion de branche, sauf qu’aucun commit ne doit être fait dessus

•  Utiliser pour déployer une application :–  Développement terminé sur la branche principal–  Création d’une branche (pour les éventuelles corrections)–  Créer un tag de la branche à chaque déploiement–  Les développements peuvent continuer sur la branche

•  le tag lui pointera toujours vers la même révision•  le déploiement fonctionnera toujours car fait avec la même version

•  Création à partir du trunk si les branches ne sont pas utilisées


SVN properties

•  Propriétés = nom + contenu•  Associées à un fichier ou un dossier•  Elles sont versionnées comme les fichiers•  Certaines sont définies et utilisées par le client SVN –  Exemple : svn:mergeinfo

•  Des propriétés arbitraires peuvent etre définies par les utilisateurs –  Commande svn propset


SVN properties •  Propriétés définies par SVN commence par “svn:”•  svn:keywords

–  Permet de substituer certains mots clés à l’intérieur des fichiers

•  Date, Revision, Author•  svn:mime-type

–  Positionne le MIME-TYPE d’un fichier–  indique a Subversion de ne pas utiliser un diff contextuel sur des fichiers binaire

•  svn:ignore–  Permet d’ignorer des fichiers et répertoires correspondant à un patron

–  Exemple : svn propset svn:ignore “*.iso” bin


SVN bonnes pratiques

•  Mettre à jour son dépôt local avant de développer une fonctionnalité

•  Ne pas commiter du code qui ne fonctionne pas ou bien ne compilant pas

•  Commiter régulièrement –  afin que l’équipe puisse récupérer votre code–  Les autres développeurs adapteront leur code


SVN bonnes pratiques •  La vie d’une branche ne doit pas être trop longue, car une branche sert à :–  développer une fonctionnalité, une fois celle-ci terminer, il faut fusionner la branche à la branche principale

–  Garder temporairement une version stable de l’application déployée, afin de corriger des bugs, incorporer quelques évolutions.

•  Plus une branche vit longtemps, plus le risque de conflits lors de la fusion est important


SVN bonnes pratiques •  Eviter les commits sans commentaire

–  Déterminer pourquoi un fichier a été commité plusieurs mois auparavant devient vite compliqué

–  Éviter les commentaires non précis comme : “correction d’un bug”

•  Regrouper sous un seul commit les modifications de fichiers concernant une fonctionnalité –  Si 10 fichiers modifiés, ne pas faire 10 commits

•  Si un tracker de bugs est utilisé, il est pratique de mettre l’ID du bogue dans le commentaire –  Des interactions permettent de liés un bug au commit


Outils liés •  Navigation :

– WebSVN, ViewVC•  Quelques Clients :

–  TurtoiseSVN, SVNTree, Subclipse (plugin eclipse)•  Api :

–  Java, C, Perl, Python, Php, etc.•  Installation possible sur

–  Les distribution unix , Mac Os, Windows•  Transformation de dépôt

–  SVN àGit : git-svn



SVN côté serveur SourceSup

31/03/16

Administration

•  Passe par la commande : “svnadmin”•  Créer un dépôt

–  svnadmin create dépôt•  Dump :

–  un export du dépôt Subversion contenu dans un fichier–  Contient toutes les révisions avec les branches et tags

•  Créer un dump–  svnadmin dump dépôt > nom_du_dump

•  Importer un dump–  svnadmin load dépôt < nom_du_dump


Filtrer un dépôt

•  Svndumpfilter :–  Permet de supprimer une partie de l’historique d’un dump SVN

–  utile lorsqu’un fichier contenant des mots de passe a été commité

•  le svn delete supprime seulement le fichier pour les prochaines révisions

•  Les anciennes révisions doivent aussi être “purgées”


Vue de dépôt web

•  Navigateur web d’un dépôt disponible sur la forge

•  Permet de –  naviguer dans l’arborescence d’un dépôt –  Visualiser une ancienne révision –  Comparer le contenu des fichiers de deux versions

•  Chaque soir sont calculées des statistiques : –  Les commits / ajouts effectués par chaque utilisateur –  Les utilisateurs ayant commité les 3 derniers mois


Hooks

•  Petits programmes executés suite à une action spécifique survenue sur le dépôt–  Pre-commit:

•  appelé avant que la nouvelle révision ne soit créée•  Permet d’appliquer des règles à la création de révision

(commentaire non vide)–  Post-commit:

•  Appelé juste après la création de la nouvelle révision•  Permet de notifier d’autres outils qu’une révision a été publiée (tracker, mail, …)


Envoie de mail

•  Sympa : serveur de listes de diffusion •  SourceSup permet à un projet de créer des listes

sur un serveur Sympa –  Un plugin permet la création de plusieurs listes –  Création d’une liste spéciale pour les commits en un clic

•  Les membres de la liste sont les membres du projet –  Synchronisation régulière –  Le propriétaire est le créateur de la liste

•  Un hook s’il est activé permettra d’envoyer par mail après chaque commit les modifications effectuées


Tests et défaillances


Tests •  Valident et vérifient le bon fonctionnement d’un logiciel

•  Assurent que le produit est conforme aux spécifications

•  Vérifier la qualité d’un produit•  permettent d’identifier les bogues, erreurs, crashs afin que les développeurs les corrigent

•  En fonction du logiciel, l’effort à passer sur les tests n’est pas le même–  Logiciel embarqué dans une fusée


Qualité d’un logiciel

•  Qualité d’un logiciel = qualité fonctionnelle + qualité non fonctionnelle

•  Qualité fonctionnelle–  Vérifie que le produit correspond aux spécifications fonctionnelles

•  Qualité non fonctionnelle–  Vérifie les performances, la robustesse, la qualité du code source, la sécurité, etc.

•  Les tests permettent de mesurer la qualité globale d’un logiciel


L’équipe de testeurs •  Les testeurs doivent être critiques

–  à il est préférable qu’un développeur ne teste pas son propre code

•  et ne pas négliger la moindre défaillance–  Relever tout problème, même cosmétique

•  Développeur : –  Testera pour vérifier que son code fonctionne

•  Testeur :–  Testera l’application pour voir son mauvais fonctionnement

•  Un coordinateur de test peut être utile–  Création des plans de tests et les spécifications de tests–  Assigne les tests aux testeurs


Catégorie de tests

•  Boite noire :–  Les tests sont exécutés indépendament les mécanismes internes du produit

–  Le testeur n’accède pas au code source•  Boite blanche

–  Les tests prennent en considération les mécanismes interne du logiciel

–  Le testeur a connaissance du fonctionnement interne et a accès au code source


Type de tests

•  Tests unitaires•  Tests d’intégration•  Tests fonctionnels•  Tests non fonctionnels•  Tests de régression•  Tests d’acceptation


Tests unitaires •  S’exécute en mode boîte blanche•  Écrits au fur et a mesure des développements•  Permettent de tester un bloc de code individuellement

•  Important car –  Permettent de détecter beaucoup de défaillances –  Peuvent être automatisés (PHPUnit, JUnit, etc.)

•  Deux objectifs :–  Couverture du code : test de chaque ligne de code

(appel de fonction, itération, choix, etc.)–  Couverture des données : données valides/invalides


Tests unitaires •  Conforme à l’acronyme F.I.R.S.T :

–  FAST : •  rapide à exécuter

–  INDEPENDANT : •  tests indépendant des autres

–  REPEATABLE : •  répétable autant de fois que nécessaire

–  SELF-VALIDATING : •  se valide lui même en retournant un succès ou un échec

–  TIMELY : •  tests écrits durant le développement, quand le développeur en a besoin


Tests d’intégration

•  Exécutés en mode boite blanche•  Cherchent à montrer les problèmes lors d’interactions entre plusieurs modules

•  Permettent de détecter au plus tôt les problèmes liés à l’interfaçage entre deux modules

•  Moins couteux que de tester l’ensemble des modules intégrés en une fois


Tests non fonctionnels •  S’exécutent en boite noire•  Composés d’une batterie de tests

–  Tests de charge•  Tester l’application dans des conditions normales (nombre d’utilisateurs simultanés)

–  Tests de stress•  Tester le logiciel au delà des capacités normales, jusqu’à un point de rupture

•  (simulé un nombre très important d’utilisateurs simultanés qui s’authentifient ou valident un formulaire)

–  Tests de Volume•  Tester le logiciel avec un volume de données défini, comme une base de données remplie


Tests non fonctionnels –  Tests de performance

•  Mesure de temps de réponse d’une application•  Tester sa capacité d’évolutivité (si ajout de ressources supplémentaires à meilleures performances)

–  Tests d’utilisabilité•  Est-ce que l’utilisateur normal arrive à utiliser l’application à partir des exigences d’apprentissage demandées

–  Tests de récupération•  Comment le système redémarre après un crash•  Stoper une base de données pendant un enregistrement et voir comment le système redémarre (corruption ou pas ?)

–  Tests de documentation•  Valider la doc d’installation d’un logiciel


Tests de non régression

•  Sous ensemble des tests originaux •  Nouveaux tests qui valident les corrections

apportées•  vérifient qu’une évolution ou une modification du code n’a pas provoqué d’effet de bord sur le reste du produit


Sans gestion des cas de

tests •  Tests au hasard•  Écriture des tests dans un document word•  Pas de sauvegarde des résultats des tests

–  ou sauvegarde dans un doc word–  Difficile de garder un historique et d’avoir une vision d’ensemble de la qualité du logiciel


TestLink

•  Plateforme web PHP•  Objectif :

–  Organiser les cas de tests sous forme de plans de tests à exécuter

–  Gestion de l’historique des tests exécutés –  Centraliser la gestion des tests et la rendre accessible

à l’ensemble de l’équipe du projet, tout en gérant des droits

•  Dernière version 1.9.14 publiée en septembre 2015


Cas de tests

•  Composé d’un ensemble d’entrées, de conditions d’exécution et de résultats attendus

•  Pour écrire le plan de test, il faut détailler chaque cas de test

•  Éléments d’un cas de test :–  Un identifiant–  Description :

•  précisions sur le test et les attentes


Cas de tests –  Préconditions :

•  Conditions à réunir pour effectuer le test•  Les cas de test à exécuter précédemment

–  Scénario : •  Suite d’étapes à suivre par le testeur•  Chaque étape peut avoir un “résultat attendu”

–  Résultats attendus–  Résultats obtenus

•  Si différents à signalement d’une défaillance•  Sinon le test est réussi


Campagne de tests

•  Une campagne de tests –  Sélectionne certains cas de tests ayant un rapport–  Procède à leur exécution

•  Chaque campagne a un objectif–  Validation d’une fonctionnalité–  Validation du logiciel–  Performance


TestLink


workflow

•  Créer un projet•  Créer ses cas de test•  Créer une campagne de test (ou plan de test)•  Spécifier un build au projet à tester•  Ajouter les cas de test à la campagne de test•  Assigner les cas de test aux utilisateurs•  Executer les cas de test•  Voir les résultats (rapports / graphiques)


Autres fonctionnalités

•  Mots-clés –  Permettent de regrouper des cas de tests puis de les

retrouver facilement •  Gestion des exigences

–  Exigence : •  Description de ce qu’un logiciel doit faire

–  Création/Import d’exigences métiers –  Lier les cas de tests aux exigences


Intéractions

•  TestLink dispose d’API•  Avec Mantis

–  lier un cas de test avec un bogue–  Permettre de facilement accéder au bogue s’il doit être mis à jour

•  SourceSup–  Création d’un projet de test pour un projet SourceSup

–  Synchronisation des utilisateurs et des permissions depuis la forge vers TestLink


Mantis


Mantis

•  Gestionnaire de bogues et d’évolutions •  Rassemble les anomalies par projet

–  Affectation de rôles pour y accéder et interagir

•  Authentification via la fédération d’identité •  Le projet Mantis

–  créé depuis la forge, les utilisateur recevant ainsi les droits dessus

•  Tableau de bord personnel de l’ensemble des bogues qui concerne l’utilisateur


Un bogue sous Mantis

•  Possède –  un statut qui évolue au fur et à mesure des

corrections et tests •  Nouveau, affecté, résolu, clos, etc.

–  Un rapporteur, un développeur assigné –  Des informations sur sa priorisation, l’impact


Interactions

•  Avec SourceSup : –  Récupération des versions définies sur la forge

•  TestLink : –  Liste des plans de tests

•  Nuxéo : –  Lier un ou plusieurs documents sur Nuxéo au bogue

•  SVN/Git : –  Passer le statut à ‘résolu’ d’un bogue via un hook


Git


VCS centralisé

•  Implémentations : –  SVN, CVS, ...

•  Serveur central hébergeant le dépôt–  Avec toutes les versions des fichiers, les branches et tags

•  Sources téléchargées localement•  Travail en local•  Envoie des modifications au serveur central•  Inconvénients :

–  Serveur central en panne à plus de commits/update–  Si crash du disk à perte de tout l’historique du projet

31/03/16 Forma&on SourceSup Base – 2016 Montpellier 88

VCS décentralisé

•  Implémentations : –  Git, Mercurial, ...

•  Les dépôts locaux contiennent l’intégralité des informations :–  Les branches, tags, toutes les versions sont en local

•  Les commits se font en local•  Inconvénients :

–  si trop de dépôts distant à difficile de se rappeler où récupérer tel fonctionnalité/correction

•  Contourner par avoir un serveur central


Git •  Créé en avril 2005

–  par Linus Torvalds –  maintenu par Junio Hamano–  Gestion du le workflow d’intégration des patches du noyau Linux

•  De plus en plus utilisé (Github : 10 millions d’utilisateurs)

•  Objectif :–  Vitesse et compacité des données (pour les gros projets comme le noyau linux)

–  Développements non linéaires (centaines de branches en parallèle)

–  Complètement distribué (pas de serveur central nécessaire)


Gestion des données •  Git pense ses données comme un instantané d’un système de fichier–  Lors d’un commit à prise d’un instantané de l’espace de travail

–  Les fichiers non modifiés ne sont pas re-stokés mais une référence est créée vers le fichier original

•  Git gère l’intégrité des données–  Génération d’une somme de contrôle (SHA-1) en fonction du contenu du fichier ou de la structure du répertoire

•  Corruption d’un fichier difficile–  Cette somme sert de référence pour indexer les données dans la base de Git


Copie de travail

•  2 manières pour la créer :–  Initialiser un dépôt vide local

•  mkdir mon_projet•  cd mon_projet•  git init

–  Cloner un dépôt existant•  git clone git://git.exemple.fr/mon_projet.git

•  Chaque utilisateur possède son dépôt local–  stoqué dans un dossier .git


Copie de travail

•  Récupération d’un dépôt distant : –  Avec Subversion :

•  svn checkout URL•  Récupère seulement une version des fichiers du dépôt

–  Avec Git :•  git clone URL•  Récupère l’ensemble des versions de tous les fichiers du dépôt, avec branches et tags

•  Il est possible de recréer le dépôt central à partir de n’importe quel dépôt d’utilisateurs


Configuration de Git

•  Plusieurs paramètres configurables–  Nom utilisateur, email, editeur pour les diffs,

•  Différents niveaux–  Dépot local : .git/config–  Utilisateur : ~/.gitconfig–  Server : /etc/gitconfig

•  Exemple :–  Git config --global user.name “mon nom”–  Git config --global user.email “mon email”


Dépôt Git local


Répertoire de travail Répertoire .git Zone d’index

(staging area)

Checkout

Add

Commit

Dépôt Git

•  Composé de 3 zones :–  Répertoire .git :

•  base de données des objets du projet et toutes les méta-données (versions, tags, branches)

•  Avec ce dossier, il est possible de recréer un dépôt complet

–  Répertoire de travail : •  Extraction d’une version du projet, depuis le dossier .git

–  Zone d’index : •  Fichier qui stocke les informations qui feront parties du prochain instantané


Status des fichiers •  Non suivi (Untracked)

–  Tous fichiers de la copie de travail qui :•  N’a jamais été embarqué dans un instantané•  N’a pas encore été indexé

•  Indexé (Staged)–  Fichiers ajoutés à la zone d’index–  Pris en compte lors du prochain commit

•  Non modifié–  Sous suivi (a déjà fait parti d’un instantané)

•  Modifié–  A déjà fait parti d’un instantané–  A été édité depuis ce commit–  Pas pris en compte lors du prochain commit (pas indexé)


Status des fichiers


Non suivi(Untracked)

Indexé(Staged) Modifié

Add

Commit

Non modifié

Modification

Add

Commit

Commandes de bases •  git add

–  Ajout de fichiers à la zone d’index •  git commit

–  Crée un nouveau commit avec les modifications contenues dans la zone d’index

•  git info–  Affiche les informations du commit

•  git push–  Propage les derniers commit vers un dépôt

•  git pull–  Récupère les derniers commit d’un autre dépôt et les

fusionne à la copie de travail


Hashes

•  Git n’utilise pas des numéros de versions comme Subversion–  Pas de sens avec un SCV décentralisé

•  Pour identifier un commit, utilisation d’un hash SHA-1 (40 caractères) –  Ces hashs peuvent être utilisés dans les commandes

git


Ajout de fichiers à la zone

d’index •  git statusOn branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)

modified: mon_dossier/mon_fichier no changes added to commit (use "git add" and/or "git commit -a »)

•  git add mon_dossier/mon_fichier•  git statusOn branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage)

modified: mon_dossier/mon_fichier


Ajout de fichiers à la zone

d’index •  Cas particulier :

–  Création d’un fichier “monfichier”–  Ajout de ce fichier en zone d’index :

•  git add monfichier–  Modification de ce fichier

•  Le fichier sera ajouté à la zone d’index dans son état AVANT modification

•  Son status indiquera : –  Changes to be committed:

•  new file: monfichier–  Changed but not updated:

•  modified: monfichier •  Pour embarquer toutes les modifications

–  un nouveau ‘git add’ sur le fichier sera nécessaire


Création d’un commit •  Possède un ID (hash) unique•  Création d’un nouveau commit avec les

modifications contenues dans la staging zone–  git commit –m “commentaire”

•  Commit en sautant l’étape ‘git add’–  git commit –m “commentaire” –  Tous les fichiers ‘sous suivis’ et ‘modifiés’ sont concernés

•  Correction du dernier commit : –  git commit ––amend –  L’objet commit précédent est modifié avec le contenu de la

zone d’index


Qu’est ce qu’un commit ?


Blob Contenu du fichier1



Tree •  Blob 6b9d2 fichier1 •  Blob fv3l0 fichier2 •  Blob 2sd3f fichier3

Commit •  tree ml4P •  Author thomas •  Commitor thomas

6b9d2

2sd3f

fv3l0

ml4P

Commit

•  Composé de plusieurs objets : –  Un objet commit : contient les méta données du

commit ainsi qu’un pointeur vers l’objet ‘tree’ racine –  Un objet tree : contient la liste des blobs du commits,

avec un pointeur vers chacun des objets –  Un ou plusieurs Blob :

•  Chaque blob possède le contenu d’un fichier

•  Le commit initial n’as pas de parent •  Tous les commits suivant ont un ou plusieurs

parents (fusion)


branches

•  La branche par défaut d’un dépôt = ‘master’ •  Ce nom n’est pas obligatoire et peu être modifié

–  git init utilise ce nom par défaut pour créer la 1e branche

•  Une branche est un pointeur vers un certain commit, qui peut être déplacé

•  Création d’une branche –  git branch mabranche –  Crée un pointeur vers le commit courant

•  Le pointeur HEAD : pointe vers la branche courante –  C’est un pointeur vers un pointeur


Git branch mabranche


z2r45

master

ml6h8

mabranche

HEAD

Git checkout mabranche


z2r45

master

ml6h8

mabranche

HEAD

Git commit


z2r45

master

ml6h8

correc&f

HEAD

ch7u3

Git checkout master


z2r45

master

ml6h8

correc&f

HEAD

ch7u3

Git checkout master

•  Cette commande a effectué deux actions : –  Déplacer le curseur HEAD vers le pointeur ‘master’ –  Remplacer les fichiers de la copie de travail par le

snapshot pointé par ‘master’ •  les commits à venir à partir de cet état vont

diverger des commits de la branche ‘mabranche’


Git commit


z2r45

master

ml6h8

correc&f

HEAD

ch7u3

op2j0

Fusion de branches

•  Les deux branches divergent maintenant •  Pour intégrer les modifications d’une branche

dans une autre –  Il faut les fusionner –  Se réalise avec la commande ‘git merge’

•  Différents types de fusions –  Fusion rapide (fast-forward) –  Fusion trois sources


Fusion fast-forward


z2r45 ml6h8

master

HEAD

correc&f

ut5h9

Fusion fast-forward

•  Le commit de la branche que l’on désire fusionner est un descendant direct du commit de la branche courante

•  Git se contente de faire avancer le curseur ‘master’

•  Pas de travaux divergents à fusionner



z2r45

master

correc&f

HEAD

ch7u3

op2j0

ny3P

Fusion trois sources


z2r45

master

correc&f

HEAD

ch7u3

op2j0

ny3P

&9m2



•  Commit de la branche à fusionner n’est pas un descendant direct du commit de la branche courante

•  Git crée un nouveau commit à partir : –  Du commit commun aux deux branches le plus récent –  Du commit de la branche à fusionner –  Du commit de la branche courante

•  Si des parties des mêmes fichiers ont été modifiés différents –  à conflit à résoudre

•  Sinon : fusion se fait automatiquement


Suppression de branches

•  Après fusion, on peut ne plus avoir besoin d’une branche

•  il suffit de la supprimer avec : –  git branch –d mabranche

•  Pour être sûr d’avoir bien fusionner les modifications d’une branche sur la branche master : –  git branch --merged –  git branch --no-merged

•  La suppression d’une branche consiste à supprimer le pointeur


Tags : étiquettes

•  Un tag sert à marquer un état important dans l’historique du dépôt

•  La commande ‘git tag’ : liste les tags existant•  Deux types d’étiquettes :

–  Légères –  Annotées

•  Possible d’étiqueter un ancien commit –  Préciser la somme de contrôle du commit

•  Par défaut, les étiquettes ne sont pas pousser –  Il faut l’indiquer explicitement –  git push origin ‘mon_tag’


Étiquette légère

•  Juste un pointeur vers un certain commit en utilisant sa somme de contrôle (hash)

•  Exemple : # git tag v1.5 # git show v1.5 commit d91e17e2a88fbf60342b46077c815c9918cd0116 Author: Sebastien Medard [email protected] Date: Mon Mar 07 15:26:03 2016 +0100


Étiquettes annotées •  Sont stockées dans la base des objets du dépôt •  Contiennent plusieurs informations :

–  Date, créateur, commentaire de l’étiquette •  Exemple :

# git tag -a v1.4 -m "ma version 1.4” # git show v1.4 tag v1.4 Tagger: Sebastien Medard [email protected] Date: Mon Mar 07 16:35:41 2016 +0100 ma version 1.4 commit d91e17e2a88fbf60342b46077c815c9918cd0116 Author: Sebastien Medard [email protected] Date: Mon Mar 07 15:26:03 2016 +0100


Branches distantes

•  Pointeur local indiquant dans quel état se trouve les branches sur un dépôt distant

•  Exemple : origin/master •  Ces pointeurs n’évoluent pas tant qu’ils ne sont

pas mis à jour –  Git fetch

•  Lors d’une mise à jour, les pointeurs évoluent –  git merge


Workflow


Développement

Git pull

git add

git commit git pull

Résolution des conflits

git push

rebaser

•  Rebaser une branche dans une autre : –  Trouver le plus proche ancêtre commun –  récupérer toutes les modifications de chaque commit

de la branche courante, les garder dans des fichiers temporaire

–  Réinitialisation de la branche au commit le plus récent de la branche cible

–  Rejouer les modifications

•  Principale différence avec une fusion –  Historique plus clair, linéaire



master

Commit 1

mabranche

HEAD

Commit 3

Commit 2


master

Commit 1

mabranche

HEAD

Commit 3 Fichier

temporaire

Commit 2


master

Commit 1

mabranche

HEAD

Commit 3 supprimé

Commit 2 Commit 3’

Le remisement

•  Scénario : –  pour mettre de côté ses modification non terminées (donc

non commitables) –  Changer de branche, faire un correctif –  le commiter et fusionner avec un branche –  Revenir à sa branche initiale, et récupérer ses

développement en cour •  Permet de créer une copie de travail propre et ainsi

pouvoir changer de branche facilement •  Utilisation d’une pile pour stocker les ‘stash’ •  Plusieurs stash stockés possible


Modes distribués : gestion centralisée

•  Fonctionnement similaire à celui de SVN •  Le premier à pousser ses modifications le fait sans problème •  Les suivants doivent :

–  Récupérer les mises à jour –  Les fusionner avec leur copie locale –  Gérer les éventuels conflits –  Pousser leurs modifications

•  Git oblige à récupérer les mise à jour avant de pouvoir pousser ses modifications –  Même si les modifications distantes/locales ne concernent pas les

mêmes fichiers –  Pas de risque d’écrasement du travail des autres

•  Fonctionnement courant dans git car beaucoup de monde est familiarisé avec


Modes distribués : gestion centralisée


Dépôt référence

Dépôt local 1 Dépôt local 2

Modes distribués : intégrateurs

•  Git autorise une multitude de dépôts distants –  Permet à des développeurs d’être facilement contributeurs –  Ont un accès en lecture sur un dépôt « référence » pour

cloner le dépôt et récupérer les mises à jours –  Poussent leurs modifications sur leur dépôt public –  Transmettent une demande à l’intégrateur pour qu’il

récupère et fusionne leurs modifications •  Un intégrateur

–  A un accès en lecture sur les dépôts des contributeurs –  Fusionne les mises à jour avec sa branche –  Pousse les nouveaux développements sur le dépôt

référence


Modes distribués : intégrateurs


Dépôt référence

Dépôt local 1 intégrateur

Dépôt public 1 Dépôt public 2

Dépôt local 2

Modes dictateurs / lieutenants

•  Fonctionnement pour les très gros projets (noyau linux) •  Contributeurs

–  Récupèrent le code du dictateur depuis le dépôt référence –  Poussent leurs modifications sur un dépôt

•  Un gestionnaire d’intégration par partie du projet à lieutenants –  Récupère les contributions sur les dépôts publics –  Fusionne les contributions des développeurs sur leur branche

•  Les gestionnaires ont un unique gestionnaire d’intégration à dictateur –  Fusionne les branches master des lieutenants sur sa branche

master –  Pousse le code à jour sur le dépôt de référence


Modes dictateur / lieutenants


Dépôt référence intégrateur

Dépôt public 1 Dépôt public 2 Dépôt public 3

lieutenant lieutenant

Dépôt distant •  Le nom à partir duquel est cloné le dépôt est par

défaut : origin •  git remote

–  Indique le dépôt distant •  Git remote –v

–  Indique l’URL associé au dépôt •  Git remote add NAME URL

–  Ajoute un nouveau dépôt distant •  Git remote show NAME

–  Indique des informations sur le dépôt distant NAME


Pousser ses modifications

•  Avant de pouvoir effectuer un push de commits –  Git oblige à mettre à jour son dépôt local –  Le développeur devra fusionner ces modifications à

sa copie de travail –  Gérer les éventuels conflit –  Ensuite il pourra transmettre ses modifications


Mettre à jour sa copie de travail

•  git fetch : –  récupération des données depuis le dépôt distant en

local, mais sans modifié la copie locale •  git merge :

–  Fusionne une ou plusieurs branches dans la branche courante de la copie de travail

•  git pull : –  Réalise les opérations fetch et merge


Historique d’un fichier

•  Git show affiche un fichier dans un commit particulier

•  Git blame donne les informations de modification d’un fichier


Installation

•  Git s’installe sur tous les systèmes populaires–  Windows–  Linux (Redhat, Debian, ubuntu, centos, etc.)–  Mac os

•  Client graphiques :–  SourceTree –  GitX –  Gitkraken –  …



Git côté SourceSup

Gestion des dépôts

•  Identification via clé ssh pour les commandes –  Possible d’en paramétrer plusieurs

•  Gestion des autorisations sur les dépôts avec gitolite

•  Un dépôt principal par projet mais aussi –  Un ou plusieurs dépôts secondaires –  Un ou plusieurs dépôts personnels

•  Initialiser à partir du dépôt principal ou vide


Hook

•  Hooks coté client –  Pre-commit –  Prepare-commit-msg

•  Hooks côté serveur –  Pre-receive :

•  traitement avant la gestion de la poussée –  Post-receive :

•  traitement après la fin du processus •  Pratique pour envoyer un mail de notification, avertir un

serveur d’intégration continue, etc. •  Notifier un tracker


Gitweb

•  Navigateur de dépôt web •  Permet

–  d’afficher l’historique d’un dépôt, y compris dans les branches

–  De faire des diff entre des versions différentes de fichiers

–  Voir toutes les informations relatives à un commit •  Message, hash, créateur, date, etc.


Intégration continue

Forma&on SourceSup Base – 2016 Montpellier 146 31/03/16

définition

•  Consiste à intégrer fréquemment le travail des membres d’un projet

•  À chaque intégration, exécution de tous les processus permettant de détecter des erreurs –  Lancement de tests –  Build de projet –  Analyse de code

•  Enjeux –  Meilleur réactivité, détection des problèmes au plus tôt à

meilleur qualité –  Une fois mis en place, déleste les développeurs de ces

actions


Pré requis

•  Les sources sont hébergées sur un dépôt•  Automatiser

–  le build du projet (maven, ant, make, etc.)–  les tests (junit, etc.)

•  Les développeurs commitent chaque jours–  Intégration régulière et de petite taille


workflow


dépôt

build test package

déploiement

Espace de travail

Notifications

Dépôt de livrables

Serveur d’intégration continue

Jenkins fonctionnalités •  Fonctionne avec des jobs configurables

–  Récupération des sources à partir d’un dépôt (SVN/Git) –  Gestion des droits –  Actions avant/après le build –  exécution automatique des tests et du build à partir

d’événements ou régulièrement •  Console d’erreur indiquant les éventuelles

problèmes •  Gestion des historiques de builds•  Génération de rapports et de notifications•  Déploiements


Déploiement continue

•  À intervalle régulier, voir chaque commit, le code source est :–  Compilé–  Assemblé–  Déployé sur un environnement de test–  Testé–  Déployé sur la plateforme de production


intéret

•  Effectuer de petits déploiements de manière très régulière :–  Réduit les risques –  Gestion de projet :

•  Test des évolutions déployées•  Découverte au plus tôt des anomalies

–  Réduit le temps de correction des problèmes remontés•  Plus un bug est découvert tôt, moins d’impact aura sa correction sur le reste du code

–  Réduit le temps d’indisponibilité des plateformes de test (problèmes de compilation, fonctionnalités cassées, etc.)


Jenkins

•  Création de job Jenkins depuis le plugin de la forge –  Possibilité de lier directement le dépôt SVN/Git –  Configure automatiquement les autorisations pour les

membres du projet •  Suppression et lancement manuel du job depuis

le plugin de la forge



Qualité de code

Qualité

•  Évaluer la qualité de code–  Utilisation de métrique et de critère d’évaluation

•  Différent types de qualité–  Qualité du code

•  Implémentation des fonctionnalités–  Qualité logicielle

•  Résultat final des fonctionnalités•  Qualité du code peut être analysée automatiquement–  Des outils existent pour les langages les plus utilisés


Problèmes

•  Duplication de code : –  Factoriser au maximum –  Du code dupliqué est l’occasion d’élever le niveau

d’abstraction •  Mauvaise distribution de la complexité

–  beaucoup de méthodes de petite complexité >> peu de méthodes très complexes

•  Mauvais « design » –  Des classes faisant appel les unes aux autres à

cycles


Problèmes

•  Pas de tests unitaires –  Fonctions avec cas multiples

•  Si ajout d’un cas à comment assurer la non régression sans TU

–  Un code sans tests unitaire peut être •  Du code mort •  Un appel à une API CRUD

•  Non respect des standards –  Pas de gestion d’exceptions –  Voir les bonnes pratiques de chaque langage


Problème

•  Bugs potentiels évident –  Appel à une méthode d’un objet « null »

•  Trop peu de commentaires –  Documenter ses fonctions/classes, les types de

paramètres, les résultats attendus –  Écrire du code compréhensible

•  Nommer un objet pas en fonction de son type mais plutôt sur ce qu’il représente ou accompli

•  « mafonction1 » << « createListPerson »


SonarQube

•  Plateforme web centralisée de gestion de la qualité –  Différents profils de qualité disponibles –  Intégrable dans la chaine de build –  Support de nombreux langages –  Utilise les rapports fournis par des outils existant

•  Findbugs, PMD, checkstyle, etc. –  Plusieurs plugins disponibles

•  Export, langage –  Rapport et évolution de la qualité du projet –  Disponible en open source


SonarQube


Métrique

•  Une métrique permet de mesurer un aspect du code –  Fournit une valeur chiffré pour un critère

•  Un mauvais rapport (ensemble de métriques mauvaises) –  Doit être un signal d’alarme –  Doit déclencher des actions afin de corriger les

problèmes


Métriques standard

•  Couverture du code par les tests unitaires •  Nombre de lignes de code •  Densité des commentaires = nombres de lignes

de commentaire / nombre de lignes de code •  Complexité du code •  Code dupliqué •  Interdépendances entre fichiers



Nexus

Nexus

•  C’est un repository manager •  Répond à deux problématiques

–  Agir tel un proxy entre les machines d’une entité et les dépôts Maven publics

–  Organiser les dépôts où se feront les déploiements Maven des projets de l’entité


Nexus proxy

•  Permet d’éviter que chaque développeur télécharge les dépendances maven

•  Si une dépendance est nécessaire, elle est téléchargée une fois sur Nexus

•  Maven interroge les dépôts publics pour savoir si une version plus récente n’est pas disponible –  Gérer par le repository manager qui met à jour

régulièrement les dépendances •  Permet aussi de forcer l’équipe de développeur

d’utiliser une certaine version d’une dépendance


Nexus gestionnaire de dépôts

•  Fourni des dépôts pour héberger des artéfacts •  Gestion d’autorisation sur les dépôts afin de les

rendre privés ou publics •  Deux dépôts sont créés pour chaque projet de la

forge –  Release et snapshot –  évite que tous les développeurs buildent les

dépendances •  Déploiement facile depuis un job jenkins en

ajoutant la configuration maven


Nuxéo

•  Gestionnaire de document –  Gestion des versions de documents –  Association de meta-données aux documents –  Workflow personnalisable pour gérer le cycle de vie

des documents, l’historique •  Création d’un workspace depuis la forge

–  Seuls les membres du projet y ont accès par défaut –  Des documents peuvent être réalisés depuis le plugin

de la forge directement dans le workspace


Evolutions à venir

•  Mise à jour de la plateforme –  avec la dernière version stable de FusionForge (6.0.3) –  Industrialisation des mises à jour (ansible) –  Passage sur Ubuntu

•  abandon de Centos (repo officiel pas suffisamment à jour pour Subversion, php, etc.)

–  Mise à jour des différents outils –  Récupération des établissements dans le référentiel PASS

•  Etude sur une possible intégration de Gitlab –  Voir les apports –  Pas trop redondant ?


Pour finir

•  Documentation du service : –  https://services.renater.fr/sourcesup

•  Support RENATER : –  [email protected]

•  Retours ou propositions d’évolutions –  https://feedback.renater.fr/


formation sourcesup base - renater · fichiers php et autres ! utilisez un éditeur qui colorise !...

Documents