Post on 14-Apr-2017
Industrialisation des
développements
(la recette)
Hello!Je suis Sylvain Leroy
Vous pouvez me trouver sur :sylvain.leroy@tocea.com / @sleroy0 about.me/sylvain_leroy
2007
Ingénieur Recherche
Informatique
2011
Création Société Tocea
2014
Acquisition Tocea Groupe Metrixware
CTO Tocea
2015
Acquisition EchoesGroupe Metrixware
CTO Metrixware
Projet Recherche
Ma Société
▧Assistance Qualité / Recette applications
▧Modernisation automatique d’applications
▧Offre Intégration Usine Logicielle
▧Formateurs Bonnes Pratiques /Cleancode / Qualité / Devops
▧Distributeur Outils de qualité de code (Optimyth)
▧Komea Dashboard (Pilotage développements par la qualité/productivité)
▧Offres Cobol/Mainframe
TOP 20 Justifications les plus courantes
▧ Cela fonctionne sur ma machine▧ Ou étiez-vous quand le programme a crashé ?▧ Pourquoi voulez-vous faire ceci ainsi ?▧ Vous n’utilisez pas la bonne version du système d’exploitation▧ Même si cela ne fonctionne pas, est-ce gênant ?▧ Avez vous passé l’antivirus ?▧ Quelqu’un a du changé mon code▧ Cela fonctionne mais cela n’a pas été testé▧ Ceci ne peut être à l’origine de Cela!▧ Je ne peux pas tout tester!▧ C’est juste une coïncidence malchanceuse▧ Vous ne devez pas utiliser la dernière version du logiciel▧ Je n’ai pas touché à ce module depuis des lustres!▧ Il doit avoir quelque chose de bizarre dans vos données▧ Qu’avez vous pu taper pour faire planter le logiciel ?▧ Cela doit être un problème matériel▧ Comment est-ce possible ?▧ Cela fonctionnait hier▧ Cela fonctionne sur ma machine▧ Cela n’avait jamais cela avant▧ C’est bizarre▧ C’est normal, c’est une fonctionnalité
L’industrialisation du processus de développement
Quelles méthodologies et
outils pour démarrer
un nouveau développement ?
Quels sont les pré-requis pour un projet de développement chez Google ?
Un outil de gestion des exigences et
des tests (réclamation
s..)
Tracage des exigences
Identifiez les changements, la raison des changements et l’époque
Evaluation des spécifications
Faîtes évaluer les spécifications par les développeurs
Estimez le poids des exigences
Estimez la charge pour chaque exigence, visez 10 à 15j maximum.
un dépôt de source unique qui contient tout
Stockez tout!Utilisez votre dépôt de source pour stocker fichiers, sources, scripts, données.
Définissez votre workflow
Parce que GIT vous en offre un tout cuit
Utilisation de Git + GitFlow
https://danielkummer.github.io/git-flow-cheatsheet/
Les différentes GatesTests des fonctionnalités critiques (scénario nominal)Charge <= 1J
Q1
Tests complets : toutes les options sont testées, toutes les interactions complexes Charge : (max 1 semaine par env)
Q2Q3
Tests de performance , sécuritéCharge : 1 à 2 semaine par env
Qg
Analyse qualimétrique du programme.Règles de programmation, métriquesCharge : machine < 4h.
Casser un build lors de l’analyse qualimétrique
▧Installation du plugin BuildBreaker de Sonar
▧Définition d’alertes sur les métriques ciblées
Un système de
gestionnaire de sources distribué
Un serveur d’intégration continue
Ne négligez pas le temps de build !Parce que personne n’aime attendre.
L’intégration continue
est une machine, maintenez-la!
Inspirez-vous de la maintenance industrielle (MTBF, MTTM, Availability)
Un processus
de fabrication
Le pipeline de
déploiement
Build Pipeline plugin
Jenkins Workflow plugin( $$$)
Documentez votre processus de fabrication
Un serveur de
documentation
centralisé
Générez votre documentation
Utilisez un format de documentation pour la génération automatique
Versionnez votre documentation
Stocker votre documentation sur votre SCM
Un dépôt Maven/GEM/
Deb
Rationalisez les technologies
Identifier et rationalisez les technologies, suivez les évolutions
Utilisez un outil de
build (Gradle,
maven, ..)
Privilégiez les outils de scripting
Parce que coder un plugin Maven ce n’est pas sympa du tout (et maven assembly, release…)
Une architecture d’entreprise
Découvrez les outils comme Puppet, Ansible, Docker, ...
Virtualisez vos
environnements
Gestion des livraisons et des notes
de livraison
Tracez les modifications!
Associez les numéros de tickets aux messages de commits
Gestion des livraisons▧Les dates de release
doivent être planifiées selon une fréquence régulière
▧La procédure et l’outillage de release doivent être documentés
▧Identifiez et documentez tous les éléments liés à une unité de déploiement
▧La fonction de release doit être réalisée par une entité autonome
▧Les unités de déploiement doivent être construites tôt
▧Le processus de déploiement doit être testé avant le déploiement réel.
▧Prévoyez un plan de restauration
▧Utilisez des outils▧Gérez et configurer les
outils
Pas de contrainte sur le choix
de l’IDE
Un logiciel de suivi de
bugs(bugtracker)
Personnalisez le workflow
N’oubliez pas les champs nécessaires pour calculer les KPIs par la suite!
Root Cause Analysis
Indispensable pour évaluer la qualité de votre processus
Testez votre application!
Automatisez autant que possible
Mesurer la couverture
de code
Quels outils de couverture de code ?
Cobertura Atlassian Clover
Jacoco Code Cover
https://confluence.atlassian.com/display/CLOVER/Comparison+of+code+coverage+tools
<project> ... <reporting> <plugins> ... <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.7</version> </plugin> </plugins> </reporting></project>
PetClinic Maven projecthttps://github.com/spring-projects/spring-petclinic/
Exemple de rapport
allprojects { apply plugin: 'jacoco' repositories { jcenter() } jacoco { toolVersion = '0.7.1.201405082137' }}
task jacocoRootReport(type: org.gradle.testing.jacoco.tasks.JacocoReport) { dependsOn = subprojects.test sourceDirectories = files(subprojects.sourceSets.main.allSource.srcDirs) classDirectories = files(subprojects.sourceSets.main.output) executionData = files(subprojects.jacocoTestReport.executionData) reports { html.enabled = true xml.enabled = true csv.enabled = false }}
PetClinic Gradle projecthttps://github.com/sleroy/spring-petclinic
Rapport obtenu
Pour les projets open
source : Coveralls.io
Employez des méthodologies
de tests (TDD,BDD)
“Test Driven Development :
Développement piloté par les tests
Crédit : alphatalk.vn
Astuces Tests unitaires▧Exécuter les tests en mémoire▧Ecrire les tests de manière à ce qu’ils soient
indépendants▧Les tests doivent être isolés (pas d’effet de bord)▧Exécuter chaque test (pas d’@Ignore ou de /**/)▧Ecrire chaque test sous la forme d’une assertion (ou
d’un prédicat)▧Ecrire chaque test avec l’assertion la plus forte possible▧Assurez-vous que le code requis pour les tests et
séparé du code en production▧Refactorez avant de déboguer▧Ajoutez un timeout▧Nommez bien vos tests▧Utilisez des exceptions spécifiques▧Rendez vos tests exigeants
“Behaviour Driven Development :
Développement piloté par les tests
Multipliez les niveaux
de tests
▧Tests unitaires▧Tests d’intégration▧Tests fonctionnels▧Tests d’acceptation▧Smoking Tests▧Tests de déploiement▧Tests du système▧Tests de performance▧Tests de sécurité▧Tests manuels
Les différents tests :
80%Couverture de code optimale à
atteindre(Pour les système ne menaçant pas
la vie humaine)
50%Le nombre de défauts en moyenne
supprimés par les (seuls) tests unitaires
▧Au dessus, le coût de détection des bugs est trop important
▧Intégrés directement à Eclipse, Maven ..▧Utilisation de JUnit ou TestNG▧Suivre les évolutions (régulières) des
frameworks qui simplifient l’écriture▧Les tests unitaires c’est du code, écrivez-
les bien!
Tests unitaires
▧Approche BigBang▧Approche ToP/Down▧Approche Bottom/Up▧Problématique des bases de données :
mémoire, embarquée ou simple fichier ?▧Problématique de simulation des web-
services : bouchons, stubs,...
Tests d’intégration
Vérifier le fonctionnement des “grands” composants de l’architecture
▧TF : fonctionnalités du logiciel / aux spécifications.
▧TS : fonctionnalités du logiciel / aux exigences clients.
▧Tests réalisés en boîte noire à partir d’un livrable de l’IC
▧4 Vérifications : Tests des fonctionnalités critiques (Smoke
Testing)Tests de validation de résultats (Sanity Testing)Tests de non-régressionTests d’ergonomie / utilisabilité
Tests fonctionnels / système
▧Créés généralement par le client▧Exprimés avec son vocabulaire (DDD)▧Tests boîte noire▧Utilisation d’outils comme Fitnesse
peuvent simplifier l’expression de ces tests.
Tests d’acceptation
▧Utilisation d’un outil de gestion d’exigences et de scénarios de tests
▧Un Cas de test doit avoir un objectif▧Une description de l’environnement de
test est requise▧L’installation de l’environnement de tests
doit être vérifiée▧Chaque cas de test doit être associé à un
ou plusieurs requirements▧Un cas de test doit être simple et
déterministe
Tests manuels
(A suivre)Contrôler la qualité du code de
l’application (et pas que…)
Merci
Vous pouvez me trouver :@sleroy0
sylvain.leroy@tocea.com