Ecole Informatique IN2P3

Présentation au sujet: "Ecole Informatique IN2P3"— Transcription de la présentation:

1 Ecole Informatique IN2P3
Les outils de mise en production du logiciel

2 Thématique: Les outils de mise en production du logiciel
Cette école s'adresse à tout développeur ayant déjà parcouru tout le cycle de développement d'un logiciel et soucieux de distribuer son programme ou de le mettre en production sur un serveur

3 L’école Du 28 septembre au 2 octobre 2015, à Lyon
La page INDICO : Toutes les docs, présentations, TPS sont dans : Data3\calcul\Ecole_IN2P3\Ecole_IN2P3_production_logiciel_sept2015 Une quarantaine de personnes (30 stagiaires) Beaucoup de TPs autour d’un seul code « fil rouge » (en java)

4 Points abordés Généralités sur le cycle de vie du logiciel et la qualité du code : Notion de dette technique Retour de la société Orange TP sur l’outil SonarCube (inspection de code, indicateurs) Importance des tests (unitaires, d’intégration) Exposé sur des travaux de recherche dans ce domaine au LRI démos en TPs La production collaborative du code TP avec git et gitlab (CC) Les workflows Importance des logs et de leur normalisation Présentation de l’infra de gestion des logs du CC TP Intégration continue impacts à la DSI de l’INRA TP sur l’outil Jenkins sur l’infra Cloud du CC Le packaging de l’application sous forme de container Présentation de Docker TP Docker

5 Evolution des pratiques
Cycle de vie du logiciel : livraisons plus fréquentes, versions fonctionnelles mais incomplètes, prise en compte des retours des utilisateurs ( méthodologie agile )  automatiser pour fiabiliser et accélérer les livraisons  « Usine Logicielle » : ensemble d’outils pour le « déploiement continu » : build, tests, inspection du code, packaging, déploiement, doc, logs

6 Qualités d’un logiciel
Les qualités : Capacité fonctionnelle Fiabilité Utilisabilité Rendement Maintenabilité (évolutivité) Portabilité Exploitabilité Mesure / garantie de qualité : IVVQ (Intégration, Vérification, Validation et Qualification)

7 Bonnes pratiques pour améliorer la qualité
Conception Architecture Conventions de codage Traces, exceptions Tests unitaires, d’intégration, de performance Sécurité Revues

8 Mesure de la non qualité
Dette technique : effort supplémentaire (en jour.homme) à faire dans le développement futur pour palier aux défauts de conception (== coût de remédiation). Analogie financière : rembourser sa dette évite de continuer à payer des intérêts. Dette naturelle ou intentionnelle Méthode pour l’évaluer : Squale "Software Quality Assessment based on Lifecycle Expectations" Implémentée dans l’outil SonarQube (ressource)

9 Logiciel libre permettant la mesure de la qualité du code source en continu.
Support multi language ( 25+ ) Reporting de la qualité du code sur différents axes. Generation de différentes vues avec evolution temporelle et différentielle Analyses automatisés ( integration maven, ant … et serveurs d’integration (Jenkins…)) Intégration dans eclipse Intégration avec des outils externes ( JIRA, Mantis, LDAP … ) Extensible par plugins Implémentation de SQALE pour évaluer la dette technique. SQALE : Software Quality Assessment based on Lifecycle Expectations

10 Axes de la qualité du code
Architecture & design Commentaires Duplication Sources Règles de codage Tests Unitaires Bugs Potentiels Complexité

11 Tableau de bord

12 Défauts

13 Site demo : http://nemo.sonarqube.org/
Règles Site demo :

14 Source code management
SCM : Dépôts de code Gestion des versions Centralisé versus distribué … Git : TP avancés GitLab versus GitHub : « forges sociales » GitLab : instance au CC, CERN (et au LAPP…) Workflows (branches : features, releases, hotfix..., publication, merge request)

15 GitLab

16 GitLab : statistiques

17 GitLab : merge request

18 GitLab : nouveau projet

19

20 Les logs Quoi logger ? : tout ! (info, erreurs , exceptions...)
Bonnes pratiques : Utilisation de librairies Format standard, exploitable (structuré) Niveau de sévérité adapté Messages explicites (usage : homme ou machine) Avec un id unique, des infos de contexte etc… Les logs doivent (aussi) servir aux exploitants

21 Gestion des logs au CC Collecte : syslogNG
Moteur de requetes: Elasticsearch Portail : Kibana

22 Les tests Activité aujourd’hui incontournable pour la qualité du logiciel, promue par l’agilité : plus tôt on teste, plus on gagne de temps à la fin Non exhaustifs Différents types, approches complémentaires : Structurel (tests unitaires, d’intégration) : analyse du code source du logiciel, test des chemins, des instructions … Fonctionnel (boîte noire) : examine le comportement du logiciel et la conformité à la spécification, création de scénarios utilisateur Bonnes pratiques : Tests de non-régression Automatisation

23 Jenkins Intégration continue :
Ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée Jenkins est un outil libre d’intégration continue écrit en Java : Interfaçage avec VCS (CVS, SVN, GIT …) Exécution de projets basés sur Apache Ant et Maven et aussi des scripts en shell Unix ou batch Windows Build + tests multi-plateformes (Cloud) Contrôle de la qualité du code (+ Sonarqube)

24 Intégration continue

25 Dashboard Jenkins

26 Jenkins : exemple de build

27 Jenkins : historique des builds

28 Jenkins : machines virtuelles

29 Jenkins : machines Cloud pour build

30 Logiciel libre qui automatise le déploiement d'applications dans des conteneurs logiciels.
Ecrit en GO Permet de créer et gérer des containers ( vm light ) Empaquète une application et ses dépendances dans un conteneur virtuel Les conteneurs sont isolés les uns des autres Access root Repository de Dockers Très bonnes performances cpu / mémoire Déploiement docker en quelques millisecondes et kb

31 Dockers Virtual Machines Containers

32 A suivre … Actions coordonnées dans l’équipe des développeurs
Mise en place d’outils (au LAPP / au CC) ? Git / gitlab SonarQube Jenkins ….