Industrialisation des développements logiciels

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