1.
Industrialisation des
développements
(la recette)

2.
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 Echoes
Groupe Metrixware
CTO MetrixwareProjet Recherche

3.
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

4.
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é

5.
L’industrialisation du
processus de
développement

6.
Quelles
méthodologies et outils
pour démarrer
un nouveau
développement ?

7.
Quels sont les
pré-requis pour
un projet de
développement
chez Google ?

8.
Un outil de
gestion des
exigences et
des tests
(réclamations..)

9.
Tracage des exigences
Identifiez les changements, la raison des
changements et l’époque

10.
Evaluation des spécifications
Faîtes évaluer les spécifications par les
développeurs

11.
Estimez le poids des
exigences
Estimez la charge pour chaque exigence,
visez 10 à 15j maximum.

12.
un dépôt de
source
unique qui
contient tout

13.
Stockez tout!
Utilisez votre dépôt de source pour
stocker fichiers, sources, scripts, données.

14.
Définissez votre workflow
Parce que GIT vous en offre un tout cuit

15.
Utilisation de Git + GitFlow
https://danielkummer.github.io/git-flow-cheatsheet/

16.
Les différentes Gates
Tests des fonctionnalités critiques (scénario nominal)
Charge <= 1JQ1
Tests complets : toutes les options sont testées, toutes
les interactions complexes
Charge : (max 1 semaine par env)
Q2
Q3
Tests de performance , sécurité
Charge : 1 à 2 semaine par env
Qg
Analyse qualimétrique du programme.
Règles de programmation, métriques
Charge : machine < 4h.

17.
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

18.
Un système de
gestionnaire de
sources distribué

19.
Un serveur
d’intégration
continue

20.
Ne négligez pas le
temps de build !
Parce que personne n’aime attendre.

21.
L’intégration continue
est une machine,
maintenez-la!
Inspirez-vous de la maintenance industrielle (MTBF,
MTTM, Availability)

22.
Un processus de
fabrication

23.
Le pipeline de
déploiement

24.
Build Pipeline plugin

25.
Jenkins Workflow plugin( $$$)

26.
Documentez votre
processus de fabrication

27.
Un serveur de
documentation
centralisé

28.
Générez votre
documentation
Utilisez un format de documentation pour
la génération automatique

29.
Versionnez votre
documentation
Stocker votre documentation sur votre
SCM

30.
Un dépôt
Maven/GEM/Deb

31.
Rationalisez les
technologies
Identifier et rationalisez les technologies,
suivez les évolutions

32.
Utilisez un outil
de build (Gradle,
maven, ..)

33.
Privilégiez les outils de
scripting
Parce que coder un plugin Maven ce n’est
pas sympa du tout (et maven assembly,
release…)

34.
Une architecture
d’entreprise

35.
Découvrez les outils comme Puppet,
Ansible, Docker, ...
Virtualisez vos
environnements

36.
Gestion des
livraisons et des
notes de livraison

37.
Tracez les modifications!
Associez les numéros de tickets aux
messages de commits

38.
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

39.
Pas de
contrainte sur le
choix de l’IDE

40.
Un logiciel de
suivi de bugs
(bugtracker)

41.
Personnalisez le workflow
N’oubliez pas les champs nécessaires pour calculer
les KPIs par la suite!

42.
Root Cause Analysis
Indispensable pour évaluer la qualité de votre
processus

43.
Testez votre application!
Automatisez autant que possible

44.
Mesurer la
couverture de
code

45.
Quels outils de couverture de code ?
Cobertura
Atlassian
Clover
Jacoco
Code
Cover
https://confluence.atlassian.com/display/CLOVER/Comparison+of+code+coverage+tools

46.
<project>
...
<reporting>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-
plugin</artifactId>
<version>2.7</version>
</plugin>
</plugins>
</reporting>
</project>
PetClinic Maven project
https://github.com/spring-projects/spring-petclinic/

47.
Exemple de rapport

48.
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 project
https://github.com/sleroy/spring-petclinic

49.
Rapport obtenu

50.
Pour les projets
open source :
Coveralls.io

51.
Employez des méthodologies
de tests (TDD,BDD)

52.
“Test Driven Development :
Développement piloté par les tests

53.
Crédit : alphatalk.vn

54.
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

55.
“Behaviour Driven Development :
Développement piloté par les tests

56.
Multipliez les
niveaux de tests

57.
▧ 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 :

58.
80%
Couverture de code optimale à
atteindre
(Pour les système ne menaçant pas la
vie humaine)

59.
50%
Le nombre de défauts en moyenne
supprimés par les (seuls) tests
unitaires

60.
▧ 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

61.
▧ 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

62.
▧ 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égression
Tests d’ergonomie / utilisabilité
Tests fonctionnels / système

63.
▧ 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

64.
▧ 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

65.
(A suivre)
Contrôler la qualité
du code de
l’application
(et pas que…)

66.
Merci
Vous pouvez me trouver :
@sleroy0
sylvain.leroy@tocea.com