1
Retour d’expérience MMA
« Software factories »
Laurent Broudoux
laurent.broudoux@groupe-mma.fr
@lbroudoux
08/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
 laurent.broudoux@groupe-mma.fr, laurent.broudoux@gmail.com
 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 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
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
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 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
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
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
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
Gestion de sources
Solution Subversion
Intégration Eclipse

19
Gestion de sources
Résolution des conflits

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
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
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
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
Archiva
Un référentiel de composants

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
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è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
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 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
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
« Développer comporte des risques ! »
Risque 2
Découvrir et corriger tard les anomalies
est très couteux !

38
Le concept
Spécifications
Conceptions
Implémentation
Tests
Qualité
Pourtant, tous les logiciels
sont fabriqués comme cela …

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
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 »
« Développer comporte des risques ! »
Risque 4
Difficultés pour déployer le logiciel

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
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
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
Serveur d’Intégration Continue
Jenkins

47
Serveur d’Intégration Continue
Jenkins

48
Serveur d’Intégration Continue
Jenkins

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
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
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
Stratégies de Tests
Interaction unit testing
 Différents scopes

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
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
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
Qualité de code
Sonar

57
Qualité de code
Sonar

58
Qualité de code
Sonar

59
Qualité de code
Sonar

60
Qualité de code
Sonar

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
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
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
3. Communiquer & Déployer

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
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
Wiki
Confluence
 Wiki comme support de documentation technique

68
Wiki
Confluence
 Wiki comme support de communication roadmap / JIRA

69
Wiki
Confluence
 Wiki comme base de connaissance technique

70
Wiki
Confluence
 Wiki comme place de discussion

71
Pair Review
Crucible

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
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
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
DevOps
Le problème
 Intégration Continue et Agile nous poussent vers cette tendance …

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
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
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
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
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
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
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
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
Annexes