Charlycha

Quelques billets techniques et peut être un peu de moi, mais pas trop !

Aller au contenu | Aller au menu | Aller à la recherche

lundi 2 juillet 2007

Changement d'horizon

Changement de boite

Après une longue absence, justifiée :o : Oui, changement de boite ! me revoici enfin.

J'ai fini par quitter Axemble / VDoc Software pour rejoindre Alinto, en tant que Directeur Recherche et Développement. Cela fait maintenant 8 semaines, et, après une période de transition/formation, me voilà enfin opérationnel.

Alinto propose des solutions dans le domaine de la messagerie, possède sa propre plate forme de messagerie mutualisée, batie autour de logiciels libres et en apportant une valeur ajoutée. Elle propose des passerelles Mail 2 Fax, Fax 2 Mail, Mail 2 SMS ainsi que des briques collaboratives (Agenda, Contact, partage de fichiers...)

Ma mission, consistera à faire évoluer la solution d'Alinto, aujourd'hui développée en PHP, vers une solution Java, afin de proposer un packaging aujourd'hui manquant. Par la même occasion, nous allons en profiter pour redonner un coup de "jeune" à l'application en passant sur des techno Web 2.0 / Ajax.

l'Architecture

L'architecture que je met en place sera basée sur des briques Java/Jee tel que :

Coté serveurs :

  • Serveur d'application : JBoss / Tomcat
  • Serveur SGBD-R : MySql ou PostgreSQL
  • Serveur Ldap : Open LDAP

Coté Framework Java

Un framework récent mais vraiment différent de ceux que l'on peut rencontrer dans le monde JEE, pas de JSP, mais un MVC2 vraiment facile à apréhender

La couche d'IOC (Inversion of control). Elle permet de rendre les briques utilisées ou crées indépendantes les unes des autres, et ainsi de rendre l'architecture du soft modifiable à souhait

La couche ORM par excellence : simple et puissante, avec une transition vers EJB 3 toute trouvée !

Coté Projet et Build

Largement utilisée par l'Open Source, cette solution apporte une dimension nouvelle dans le monde de la gestion du projet, des sources, du test et du packaging

Le gestionnaire de source nouvelle génération

  • CI : Intégration continue :

J'avoue n'avoir pas encore tranché entre Contiuum et Continuous Integration. Les 2 solutions restant attrayante et compétitives...

jeudi 25 janvier 2007

Migration depuis Visual Source Safe vers SVN

J'ai récemment voulu migrer la base Microsoft Visual Source Safe de ma boite vers Subversion (SVN pour les intimes) afin de pouvoir gérer au mieux les branches de maintenances et de développements du logiciel de workflow dont je suis en charge : vdoc process .

Première tentative : Comme pour beaucoup de choses, je commence par une recherche Google.
Le premier programme que je teste est un script Perl : http://www.riseup.com/~brettw/dev/VSS2Subversion.html

Résultats peu probants : Je lance le script une première fois avec l'option "--dumpusers" afin de créer la base des utilisateurs, je configure le serveur SVN pour qu'il prenne en compte ces comptes avec un mot de passe vide puis je relance le script une deuxième fois. Déçu : Ce script ne fait qu'une copie de la dernière version de source safe et la pose dans SVN. Certes il importe les fichiers avec les bons comptes utilisateurs, mais tout est perdu : dates de modifications, historiques... bref difficilement défendable pour un outil de gestions de sources en entreprise ...

Après d'autres tentatives infructueuses, je tombe au hasard d'un post sur un forum, sur un gars qui fait sa pub pour son outil : Polarion. J'avais déjà entendu parler d'eux notamment pour le plugin qu'ils proposent avec Eclipse.

Deuxième tentative: Polarion propose en effet un outil nommé "SVN Importer". Ecrit en Java, il se rapproche déjà plus de mon domaine de compétences ;). Après avoir fait plusieurs petits essais, je me lance la veille d'un Week-End pour une migration complète.

Après 4 jours de travail sur un serveur Bi-Xéon 3ghz, la migration n'était toujours pas terminée. Dans les logs, je m'aperçoit que les appels à VSS.EXE (l'outil ligne de commandes de Source safe) prennent énormément de temps, et plus le nombre de document augmente, plus le temps augmente. Etrange...

Puisque cette solution correspondait déjà mieux en mes besoins de migration (Conservation de l'historique, des dates réelles, des intervenants réels) mais que les temps de traitements étaient trop long (dû à l'utilisation de Source Safe en ligne de commande, je décide alors de récupérer les sources (le projet est en Open Source). Je m'y colles un Week-end et je transforme cet outil pour qu'il utilise les API COM de Source Safe via JAWIN qui est une interface Java / Api Windows et COM.
Mes premiers essais sont vraiment concluant : je passe de 2 à 15 sec pour un document (selon sa taille et son historique) à 10ms à 500ms maximum ! et une migration complète avec l'import dans SVN ne prend environ que 11 heures !!!

J'ai bien évidemment proposé puis inclus mes modifications au projet SVN Importer de Polarion. Les modifications seront disponible certainement à partir de la Release SVNImporter 1.1-M9. En attendant, elle peuvent être récupérés directement depuis leur repository SVN.