Environnement
Avant de donner la recette pour la mise en oeuvre de hudson, nous
allons donner quelques définitions. En effet, certains termes
utilisé dans ce document ont un sens variable suivant le
contexte.
Précisons d'abord les rôles des différents
environnements :
- Environnement d'Intégration : sert à
valider manuellement que le le comportement du produit est
identique sur les environnements de développement et sur la
plateforme cible. L'environnement d'intégration doit être
un clone des plateformes de production.
- Environnement Intégration continue : sert à
valider automatiquement que le le comportement du produit est
identique sur les environnements de développement et sur la
plateforme cible. L'environnement d'intégration doit être
un clone des plateformes de production.
Environnement de Validation :
sert à vérifier
que le produit est conforme aux spécifications.
Jeu de test :
Ensemble de données nécessaires au passage d'un test
Test unitaire : Théoriquement
il s'agit d'un test vérifiant une exigence, mais dans ce
document, nous l'utiliserons dans son acception consacrée test
Junit.
Bénéfices de l'intégration
continue
Dans les configurations de développement JAVA« standard »,
le codage s'effectue sur Windows et l'intégration s'effectue
sur LINUX/UNIX, il est donc fréquent d'avoir des surprises au
moment de passer sur l'environnement cible, les environnements
d'intégration permettent anticiper les problèmes
techniques.
L'intégrateur identifie les dysfonctionnements et les
corrige. Malheureusement, dans la plupart des configurations projet,
personne n'étant affecté exclusivement à
l'intégration et les soucis d'intégration tendent à
être reléguées aux dernières tâches.
Au delà de l'effet de mode, le principal bienfait de
l'intégration continue sera d'améliorer la visibilité
de ces problématiques.
L’intégration continue valide automatiquement le
produit sur la plateforme cible.
- Permet de détecter au plus tôt les problèmes
de dépendance aux environnements : File System, Encoding,
Case-sensitive, performances etc.
- Permet de lisser le stress dans l'équipe (plus de
pression dans les phases précoces, moins au moment de la
livraison)
- Il donne une aperçu de la qualité du produit au
chef de projet et donne confiance au moment de la livraison
.
Impacts structurants de l'intégration
continue
Contraintes de codage
L'ensemble des projets sur le référentiel de source
doit être compilable à tout moment.
Pour l'intégration continue, le développeur est
contraint d'écrire des tests unitaires.
Test unitaires
Dans un monde systématique, chaque exigence devrait être
vérifiée par un test unitaire, inversement, chaque test
unitaire devrait se mettre en relation avec une seule exigence.
Cependant, dans le monde réel, un test unitaire pourra être
associé à plusieurs exigences, une exigence pourra
n'être pas couverte... etc. In fine le développeur
arbitrera (mais avec un minimum d'expérience, cela se passe
bien. )
A chaque TU est associé un jeu de tests, mais aucune
hypothèse de données préalable ne peut être
faite. Que l'on parte d'une base totalement vidangée ou pleine
de donnée, le résultat du test unitaire doit être
le même. D'autre part, le séquence des TU ne doit pas
non plus conditionner le résultat.
Ressources
- L’intégration
requiert un serveur dédié pour hudson
- Il faut une base de données
par utilisateur
(Elle peux se situer sur la machine de
développement ou sur un serveur mutualisé)
Contrainte de conception
- Il faut utiliser maven pour
l'assemblage
- Les test unitaires doivent être
écrit avec Junit
Au quotidien
- Il faut vraiment s’impliquer
dans la supervision des builds et être vigilant tout au long
du développement du produit : codage, intégration,
validation
- L'équipe doit s'organiser
dans ce but, c'est-à-dire qu'il faut un responsable
Intégration Continue (le même que le responsable GCONF)
Mise en oeuvre
Installer un serveur hudson- Planifier les tâches à des horaires où la
machine n'est pas trop chargée
 |
| De The French Hack |
 |
| De The French Hack |
 |
| De The French Hack |
