La fabrique logicielle Serialcoder

 

Je vais discuter ici de la mise à jour d’un de nos logiciels et de la façon dont nous procedons pour que l’utilsateur final puisse en beneficier en toute quiettude.

La contrainte au depart est qu’un client peut avoir ses propres composants, chaque client n’a pas obligatoirement la meme version qu’un autre, un client peut utiliser un serveur mutualisé, ou son propre serveur en local, voir utiliser une machine soho. Nous utilisons une architecture N-Tiers, sans trop entrer dans le détail, le logiciel est composé des elements suivants qu’il faut deployer de manière synchronisée :

  • La base de données
  • La ou les interfaces utilisateurs
  • Les services
  • Les webservices
  • Les sites web

La base de données

La problèmatique pour nous est de garantir que chacun de nos clients utilise le bon schema (Table/Vue/Procedures stockées) , Il n’etait pas question pour nous de passer les scripts à la main, alors pour etre certain que le schema sera bien mis à jour nous avons developpé un outil qui nous avons nommé “Sql Schema Script Synchronizer”, il s’agit d’un dispositif qui historise tous les scripts de modification du schema SQL, script par script en donnant pour chacun un numéro de version incrémentiel, lors d’une mise a jour il ne nous reste plus qu’à recreer entre une version et une autre une liste de script à passer sur la base de destination pour obtenir la version du schema voulue, ci dessous le workflow que nous utilisons :

Nous mettrons bientot cet outil gratuitement avec son code source a disposition de ceux qui sont interessés par cette problèmatique , le projet sera hebergé sur Google code à l’adresse suivante http://code.google.com/p/s-cube/

 

La ou les interfaces utilisateurs (Client riche)

Concernant le deploiement de cette partie, Microsoft à mis au point la technologie Clickonce, elle permet une fois le logiciel installé sur le poste du client final, de lui indiquer nativement qu’une mise à jour est disponible et qu’il procede a son téléchargement. Cette technologie est très pratique et permet proprement de gerer un grand parc de machine en obligeant le téléchargement sur une version précise (contrairement à un MSI). Le seul bemol est qu’elle ne permet pas nativement le deploiement selectif, dans notre cas certain de nos clients utilisent des composants spécifiques, nous avons du ecrire un outil de publication clickonce qui permet de réaliser cette opération. De plus nous avons décidé que chaque client devait posseder sa propre url personnalisée de téléchargement du client riche.

Les services

La mise a jour des assemblies d’un service NT n’est pas une chose aisée de manière automatisée, autant il existe Clickonce pour les clients riches autant il n’existe rien pour les services NT si ce n’est Stopper celui-ci et installer les assemblies à la main. Cette manipulation est envisageable dans le cas d’un nombre restreint de serveurs et il faut avoir le droit d’y acceder ce qui n’est pas toujours le cas. Pour la mise en place d’un update automatisé des services, nous avons ecrit un premier service NT lui meme dont le role est de mettre a jour d’autre service, nous l’appelons le Service Updater il s’auto update via chargement / déchargement d’assemblies dans un appdomain, son principe est très simple, il check à interval régulier si une mise à jour est disponible sur le repository central, si c’est le cas il commence le téléchargement des assemblies disponibles dans un cache local, puis stoppe les services NT concernés, copie les nouvelles assemblies et redemarre les services.

Les webservices , Les sites web

La copie a chaud est prevu en revanche pour les sites web, au préalable le service updater ayant téléchargé les pages et autres assemblies copie celles-ci directement dans les sites (le plus vite possible) avant cette opération une page de maintenance est activée, a la fin de la copie le site revient dans son mode initial.

Voici le schema global de deploiement :

Deploy

La software factory utilisée basé sur les elements clés suivant :

  • Repository Subversion
  • Cruise Control
  • Sql Schema Script Synchronizer
  • Clickonce
  • Un Service Updater

Les developpeurs envoient leur code source vers un repository Subversion , celui-ci est analysé et buildé sur un serveur d’intégration en utilisant Cruise Control, cela nous permet de proceder aux builds, et de lancer les tests unitaires pour savoir si le code commité est viable.

Dès que nous considerons que le code est stable et que les fonctionnalités définies dans notre roadmap sont bien implémentées et conformes, le chef de produit decide de publier une nouvelle version pour un client spécifique ou tous les clients.

En fonction des clients , des assemblies custom peuvent alors etre buildée en supplément.

Un service de publication prépare les fichiers sur un serveur repository et indique à un web service qu’une nouvelle version est disponible.

Le service Updateur detecte alors le changement et commence le téléchargement des fichiers disponibles et les places dans un cache. S’il detecte qu’il y a un changement de schema de la base de données, alors il place celle ci en maintenance et demande ainsi à tout les clients connectés de bien vouloir se deconnecter avant un labs de temps défini, a l’issue le service updateur coupe tous les services NT concernés, fait un backup de la base et installe ensuite le ou les nouveaux scripts sql jusqu’a atteindre la version voulue par le chef de produit. Il copie alors les nouvelles assemblies pour les services NT et pour les sites web (Extranet, WebService, Ect..).

Quand cette opération est terminée le service updateur indique au repository central qu’il a terminé toutes ses opérations, le repository change la version Clickonce et les clients utilisateurs finaux peuvent sont notifiés que la nouvelle version de leur interface est disponible.

L’utilisateur final est alors completement mis a jour et peut nous demander de nouvelles fonctionnalités ;).

Cette architecture de deploiement nous permet une veritable integration continue, a l’heure actuelle nous publions une à deux versions par mois, si un bug severe se presente nous somme en mesure de le corriger et de deployer une nouvelle version dans les 24 heures qui suivent.

Aucun commentaire: