Inscription au Déjeuner sur web n°2 et Je-ne-sais-quoi

Voilà voilà, je me suis inscrit à la deuxième édition de Déjeuner sur web, à Toulouse, sur le site de la Mêlée Numérique.

C'est l'occasion d'une « magnifique » annonce Twitter :


Oui, j'utilise Twitter entre autres comme révélateur de TODO List : les choses que j'ai à faire n'apparaissent que quand elles sont faites. Comme ça, pas de stress. Et cela comble le Knowing-Doing Gap.

... J'ai comme l'impression que bloguer sur le Knowing-Doing Gap à partir d'un événement aussi anodin qu'une inscription à quelque chose qui n'a pas eu lieu, peut donner la même impression d'inutile mise en abyme que Twitter soi-même. Pourtant pourtant quelque chose se joue...

Déjeuner d'ex-Fûteurs et retour sur les Fûts

J'ai déjeuné ce midi avec les deux autres instigateurs du projet original « Les Fûts », c'est-à-dire Christophe et Pierre (ils sont dans la colonne à droite).

Repas très sympa à Gradignan ; on mange toujours aussi bien au Thé à la menthe.

On est revenus un peu sur le projet des Fûts (entre moults autres sujets). Pour ma part ce que j'en retiendrai :

• l'idée d'une plate-forme web avec fédération d'identité pour les associations reste « une idée qu'elle est bonne »
• pour des sites mon-associatifs, des solutions existaient à l'époque, et de nouvelles existent aujourd'hui, ou ont évolué. On a parlé par exemple de Joomla!, de Guppy...
  
• la disponibilité de l'équipe n'était pas là, ou mauvaise : on ne se voyait que quelques fois par semaine, par exemple. Or pour un tel projet, qui demandait un fort investissement technique, il faut s'y mettre à fond, et surtout sur de grosses plages de temps.
  
• à mon avis, le modèle économique basé sur un modèle associatif n'était pas bon. C'est une autre façon de voir le point précédent.
  
• on s'est dispersés à tort sur deux objectifs : des réunions d'architectes NTIC bordelais, et une plate-forme web pour les associations, les architectes développant (imaginait-on) la plate-forme.
• et évidemment, on a été trop ambitieux sur les délais affichés...

Gros problème de focus, je dirais.

Mais l'idée reste bonne ;-)

Validation de backups

OK, on fait tous des sauvegardes, ou backups, automatisés.

Un des risques est qu'un grain de sable s'immisce dans le processus de backup, et que le fichier de sauvegarde soit au final invalide, c'est-à-dire qu'il ne puisse plus servir à la restauration des données. Pas très pertinent, du coup.

Pour gérer ce risque, on peut disposer d'une machine jumelle, sur laquelle on va régulièrement procéder à une restauration de l'environnement qui a été sauvegardé. Mais il s'agit là de tâches « bas niveau », comme dirait un administrateur système de mes connaissances, et elles ne valident que le processus de restauration, non pas que les données ont été réinstallées avec succès.

Pour illustrer ce risque, imaginons que telle procédure de backup consiste à créer l'archive d'un répertoire. Et que pour un bête problème de configuration qui change, se retrouve archivé un mauvais répertoire ou un répertoire vide. Toutes les opérations techniques de sauvegarde, copie, transfert, et restauration, se passeront bien, mais les données issues de la restauration n'auront aucun intérêt. Et on ne s'en apercevra qu'en cas de besoin... (Ne rigolez pas, ça m'est arrivé).

J'ai donc pensé à automatiser une validation « applicative » de la restauration quotidiennne de mes données sauvegardées.

Prenons l'exemple d'un repository Subversion, qui est le cas le plus critique pour le développement. À intervalles réguliers, j'ai un processus qui :

1. récupère sur une machine dédiée la dernière version du backup du repository
2. extrait les fichiers
3. les installe en tant que repository temporaire, et démarre une instance svnserve (serveur Subversion)
4. simule un client (un poste de travail de développeur), et se connecte au serveur démarré pour rapatrier tous les fichiers
5. fait quelques mesures et validations sur les fichiers ainsi rapatriés : le nombre de projets est supérieur à 10, etc.
   

Au fil du temps, je vérifie que les restaurations de backups vérifient certains critères, comme :

• le numéro de révision Subversion ne cesse de croître avec le temps (non-réversibilité)
• le nombre de projets ne cesse de croître avec le temps (loi d'entropie du développement Java)
  
• la taille de l'archive croît grosso modo avec le temps (avec une tolérance de -2 %, car cela dépend de la compression)

Je pourrais aussi vérifier que :

• le numéro de révision Subversion rapatriée correspond à peu près (à 100 près, par exemple) à la révision Subversion qui est active sur la machine de production
  

J'ai une console qui me permet de suivre ces évolutions.

L'architecture technique que j'utilise est la suivante :

• Le serveur « ref » contient les données de référence, en l'occurrence le repository Subversion utilisé en développement
• [1]. À minuit (0:00), une hot copy est créée localement, compressée, et envoyée par FTP vers le serveur « ftp », qui est une sorte de sas.
  
• [2]. À 1:00, l'archive est récupérée et copiée localement sur « bkp », qui collecte une copie de tous les fichiers de sauvegarde de l'architecture.
• [3]. À 2:00, l'archive est récupérée et copiée localement sur « ci », qui est vu comme un serveur d'intégration continue (Continuous Integration).
• Les fichiers de l'archive sont extraits, installés en tant que repository local, svnserve est démarré, des tests sont passés, etc.
• Un rapport est émis, qui pourra être agrégé aux autres et servi par un Web Service.
  

Une console agrège ensuite les différentes informations. Voici un exemple de tableau de bord :

• La console présente les noms des derniers fichiers de sauvegarde, leur date, leur « âge » en jours, leur taille, et indique s'ils ont fait l'objet d'une restauration ou non.
• La mention « restored » indique que la restauration du fichier a réussi.
• La mention « NO » indique que la restauration n'a pas eu lieu (il y a quelques progrès à faire, visiblement)
• Les mentions « -1 », « -2 », etc. indiquent que le dernier fichier de sauvegarde n'a pas encore fait l'objet de restauration, et que la dernière restauration pour ces données a eu lieu sur l'avant-dernière sauvegarde, l'antépénultième, etc.
  

L'intérêt de la machine sas « ftp » est de pouvoir interdire les accès directs de « ref » vers « bkp », dans le cas de réseaux différents par exemple. Dans le cas où tout ce beau monde est sur le même réseau, on peut s'en passer.

La machine « bkp » a bien comme responsabilité de centraliser tous les backups de l'architecture. On pourrait avoir par exemple :

Une remarque :

• il est intéressant d'imposer que les données de référence soient systématiquement versionnées en amont (exemples : Subversion, un wiki, etc.). Une réflexion à mener pour les données métier si vous voulez mon avis...
  

Bon, je suis bien content. Ça fait longtemps que je souhaitais implémenter ce système.

Et vous ? Quelle garantie vous offrez-vous sur la pertinence de vos backups ? Vous contentez-vous de faire confiance à vos logiciels utilitaires ?

Cela vous paraît un peu compliqué ?... ;-)

Assertions JUnit 4.4 : assertThat()

Merci aux blogueurs de Xebia France de me faire découvrir la méthode assertThat() de JUnit 4.4, sur laquelle je ne m'étais pas encore penché : Simplifier les assertions JUnit et améliorer vos tests.

Avoir des tests les plus clairs possible est une Bonne Chose™.