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
I...
Ma Société
▧ Assistance Qualité / Recette
applications
▧ Modernisation automatique
d’applications
▧ Offre Intégration Usin...
TOP 20 Justifications les plus courantes
▧ Cela fonctionne sur ma machine
▧ Ou étiez-vous quand le programme a crashé ?
▧ ...
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éclamations..)
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 Gates
Tests des fonctionnalités critiques (scénario nominal)
Charge <= 1JQ1
Tests complets : toutes les op...
Casser un build lors de l’analyse qualimétrique
▧ Installation du plugin BuildBreaker de Sonar
▧ Définition d’alertes sur ...
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, Availabili...
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’ou...
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...
<project>
...
<reporting>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-
plugin<...
Exemple de rapport
allprojects {
apply plugin: 'jacoco'
repositories { jcenter() }
jacoco { toolVersion = '0.7.1.201405082137' }
}
task jacoc...
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
▧ Le...
“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
...
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 ...
▧ Approche BigBang
▧ Approche ToP/Down
▧ Approche Bottom/Up
▧ Problématique des bases de données :
mémoire, embarquée ou s...
▧ TF : fonctionnalités du logiciel / aux
spécifications.
▧ TS : fonctionnalités du logiciel / aux
exigences clients.
▧ Tes...
▧ Créés généralement par le client
▧ Exprimés avec son vocabulaire (DDD)
▧ Tests boîte noire
▧ Utilisation d’outils comme ...
▧ Utilisation d’un outil de gestion d’exigences
et de scénarios de tests
▧ Un Cas de test doit avoir un objectif
▧ Une des...
(A suivre)
Contrôler la qualité
du code de
l’application
(et pas que…)
Merci
Vous pouvez me trouver :
@sleroy0
sylvain.leroy@tocea.com
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Industrialisation des développements logiciels
Prochain SlideShare
Chargement dans…5
×

Industrialisation des développements logiciels

295 vues

Publié le

Quelques slides autour de l'industrialisation des développements logiciels, les enjeux, les outils, quelques méthodes pour gagner en temps.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
295
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • ANomalie : Toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. Voir aussi défauts, déviation, erreur, faute, défaillance, incident, problème.
  • Versioner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Wiki, etc
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • http://agiledata.org/essays/tdd.html


  • http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • Industrialisation des développements logiciels

    1. 1. Industrialisation des développements (la recette)
    2. 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. 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. 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. 5. L’industrialisation du processus de développement
    6. 6. Quelles méthodologies et outils pour démarrer un nouveau développement ?
    7. 7. Quels sont les pré-requis pour un projet de développement chez Google ?
    8. 8. Un outil de gestion des exigences et des tests (réclamations..)
    9. 9. Tracage des exigences Identifiez les changements, la raison des changements et l’époque
    10. 10. Evaluation des spécifications Faîtes évaluer les spécifications par les développeurs
    11. 11. Estimez le poids des exigences Estimez la charge pour chaque exigence, visez 10 à 15j maximum.
    12. 12. un dépôt de source unique qui contient tout
    13. 13. Stockez tout! Utilisez votre dépôt de source pour stocker fichiers, sources, scripts, données.
    14. 14. Définissez votre workflow Parce que GIT vous en offre un tout cuit
    15. 15. Utilisation de Git + GitFlow https://danielkummer.github.io/git-flow-cheatsheet/
    16. 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. 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. 18. Un système de gestionnaire de sources distribué
    19. 19. Un serveur d’intégration continue
    20. 20. Ne négligez pas le temps de build ! Parce que personne n’aime attendre.
    21. 21. L’intégration continue est une machine, maintenez-la! Inspirez-vous de la maintenance industrielle (MTBF, MTTM, Availability)
    22. 22. Un processus de fabrication
    23. 23. Le pipeline de déploiement
    24. 24. Build Pipeline plugin
    25. 25. Jenkins Workflow plugin( $$$)
    26. 26. Documentez votre processus de fabrication
    27. 27. Un serveur de documentation centralisé
    28. 28. Générez votre documentation Utilisez un format de documentation pour la génération automatique
    29. 29. Versionnez votre documentation Stocker votre documentation sur votre SCM
    30. 30. Un dépôt Maven/GEM/Deb
    31. 31. Rationalisez les technologies Identifier et rationalisez les technologies, suivez les évolutions
    32. 32. Utilisez un outil de build (Gradle, maven, ..)
    33. 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. 34. Une architecture d’entreprise
    35. 35. Découvrez les outils comme Puppet, Ansible, Docker, ... Virtualisez vos environnements
    36. 36. Gestion des livraisons et des notes de livraison
    37. 37. Tracez les modifications! Associez les numéros de tickets aux messages de commits
    38. 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. 39. Pas de contrainte sur le choix de l’IDE
    40. 40. Un logiciel de suivi de bugs (bugtracker)
    41. 41. Personnalisez le workflow N’oubliez pas les champs nécessaires pour calculer les KPIs par la suite!
    42. 42. Root Cause Analysis Indispensable pour évaluer la qualité de votre processus
    43. 43. Testez votre application! Automatisez autant que possible
    44. 44. Mesurer la couverture de code
    45. 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. 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. 47. Exemple de rapport
    48. 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. 49. Rapport obtenu
    50. 50. Pour les projets open source : Coveralls.io
    51. 51. Employez des méthodologies de tests (TDD,BDD)
    52. 52. “Test Driven Development : Développement piloté par les tests
    53. 53. Crédit : alphatalk.vn
    54. 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. 55. “Behaviour Driven Development : Développement piloté par les tests
    56. 56. Multipliez les niveaux de tests
    57. 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. 58. 80% Couverture de code optimale à atteindre (Pour les système ne menaçant pas la vie humaine)
    59. 59. 50% Le nombre de défauts en moyenne supprimés par les (seuls) tests unitaires
    60. 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. 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. 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. 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. 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. 65. (A suivre) Contrôler la qualité du code de l’application (et pas que…)
    66. 66. Merci Vous pouvez me trouver : @sleroy0 sylvain.leroy@tocea.com

    ×