Rex Software Factories 20140117 - Ensim

1

Retour d’expérience MMA« Software factories »

Laurent [email protected]

@lbroudoux08/01/2015

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

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

[email protected], [email protected]

http://lbroudoux.wordpress.com

4

Keywords

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

Quelle est la situation?

7

Développer seul

« Un poste, un environnement de développement … et c’est parti ! »

Rien de plus simple !

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

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

Développer ensembleIllustration 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

Un processus de constructionProposition

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

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

1. Historiser & Partager

14

Etape 1Historiser & 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

Gestion de sourcesLe problème

Le problème typique : Harry rencontre Sally !

Comment éviter que le travail de Harry soit « écrasé » par Sally ?

16

Gestion de sourcesPrincipes 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

Gestion de sourcesStraté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

Gestion de sourcesSolution Subversion

Intégration Eclipse

19

Gestion de sourcesRésolution des conflits

20

Système de buildLe 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

MavenPrésentation

<project> <modelVersion>4.0.0</modelVersion>  <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <packaging>...</packaging> <dependencies>...</dependencies> <properties>...</properties>  <build>...</build> <reporting>...</reporting>  <name>...</name> <description>...</description> <url>...</url> <organization>...</organization> <developers>...</developers>  <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

MavenCaracté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

MavenGestion 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

GETGET

CACHE

CACHE

24

ArchivaUn référentiel de composants

25

Gestion des activitésLe 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

Gestion d’activitéProduit JIRA

27

Gestion d’activitéExemple d’issue

Version du composant portant la correction

Ensemble des sources

modifiés + accès aux

deltas

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

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

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

SynthèseEtat de notre Software Factory








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

2. Intégrer, intégrer, intégrer …

34

Etape 2Inté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

Développer un logiciel

comporte des risques !

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


Risque 2

Découvrir et corriger tard les anomaliesest très couteux !

38

Le concept

Spécifications

Conceptions

Implémentation

Test

s

Qualité

Pourtant, tous les logiciels

sont fabriqués comme cela …

39


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

L'effet tunnel,

vous connaissez ?

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 »


Risque 4

Difficultés pour déployer le logiciel

42


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

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

Les développeurs sont

les

premiers acteurs.

45

Serveur d’Intégration Continue



Checkout / Commit

Compilation

Packaging

Compilation

Packaging

Tests

…

PublicationCheckout

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

Serveur d’Intégration ContinueJenkins

47


48


49

Tests UnitairesLe 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

Tests UnitairesUn autre modèle ?

Spécifications, Architecture, Conception

Intentions Réalité

Tests (dont unitaires), Assurance Qualité

Justification

Foss

é !

Vérifica

tion de la

réalité

Implémentation, Déploiement

51

Tests UnitairesPré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 unitairesAppels 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

Stratégies de Tests

Interaction unit testing

Différents scopes

53


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


Ajouter un Test

Modifier le code

Valider leschangements

Refactorerle 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

Qualité de codeLe 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

Qualité de codeSonar

57


58


59


60


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









63



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

3. Communiquer & Déployer

65

Etape 3Communiquer & 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

Wiki & Pair ReviewLe 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

WikiConfluence

Wiki comme support de documentation technique

68

WikiConfluence

Wiki comme support de communication roadmap / JIRA

69

WikiConfluence

Wiki comme base de connaissance technique

70

WikiConfluence

Wiki comme place de discussion

71

Pair ReviewCrucible

72

Wiki, Pair Review et Gestion d’activitésSynthèse

Gestion d’activité

Revue de code

Revue de code

Gestion des connaissances

et infos

Partage et contextes de travail

Développeurs

Correspondant

TechniqueResponsable

d’activité

Support aux développement

Visibilité

Communication

73

Déploiement ContinuPrincipes

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


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

Déploiement ContinuImplé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

FabriqueGEV

Développeur

BUILDSNAPSHOT

BUILDSNAPSHOT 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

DevOpsLe problème

Intégration Continue et Agile nous poussent vers cette tendance …

76

DevOpsLe problème

Le Mur de la confusion

Changement ! Stabilité !

Développement(Dev)

Production / Operations(Ops)

Outils de Dev Outils de Prod

77

DevOpsPré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

DevOpsInfrastructure 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

DevOpsOutillage 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 CHEFsur machine cible

OUConsole de pilotage du déploiement

En 1 commande : réinstallation complète de la stack logicielle !

OS / VM

Logiciels

Application

Hardware

80

DevOpsRéférentiel de déploiement

En complément de Chef, un outil permettant de tracer tous les déploiements réalisés

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









Référentiel Variables

83



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

Annexes

Technology

Rex Software Factories 20140117 - Ensim