Rex Software Factories 20140117 - Ensim

891 vues

Publié le

Retour d'expérience sur la mise en place d'usines logicielles chez MMA faite pour l'Ensim (Ecole Nationale Supérieure d'Ingénieurs du Mans), niveau Master. Contenu : définitions, processus de développement agile et étapes de déploiement.

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

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

Aucune remarque pour cette diapositive

Rex Software Factories 20140117 - Ensim

  1. 1. 1 Retour d’expérience MMA « Software factories » Laurent Broudoux laurent.broudoux@groupe-mma.fr @lbroudoux 08/01/2015
  2. 2. 2 Historique Version Date Auteur Motif 0.1 17/01/2014 L. Broudoux Création 0.2 05/01/2015 L. Broudoux Mise à jour (coquilles + actualisation)
  3. 3. 3 Quelques mots …  Laurent Broudoux  Le jour …  Architecte IT Senior chez MMA  Mots-clés : Java, SOA, MDE, Agile, Software Factories  La nuit ...  Coder, geek, open source comitter (voir http://www.githu.com/lbroudoux)  Me joindre / suivre  @lbroudoux  laurent.broudoux@groupe-mma.fr, laurent.broudoux@gmail.com  http://lbroudoux.wordpress.com
  4. 4. 4 Keywords
  5. 5. 5 Réchauffement … (enfin, j’espère …) Qui a rencontré les termes suivants ? TDD – DevOps - Continuous Delivery Qui possède un compte chez Github ?
  6. 6. 6 Quelle est la situation?
  7. 7. 7 Développer seul « Un poste, un environnement de développement … et c’est parti ! »  Rien de plus simple !
  8. 8. 8 Développement en équipe  Un travail épanouissant !  Mais des difficultés une fois soumis aux contraintes de l’entreprise  Comment partager mon travail avec mes collègues ?  Comment ne pas écraser malencontreusement le travail de mes collègues ?  Comment garantir le respect d’un style de coding ?  Comment me coordonner avec mes collègues ?  Comment détecter et déterminer qui a introduit une régression ?  Comment vérifier la qualité de ce qui est produit collectivement ?  …
  9. 9. 9 Software factories ? Factory = Normes + Processus + Équipes + Outils “A Software Factory is a software product line that configures extensible tools, processes and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling and configuring framework-based components. “ “ A software factory is a structured collection of related software assets. When a software factory is installed in a development environment, it helps architects and developers predictably and efficiently create high-quality instances of specific types of applications.”  « Software Factories » [Greenfield, Short – 2004]  Microsoft Patterns & Practices Team
  10. 10. 10 Développer ensemble Illustration d’une software factory Référentiel de Sources Référentiel Documentaire Référentiel de Composants Référentiel Qualimétrique Référentiel d’Activités Plateforme d’Intégration Continue Référentiel de Revues  Au-delà de l’IDE, un écosystème riche pour supporté un processus de développement complet
  11. 11. 11 Un processus de construction Proposition Historiser & Partager Intégrer, intégrer, intégrer, … Communiquer & Déployer Comment sécuriser les développements afin de pouvoir les partager, les propager efficacement au sein de toute l’équipe ? Comment faire pour savoir qui a fait quoi, a quel moment ? Comment détecter efficacement les régressions et les problèmes d’incompatibilité ? Comment développer et dormir ensuite « sur ses 2 oreilles » ? Comment passer au niveau supérieur (> 20 développeurs par équipe), s’inscrire dans le temps, la qualité et l’efficacité optimale ?
  12. 12. 12 Cette présentation ne couvre pas l’étape 0 de l’industrialisation ! Cette étape consiste à sélectionner les frameworks, langages ou socles de développement pour garantir l’homogénéité des applications réalisées. Cette étape est très dépendante du contexte de votre entreprise : - du type d’applications produites, - de sa stratégie d’urbanisation, - des ressources humaines (développeurs et support) ! Ex: les frameworks MMA
  13. 13. 13 1. Historiser & Partager
  14. 14. 14 Etape 1 Historiser & Partager Historiser & Partager Comment sécuriser les développements afin de pouvoir les partager, les propager efficacement au sein de toute l’équipe ? Comment faire pour savoir qui a fait quoi, a quel moment ? 1 Gestion de sources 2 Système de build 3 Gestion d’activités
  15. 15. 15 Gestion de sources Le problème  Le problème typique : Harry rencontre Sally ! Comment éviter que le travail de Harry soit « écrasé » par Sally ?
  16. 16. 16 Gestion de sources Principes d’un référentiel  Copie de travail vs Référentiel Centralisé  Chaque développeur possède sa (ou ses) propre(s) copie(s) de travail. Elles résident sur son disque dur.  Le Référentiel est unique, centralisé, accessible par tous (lecture et/ou écriture) et sécurisé Copie de travail : sur chaque poste de développeurs Le référentiel : vision historisée A chaque ensemble de modifications acceptées par le référentiel, création d’un nouvel état de l’arborescence de ressources. Cet état est appelée une révision. Chaque révision est récupérable par la suite et comparable à une révision précédente. Checkout Commit
  17. 17. 17 Gestion de sources Stratégies de gestion de branches  Tronc Instable, les branches accueillent les maintenances. La version à venir est sur le tronc  + simple à appréhender : conseillé pour petites équipes avec sprints rapides.  Tronc Stable, les branches accueillent les développements pour une version ou une fonctionnalité données. Convergence sur le tronc.  + complexe mais + puissant : conseillé pour équipes conséquentes, responsabilisées ou organisées en Agile
  18. 18. 18 Gestion de sources Solution Subversion Intégration Eclipse
  19. 19. 19 Gestion de sources Résolution des conflits
  20. 20. 20 Système de build Le problème Comment automatiser les étapes de compilation et packaging ? Comment homogénéiser les commandes sur différents projets (éventuellement de différentes natures) ? Comment diffuser rapidement les applications ou composants produits ? Les mettre à disposition d’autres composants utilisateurs ? En mettant en œuvre un Système de build évolué ! Cet outil sera responsable d’abstraire le processus de construction tout en le rendant configurable. Il pourra également proposé un système de référencement et de partage des composants.
  21. 21. 21 Maven Présentation <project> <modelVersion>4.0.0</modelVersion> <!-- The Basics --> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <packaging>...</packaging> <dependencies>...</dependencies> <properties>...</properties> <!-- Build Settings --> <build>...</build> <reporting>...</reporting> <!-- More Project Information --> <name>...</name> <description>...</description> <url>...</url> <organization>...</organization> <developers>...</developers> <!-- Environment Settings --> <issueManagement>...</issueManagement> <ciManagement>...</ciManagement> <mailingLists>...</mailingLists> <scm>...</scm> <repositories>...</repositories> <pluginRepositories>...</pluginRepositories> <distributionManagement>...</distributionManagement> <profiles>...</profiles> </project>  Maven  Open source sous ombrelle Apache  Un framework pour la construction de projet  Ensemble de standards de build  Modèle de référentiels d’artifacts  Moteur de communication de projet  Notion principale : le POM  Project Object Model  Document contenant toutes les informations sur le projet : pom.xml  Transitivité des dépendances  Héritage de POM
  22. 22. 22 Maven Caractéristiques d’un projet <project> <modelVersion>4.0.0</modelVersion> <groupId>fr.mma.teamA</groupId> <artifactId>my-project</artifactId> <version>1.0.0</version> <packaging>jar</packaging> </project>  Convention over Configuration  Organisation standardisée  1 projet => 1 résultat (.jar, .war, .ear, .zip)  Conventions de nommage  Réutilisation de la logique de construction  Moteur de coordination  Tout est plugin !  Project Object Model  Plugins par défaut en fonction du packaging  Cycle de construction  Correspondance plugins / phases Même démarche et mêmes commandes qq soit le composant.
  23. 23. 23 Maven Gestion des dépendances <project> <modelVersion>4.0.0</modelVersion> <groupId>fr.mma.teamA</groupId> <artifactId>my-project</artifactId> <version>1.0.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> http://central.apache.org http://repository.jboss.org Local Local Local Référentiel de Composants Central GET GET CACHE CACHE
  24. 24. 24 Archiva Un référentiel de composants
  25. 25. 25 Gestion des activités Le problème Au-delà de la Gestion de sources qui m’offre une vision fine et technique, je voudrai disposer d’une vision macro favorisant la communication et la distribution du travail. Responsable d’équipe / leader
  26. 26. 26 Gestion d’activité Produit JIRA
  27. 27. 27 Gestion d’activité Exemple d’issue Version du composant portant la correction Ensemble des sources modifiés + accès aux deltas
  28. 28. 28 Gestion d’activité Intégration dans l’IDE Les détails de ma tâche en cours Le contexte de travail associé à la tâche et partagé entre les développeurs Indicateur de tâche en cours
  29. 29. 29 Gestion d’activité Exemple de workflow Développeur Le responsable de développement réalise ces demandes d’évolutions. 1 2 Le développeur est notifié de la présence d’une nouvelle demande ou d’un bug à corriger. Il visualise depuis son IDE (ou un site web) l’avancement du projet 3 Implémentation 4 Le développeur réalise l’implémentation ou la correction et met à jour l’issue au sein de JIRA. Le workflow se poursuit. La mise à jour de l’issue fait progresser le workflow et met à jour les rapports d’avancement de la version en cours de réalisation. Responsable de Développement, Développeur
  30. 30. 30 Points Clés Synthèse 1 La Gestion de sources permet d’historiser, de partager et de sécuriser le code source développé. Elle permet de détecter les conflits éventuels et de les résoudre. Elle permet également le travail en parallèle et isolation sur plusieurs versions ou fonctionalités. 2 Un Système de build permet d’automatiser le cycle de construction d’un composants, d’une application. Il permet d’offrir une interface homogène quelque soit le composant. La mise en place d’un référentiel permet le partage rapide des binaires construits. 3 La Gestion d’activités offre une meilleure vision de l’activité d’une équipe. Elle favorise la communication, minimisant ainsi les cas de conflit. Elle permet une mise en correspondance fonction  code source.
  31. 31. 31 Synthèse Etat de notre Software Factory Référentiel de Sources Référentiel Documentaire Référentiel de Composants Référentiel Qualimétrique Référentiel d’Activités Plateforme d’Intégration Continue Référentiel de Revues
  32. 32. 32 Et moi, et moi, et moi ?... Quelles autres solutions : pour un projet plus restreint, pour des équipes plus petites, pour un budget plus limité, pour des technos différentes ? Gestion de sources - GitHub pour des projets OpenSource - BitBucket pour des projets OpenSource ou Privés - Unfuddle Issue Tracking - Redmine, Trac, Mantis pour une installation On Premise - JIRA en mode SaaS (ex: relation partenaire) Build Tools & repository - Ivy ou Gradle pour des projets sur langage JVM ou autres - Rake pour des projets Ruby - Grunt ou Gulp pour des projets Javascript / HTML / CSS - Ivy repository - NPM repository pour projets Javascript
  33. 33. 33 2. Intégrer, intégrer, intégrer …
  34. 34. 34 Etape 2 Intégrer, intégrer, intégrer, … Intégrer, intégrer, intégrer, … Comment détecter efficacement les régressions et les problèmes d’incompatibilité ? Comment développer et dormir ensuite « sur ses 2 oreilles » ? 1 Intégration Continue 2 Tests Unitaires 3 Qualité de code
  35. 35. 35 Développer un logiciel comporte des risques !
  36. 36. 36 « Développer comporte des risques ! » Risque 1 Ne pas aboutir !!  En 2008, une enquête du Standish Group révèle les informations suivantes :  21 % des projets informatiques sont arrêtés en cours de route  44 % n’aboutissent qu’au prix d’un important dépassement des délais ou du budget  35 % des projets peuvent être considérés comme des succès
  37. 37. 37 « Développer comporte des risques ! » Risque 2 Découvrir et corriger tard les anomalies est très couteux !
  38. 38. 38 Le concept Spécifications Conceptions Implémentation Tests Qualité Pourtant, tous les logiciels sont fabriqués comme cela …
  39. 39. 39 « Développer comporte des risques ! » Risque 3 Manque de visibilité dans le projet. « Qu'est-ce que tu entends par les tests échouent ? » « Quel est le contenu de la version 1.2.3 ? » « Quels sont nos indicateurs qualité ? »
  40. 40. 40 L'effet tunnel, vous connaissez ?
  41. 41. 41 « Pourtant, ça marche sur ma machine ... » « J'ai besoin de déployer en assemblage pour tester » « Le [chef|client|patron] arrive. On doit montrer l'avancement asap » « Développer comporte des risques ! » Risque 4 Difficultés pour déployer le logiciel
  42. 42. 42 « Développer comporte des risques ! » Utilisez l'Intégration Continue (IC) pour réduire ces risques. L’Intégration Continue n’est pas un outil mais une pratique de génie logiciel issue des méthodes agile (XP, Scrum, …) Cette pratique cherche à accélérer le temps global de construction en réduisant le temps d’intégration. Elle consiste à intégrer souvent et à progresser par petites étapes en vérifiant qu’à chaque modification de code on introduit pas de régression et que l’on est toujours capable de construire ou déployer le logiciel.
  43. 43. 43 Intégration Continue Les bonnes pratiques de l’IC portent des notions de fiabilisation mais pas d’accélération directe ! L’accélération en est fait induite par l’amélioration de la détection des problèmes  Bonnes pratiques !  Maintenir un référentiel de code source unique,  Automatiser les fabrications (ou builds),  Rendre les fabrications auto-testantes,  Tout le monde intègre (ou commit) tous les jours,  La fabrication doit être faite sur la même branche que la livraison,  Maintenir la fabrication rapide et stable,  Rendre disponible la dernière fabrication,  Assurer la visibilité de tous les changements entre 2 builds,  Automatiser le déploiement sur les environnements représentatifs.
  44. 44. 44 Les développeurs sont les premiers acteurs.
  45. 45. 45 Serveur d’Intégration Continue Référentiel de Sources Référentiel de Composants Checkout / Commit Compilation Packaging Compilation Packaging Tests … Publication Checkout Serveur d’Intégration Continue Le Serveur d’Intégration Continue est un composant central qui va être en charge : d’extraire le code source du référentiel, dérouler le processus de construction-packaging-test-etc et publier un binaire correspondant en cas de succès. Ce processus peut se dérouler périodiquement ou à chaque compilation !
  46. 46. 46 Serveur d’Intégration Continue Jenkins
  47. 47. 47 Serveur d’Intégration Continue Jenkins
  48. 48. 48 Serveur d’Intégration Continue Jenkins
  49. 49. 49 Tests Unitaires Le problème Pas simple la vie de développeur ! On écrit beaucoup de code … et un jour quelque chose ne fonctionne pas ou ne fonctionne plus ! La correction d’un bug est aisée mais trouver ce bug peut-être un cauchemar : - des heures devant le debugger - des heures à lire des logs et essayer de rejouer le cas Et puis, quand je corrige, je peux casser d’autres parties … En plus, le bug peut réapparaitre !
  50. 50. 50 Tests Unitaires Un autre modèle ? Spécifications, Architecture, Conception Intentions Réalité Tests (dont unitaires), Assurance Qualité Justification Fossé ! Vérification de la réalité Implémentation, Déploiement
  51. 51. 51 Tests Unitaires Présentation  Elémentaire : implique de connaître la granularité du découpage,  Déterminée : implique de connaître les échantillons du découpage, Tests Unitaires vs Tests Fonctionnels Tests unitaires Tests unitaires Appels de méthodes Tests fonctionnels Procédé automatique permettant de s’assurer du fonctionnement correct d’une partie élémentaire et déterminée d’un logiciel ou d’un composant. [Wikipedia] Le développeur écrit les tests !
  52. 52. 52 Stratégies de Tests Interaction unit testing  Différents scopes
  53. 53. 53 Stratégies de Tests  Différents objectifs et différents outils en fonction de la nature du test Logical Unit Testing On s’intéresse aux résultats retournés par les méthodes d’un composant. On privilégie des outils tels que JUnit (ou xUnit quelque soit le langage) Interaction Unit Testing On s’intéresse aux interactions de notre composant avec un autre composant. On utilise notamment des frameworks de Mocking (Mockito ou EasyMock). Integration Unit Testing On s’intéresse aux résultats retournés par un composant utilisant une ressource. On privilégie des outils tels que Spring + * (DBUnit, H2, Fongo, etc …) Functional Unit Testing On s’intéresse aux résultats retournés par un système complet. On privilégie des outils tels que Fitness, Cucumber, GreenPepper, … offrant un DSL permettant de spécifier des attentes.
  54. 54. 54 Stratégies de Tests Ajouter un Test Modifier le code Valider les changements Refactorer le code SUCCES SUCCES SUCCES ECHEC Spécifications Bug  Test Driven Development ou TDD  Utiliser les Tests dés le début du processus de développement !
  55. 55. 55 Qualité de code Le problème Responsable d’équipe / leader Pas simple la vie de développeur leader ! Ces satanés développeurs … tous à écrire du code de façon différente … une fois en conservant les { sur la ligne, d’autres fois en les mettant sur la ligne suivante … Et puis, il y a des novices dans mon équipe ! Ils ne connaissent pas forcément toutes les bonnes pratiques du langage … En plus, certains sont trop pressés ou fainéants : il n’écrivent pas de tests unitaires !! Automatisons l’analyse de code ! Après avoir défini (et communiqué !) des règles, fournissons des outils permettant de détecter et présentation les violations. Suivons également la tendance pour objectiver la prise en compte des recommandations par l’équipe ! Autre usage : détection de l’accumulation des dettes techniques …
  56. 56. 56 Qualité de code Sonar
  57. 57. 57 Qualité de code Sonar
  58. 58. 58 Qualité de code Sonar
  59. 59. 59 Qualité de code Sonar
  60. 60. 60 Qualité de code Sonar
  61. 61. 61 Points Clés Synthèse 1 L’Intégration Continue est une technique permettant de détecter rapidement les conflits ou régressions. Elle fiabilise alors le processus de mise en commun. Sa mise en œuvre s’appuie sur un serveur central. 2 Les Tests Unitaires apportent une mécanique de définition et vérification des attentes (spécifications) d’une application ou d’un composant. Ils peuvent s’exécuter de façon automatique, intégrés dans le processus d’IC. 3 La vérification de la qualité de code détecte les hétérogénéités de code ainsi que les portions de codes non testées. Le suivi des indicateurs dans le temps permet de se challenger sur la production d’un code performant et maintenable.
  62. 62. 62 Synthèse Etat de notre Software Factory Référentiel de Sources Référentiel Documentaire Référentiel de Composants Référentiel Qualimétrique Référentiel d’Activités Plateforme d’Intégration Continue Référentiel de Revues
  63. 63. 63 Et moi, et moi, et moi ?... Quelles autres solutions : pour un projet plus restreint, pour des équipes plus petites, pour un budget plus limité, pour des technos différentes ? Intégration Continue - TravisCI pour des projets OpenSource - CloudBees, Bamboo pour des projets OpenSource ou Privés Tests unitaires - xUnit sur pratiquement toutes les plateformes - Jasmine / Karma pour Javascript Tests d’intégration - Arquilian pour les tests « in container » sur JVM - Protractor pour Javascript Qualité de code et couverture - Checkstyle, PMD, FindBugs, Cobertura, Jacoco / EclEmma pour Java - JsLint, JsHint pour Javascript
  64. 64. 64 3. Communiquer & Déployer
  65. 65. 65 Etape 3 Communiquer & Déployer Communiquer & Déployer Comment passer au niveau supérieur (> 20 développeurs par équipe), s’inscrire dans le temps, la qualité et l’efficacité optimale ? 1Wiki & Pair reviews 2Déploiement Continu 3DevOps
  66. 66. 66 Wiki & Pair Review Le problème Les pratiques de gestion de sources et d’activités ont été mises en places lors de la phase de construction du projet. Sont-elles suffisantes pour permettre à mon application : - de vivre (voire survivre ;-) ) plusieurs décennies ? Tout cela en considérant le turnover humain ? - de monter à l’échelle ? C’est-à-dire d’être appréhender par toutes les équipes dans l’organisation ? Des outils supplémentaires de gestion documentaire ou de revue collaborative fournissent un prétexte supplémentaire pour communiquer, échanger, partager autour du patrimoine applicatif.
  67. 67. 67 Wiki Confluence  Wiki comme support de documentation technique
  68. 68. 68 Wiki Confluence  Wiki comme support de communication roadmap / JIRA
  69. 69. 69 Wiki Confluence  Wiki comme base de connaissance technique
  70. 70. 70 Wiki Confluence  Wiki comme place de discussion
  71. 71. 71 Pair Review Crucible
  72. 72. 72 Wiki, Pair Review et Gestion d’activités Synthèse Gestion d’activité Revue de code Revue de code Gestion des connaissances et infos Partage et contextes de travail Développeurs Correspondant Technique Responsable d’activité Support aux développement Visibilité Communication
  73. 73. 73 Déploiement Continu Principes Référentiel de Sources Référentiel de Composants Build Compliance Build simple Release Build Deploy QA Deploy Prod Build Deploy QA Build Pipeline Référentiel Qualimétrique Plateforme d’Intégration Continue  De l’Intégration Continue …  Depuis 2008 : utilisation de la plateforme pour construire les applications  Builds continus sur les SNAPSHOTs : compile, test, package, deploy  Builds plannifiés : qualimétrie et alimentation Sonar au quotidien,  Builds « manuels » : production des RELEASEs  … au déploiement continu.  Construire les applications, déployer et tester en continu !  Build Pipelines ! (soumis ou non à approbation)
  74. 74. 74 Déploiement Continu Implémentation des Pipelines Validation composants Workflow d’intégration et de déploiement continus (« pipeline ») Référentiel de binaires Référentiel de sources DEVELOPPEMENT DEPLOIEMENT Continuous Build Fabrique GEV Développeur BUILD SNAPSHOT BUILD SNAPSHOT COMPLIANCECOMPLIANCE BUILD RELEASE BUILD RELEASE DEPLOY GEV DEPLOY GEV DEPLOY PROD DEPLOY PROD Livreur MEP DEPLOY ASSDEPLOY ASS Serveurs de validation Serveurs de PROD Serveurs d’assemblage TESTTEST TESTTEST
  75. 75. 75 DevOps Le problème  Intégration Continue et Agile nous poussent vers cette tendance …
  76. 76. 76 DevOps Le problème  Le Mur de la confusion Changement ! Stabilité ! Développement (Dev) Production / Operations (Ops) Outils de Dev Outils de Prod
  77. 77. 77 DevOps Présentation Culture et partage sont indispensables ! Nous n’en sommes qu’aux balbutiements … La partie Dev va devoir : -intégrer les contraintes de production (résilience, performance, consommation), -intégrer les exigences de suivi (traces, dissociation mise en production / mise en service) La partie Ops va devoir : -appliquer les principes du génie logiciel à ses processus, -etre en mesure d’automatiser à outrance, -suivre la consommation en temps réel pour refacturation adhoc, -etc …
  78. 78. 78 DevOps Infrastructure as code - Chef Les recettes et livres de cuisines : des fichiers de configurations permettant de décrire la façon d’installer des composants applicatifs et techniques (DSL) Les définitions de nœuds : utilisés comme références des configurations à installer / déployer sur les nœuds Utilisation d’un référentiel Subversion comme stockage. Approche DevOps : l’infrastructure est traitée comme du code.
  79. 79. 79 DevOps Outillage Chef 2 – Récupération des RE7 CHEF Appli A 5 - installation Référentiel de code source (scripts CHEF) Référentiel des composants JAVA/HTML MMA Référentiel des binaires Référentiel des variables Serveur X 3 – Récupération des binaires d’installation 4 – récupération des applications 5 – récupération des valeurs des variables à valoriser REF-logiciels 1 – lancement des scripts CHEF sur machine cible OU Console de pilotage du déploiement En 1 commande : réinstallation complète de la stack logicielle ! OS / VM Logiciels Application Hardware
  80. 80. 80 DevOps Référentiel de déploiement  En complément de Chef, un outil permettant de tracer tous les déploiements réalisés
  81. 81. 81 Synthèse Points Clés 1 Wiki et système de pair review sont un pas supplémentaire vers la communication et donc l’agilité. Ils mettent à disposition des moyens pour facilement : documenter, enrichir et partager le savoir collectif autour du patrimoine. 2 Déploiement Continu est une extension naturelle de l’Intégration Continu. Il permet d’augmenter la vélocité et réduire le Time to Market tout en permettant de conserver traçabilité et visibilité. 3 DevOps est avant tout un défi culturel donc organisationnel. Des outils basiques existent pour automatiser de grand pans des processus, ils sont insuffisants aujourd’hui sur la totalité du périmètre.
  82. 82. 82 Synthèse Etat de notre Software Factory Référentiel de Sources Référentiel Documentaire Référentiel de Composants Référentiel Qualimétrique Référentiel d’Activités Plateforme d’Intégration Continue Référentiel de Revues Référentiel Variables
  83. 83. 83 Et moi, et moi, et moi ?... Quelles autres solutions : pour un projet plus restreint, pour des équipes plus petites, pour un budget plus limité, pour des technos différentes ? Wiki et Pair review - GitHub pour des projets OpenSource - BitBucket pour des projets OpenSource ou Privés - Gogs, Redmine ou Trac pour les projets on premise - Gerrit pour les utilisateurs du « raw » Git DevOps tools - Puppet - Run Deck - Docker - Shell scripts !!
  84. 84. 84 Annexes

×