Sommaire

De quoi allons nous parler ?

Concevoir, développer et distribuer des applications avec des technologies distribuées
- Infrastructure distribuée pour passer au stade de développement collaboratif
- Mutualiser les ressources et faire communiquer les membres d'une équipe
- Fédérer les développements, éviter les dispersions d'énergie et permettre l'évolution du produit
Adapté à notre communauté
- Utilisateurs/développeurs géographiquement distribués pour une expérience, e.g:
  1. ATLAS: 500 développeurs sur trois continents
  2. LHCb: 500 utilisateurs dans 50 instituts
Présentation des bonnes pratiques et outils
- Vue subjective et non exhaustive basée sur notre expérience
- Vision Open Source

Codage:
- Tests unitaires
  - JUnit, CUnit, ...
- Environnement de développement
  - Xcode, Visual, Eclipse, ...

Outil de contrôle de version:
- Cœur d'un système de développement collaboratif
  - E.g: CVS, SVN (voir présentation SVN), ...
Mais les besoins de partager et de communiquer dépassent largement le cadre du code source
Outils synchrones: chat, web conférences, etc.
Utiliser une plate-forme intégrée de gestion de développement:
- Savannah, GForge, Trac (voir présentation Trac), ...
Portabilité:
- Configurer et activer l'environnement de développement, de compilation et d'exécution
- E.g: autoconf, automake, libtool, Ant, CMT(voir présentation CMT)
Liaison entre packages (externes?)
- E.g: Maven, Waf, CMT(voir présentation CMT)
Gérer la documentation du code
- E.g: Doxygen

Validation progressive des versions:
- Alpha: pour les développeurs
- Bêta: pour les contributeurs
- Release Candidate: pour les sympathisants
- Final, corrections: pour tous les utilisateurs
Numérotation des versions doit être clairement formalisée pour:
- les changements apportés
- les procédures de mise à jour
- Plusieurs formes possibles
  - 1.05, 2.7.18, 1_5_0_06, 5.7-2, ...

Major number:
- Changement très important (protocole, architecture, ...)
- Incompatibilité assurée entre acteurs de versions différentes
Minor number:
- Changement important (ajout/retrait de fonctionnalités, ...)
- Incompatibilité possible (à déterminer clairement)
Patch level:
- Changement mineur (correction de bug, amélioration de l'interface, ...)
- Compatibilité assurée
Release number:
- Pas de changement fonctionnel
- Changement dans la documentation, les exemples, ...

Sous quelle forme ?
- tarball, RPM, ...
Pour quelle plate-forme ?
- Grande contrainte des grilles
- Cross-building
Prévoir des mises à jours automatiques et façiles
Outils pour le déploiement
- Intégrer un système de distribution
- CPAN, fink, Pacman, ...
Problème des versions concurrentes
- Indispensable dans un environnement grille

Beaucoup de sollicitations:
- Rapports d'anomalie (bug reports)
- Demandes de fonctionnalités (feature requests)
- Problèmes d'installation/configuration
- Questions diverses
Capitaliser:
- Structurer le support dans la documentation
  - FAQs, Documentation, Tutoriels, Wiki, ...
- Utiliser des listes de discussion archivées/Forum/Flux rss d'annonce/ ...
Utiliser une plate-forme intégrée de gestion de développement:
- Savannah, GForge, Trac (voir présentation Trac), ...

Pb: Documents binaires uniques
- PowerPoint, OpenOffice
  - Pro: universel, maitrisé, fichier unique ...
  - Cons: non versionnable, mal adapté à l'édition collaborative
Documents texte
- Versionnable, adapté à l'édition collaborative, Open Source
- LaTeX
  - Ex.: Beamer
  - Pro: fichier produit unique, multi formats, esthétique
  - Cons:
    réservé aux amateurs de LaTeX
- Xhtml+CSS+JavaScript
  - Ex.: Slidy, S5, Slideous, DomSlides, XSlidy
  - Cons:
    réservé aux amateurs de CSS/JavaScript,
    pas d'éditeur spécialisé pour l'instant, éditeur Ajax annoncé

Être rigoureux dans le développement
- Les environnements distribués apportent dès le départ des contraintes sur la conception/implémentation
Soigner davantage la documentation
Communiquer, former
Assumer le support
- Énorme consommation de temps

Questions ?