Pages

Friday, February 10, 2012

CassandraUnit : un outil Dev & Ops!

CassandraUnit est un framework permettant de vous aider à développer des applications Java basé utilisant Cassandra.

Depuis la version 1.0.1.4, C'est maintenant un outil à la fois Dev & Ops, car il peut vous accompagner dans toutes les phases de votre projet :

Un outil @Dev:
CassandraUnit est initialement né de la volonté de vouloir faire du TDD en testant aussi la persistance dans Cassandra. Le but était de répondre à 2 problématiques : 
  • Comment développer un service de lecture de données dans Cassandra en faisant du TDD sans avoir de cluster Cassandra?
  • Comment faire en sorte que mes tests unitaires soient portables et isolés pour pouvoir faire de l'intégration continue?
L'idée directrice était de proposer un environnement au niveau des tests unitaires qui permettent avant leur exécution :
  • de démarrer une instance embarquée de Cassandra.
  • de remplir cette instance avec un keyspace et des données.
Comment ça marche ?

Il faut dans un premier temps définir votre dataSet, C'est le jeu de données qui sera inséré dans Cassandra pour votre test unitaire.

CassandraUnit vous permet selon votre préférence de définir un dataSet au format XML, JSON ou Yaml ( plus d'infos ici)

Il faut ensuite l'intégrer au niveau de votre test ou de votre code. Il est possible de faire ça de plusieurs manières :
  • soit de manière native en manipulant l'APIs (donc pas forcément dans un test) : 
EmbeddedCassandraServerHelper.startEmbeddedCassandra();
DataLoader dataLoader = new DataLoader("TestCluster", "localhost:9171");
dataLoader.load(new ClassPathJsonDataSet("simpleDataSet.json"));
  • soit par héritage au niveau de votre classe de Test :
public class yourTest extends AbstractCassandraUnit4TestCase {

    @Override
    public DataSet getDataSet() {
        return new ClassPathJsonDataSet("simpleDataSet.json");
    }

    @Test
    public void shouldHaveLoadASimpleDataSet() throws Exception {
        assertThat(getKeyspace(), notNullValue());
        /* and query all what you want */
    }

}
  • soit sans héritage! merci Junit @Rule
public class SecondaryIndexWithRuleTest {

    @Rule
    public CassandraUnit cassandraUnit = new CassandraUnit(new ClassPathJsonDataSet("simpleDataSet.json"));

    @Test
    public void shouldHaveLoadASimpleDataSet() throws Exception {
        assertThat(getKeyspace(), notNullValue());
        /* and query all what you want */
    }

}

Un outil @Ops
Depuis la version 1.0.1.4, CassandraUnit propose un outil en ligne de commande multi OS : le "cu-loader".
Cet outil en ligne de commande permet de réutiliser vos dataSets pour créer vos keyspaces et/ou charger vos données dans d'autres cluster Cassandra que votre instance de Cassandra embarquée en @Dev.

L'outil permet de réutiliser les dataSets sans les modifier mais avec la possibilité de surcharger certaines déclaration liées à la configuration du cluster Cassandra (comme le replication factor, la stratégie, ...).

L'objectif de l'outil est d'éviter d'introduire des erreurs liées au changement d'environnement en créant un keyspace qui ne correspondrait au keyspace utilisé en développement.

CassandraUnit est diponible sous forme de distribution téléchargeable depuis github ici ainsi que sur le repo central maven. Il suffit donc de le décompresser et de rajouter

Voici ce que ça donne à l'utilisation :

> cu-loader
Missing required options: f, h, p
usage: CassandraUnitLoader is a tool to load CassandraUnit data Set into cassandra cluster
 -f,--file <arg>                dataset to load
 -h,--host <arg>                target host (required)
 -o,--onlySchema                only load schema (optional)
 -p,--port <arg>                target port (required)
 -r,--replicationFactor <arg>   override the replication factor set in the dataset (optional)
 -s,--strategy <arg>            override the strategy set in the dataset (optional)
Un exemple simple :
> cu-loader -f datasetDefaultValue.xml -h localhost -p 9160
Un exemple complet :
> cu-loader -f datasetDefaultValue.xml -h 10.10.10.01 -p 9160 -o -r 3 -s org.apache.cassandra.locator.NetworkTopologyStrategy
Vous trouverez plus de détails dans le doc ici

Voici des liens qui pourront vous être utile si vous voulez aller plus loin :
- github : https://github.com/jsevellec/cassandra-unit/
- mailing list : https://groups.google.com/group/cassandra-unit-users?hl=fr
- twitter : https://twitter.com/cassandraunit

Bref. Un bel outil. :-)



Friday, January 27, 2012

Brancher Nexus sur Active Directory (LDAP)

Après avoir perdu un peu de temps à configurer Nexus sur Active Directory par l'intermédiaire du protocole LDAP, Je vous propose de vous faire partager mon expérience sur le sujet et en français

Mon besoin était le suivant :
  • Mettre en place un Nexus.
  • Mettre en place un système d'authentification pour l'administration du Nexus.
  • Réutiliser le  référentiel d'utilisateur de l'entreprise.
  • Ne pas ouvrir l'administration de Nexus à tous les utilisateurs présents dans l'AD mais seulement à un groupe.
Une documentation très bien faite est mise à disposition par Sonatype Ici.

Le problème n'est pas dans la qualité de la documentation mais se brancher sur un AD par l'intermédiaire de LDAP n'est jamais simple : beaucoup d'options, de paramétrages, des contenu dans les référentiels LDAP très différents.

Etape 1 : Obtenir un accès
Avant de commencer, il faut obtenir un utilisateur/mot de passe qui soit capable de naviguer en lecture au sein de l'AD. En général, il faut créer ou faire créer un utilisateur générique par lequel vos applicatifs (comme Nexus) viendront interroger votre AD.

Une fois cet utilisateur en poche (ça peut prendre du temps à avoir ce genre de choses...) , je vous conseille de le tester avec un browser LDAP. Je me suis servi d'Apache Directory Studio. Il est Open Source et c'est une application RCP. Bref, il fait plutôt bien le job.

Il vous suffit donc de créer une connexion (host et port de l'AD, user, password) et hop vous pouvez naviguer à l'intérieur.

Il faut aussi créer un groupe AD et y rattacher les utilisateurs à qui vous souhaitez donner l'accès à l'administration de Nexus. Votre AD possède peut être déjà un groupe qui correspond à la population qui vous intéresse. Vous pouvez dans ce cas le réutiliser. Pour la suite de l'article, nous appellerons ce groupe "equipe-de-developpement".

Mais ça n'est pas fini...

Etape 2 : Obtenir une bonne vision de l'arborescence de l'AD

Le plus important et de récupérer l'adresse LDAP racine dans laquelle tous les utilisateurs se trouvent. Nous l’appellerons pour la suite de l'article "l'adresse racine utilisateur".
par exemple : CN=Users,DC=votreDomaine,DC=com

Mais ça n'est pas fini...

Etape 3 : configurer la partie LDAP de Nexus
Connectez-vous en admin sur Nexus et déplacez-vous dans la partie Security > "LDAP Configuration" accessible depuis le menu latéral gauche. C'est parti pour la partie conf : 
  • Connection : (permet de définir les paramètres de connexion à l'AD)
    • Protocol : Ldap
    • Hostname : adresse de l'AD (le même que vous avez utilisé avec botre browser LDAP).
    • Port : port de l'AD (en général c'est 389).
    • Search Base : c'est l'adresse par défaut à partir de laquelle le requêtage LDAP se fera une fois connecté. Remplissez le avec l'adresse racine utilisateur.
  • Authentication : (permet de définir la manière dont Nexus s'authentifie sur l'AD)
    • Authentication method : Choisir "Simple Authentication"
    • SASL Realm  : laisser vide.
    • Username : le username de votre utilisateur générique ayant accès en lecture à AD.
    • Password : le password de votre utilisateur générique ayant accès en lecture à AD.
Vous pouvez faire un "check authentication". Si tout est ok vous devez avoir un "LDAP connection and authentication test completed successfully." Ça veut dire que votre Nexus sait se connecter à votre AD.
  • User Element mapping : (permet de définir la manière dont Nexus va vérifier si un user existe)
    • Base DN : laisser vide (si vous avez bien renseigné dans la partie connection que l'adresse par défaut de requêtage est bien l'adresse racine utilisateur).
    • User Subtree : à cocher.
    • Object Class : Saisir "Person", c'est le type d'objet LDAP contenant les utilisateurs.
    • User ID Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient les logins utilisateurs AD. Saisir : "sAMAccountName"
    • Real Name Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient le nom complet des utilisateurs AD. Saisir : "displayName".
    • E-Mail Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient l'adresse mail des utilisateurs AD. Saisir : "mail".
    • Password Attribute : Il faut indiquer le nom de l'attribut qui contient le mot de passe des utilisateurs AD. Laisser vide (c'est un attribut par défaut).
  • Group Element Mapping : (permet de définir la manière donc Nexus va récupérer la liste des groupes).
    • Group Type : Saisir "Dynamic Groups". Il y a 2 types de groupes LDAP : un groupe dynamique correspondant à un attribut dans un objet "user" LDAP. Un groupe statique, c'est le contraire, c'est la référence à une liste d'utilisateurs dans un objet LDAP "group". Avec AD, à priori, quand un groupe est créé il l'est en statique et dynamique. Autant donc choisir dynamique car il y a beaucoup moins de configuration ;-).
    • Member Of Attribute : Il faut indiquer le nom de l'attribut LDAP dans lequel un groupe dynamique est défini. Saisir : "memberOf".
Vous pouvez faire un "Check User Mapping". Si tout est ok, Nexus vous affiche un début de liste d'utilisateurs qu'il a réussi à requêter. 

N'oubliez pas de faire "save" :-)

Mais ça n'est pas fini...

Etape 5 : Mapper votre groupe AD avec un rôle NEXUS.

Il faut maintenant configurer à Nexus pour que les utilisateurs de votre groupe AD equipe-de-developpement correspondent à un rôle dans Nexus, par exemple "Administrateur Nexus".

Déplacez-vous dans la partie "Roles" accessible depuis le menu latéral gauche :
  • Sélectionner "Add" > "External Role Mapping"
  • Realm : choisir "LDAP"
  • Role : La liste des rôle LDAP de votre AD doit être présente. choisir votre groupe equipe-de-developpement
  • Ajouter ensuite le Rôle associé en cliquant sur "add"
  • Cocher le "Nexus Administrator Role"
  • Cliquer sur OK
Mais ça n'est pas fini...

Etape 6 : activer l'authentification LDAP pour Nexus
Il faut maintenant simplement activer l'authentification par LDAP. Je dis "simplement", mais j'ai cherché un bout de temps avant de comprendre pour tout ça ne marchait pas ;-).


Déplacez-vous dans la partie "Administration" > "Server" accessible depuis le menu latéral gauche :

  • Dans la partie "Security Settings": déplacer "OSS LDAP Authentication Realm" de "Available Realms" vers "Selected Realms".
That's all...










Friday, January 13, 2012

Agilité par contamination


Lorsqu'on souhaite mettre en oeuvre Scrum la première fois, il est souvent dit de mettre en place la totalité du framework et dans un second temps de l'adapter quand l'ensemble des acteurs possèdent le recul nécessaire (pour justement l'adapter favorablement). Cette mise en place totale a pour but de ne pas tomber dans les fameux "Scrum But", souvent cause de l'échec de la mise en place de Scrum. Les "Scrum But" pour simplifier représentent les entorses au framework (Exemple : c'est le ScrumMaster qui fait les estimations et affectent les tâches, oui ça c'est de la très grosse entorse ;-)).

Je vous propose ici de vous raconter un de mes retours d'expérience sur le sujet qui est très différent de l'approche dont je viens de vous parler.

Il y a bientôt un an, j'ai intégré une équipe de développement chez un éditeur logiciel qui ne pratiquait pas "l'agilité". Ce nouvel environnement me paraissait idéal pour mettre en place Scrum couplé avec un peu d’Extrême Programming pour plusieurs raisons :
  • une petite structure (moins de 25 personnes).
  • une équipe de développement de moins de 6 personnes.
  • une forte croissance.
  • la volonté de développer une nouvelle version d'un produit.

Il faut avouer que Scrum est très déroutant dans ces pratiques quand on ne les a jamais mises en oeuvre. Comme je ne m'appelle pas Jeff Sutherland (un des papas de Scrum) et que je ne suis pas un extrémiste (enfin j'estime ne pas l'être, ce qui est différent, je vous l'accorde), je n'ai pas forcé pour la mise en place de Scrum.

En revanche, je travaillais sur un sujet isolé et avec une liberté totale sur ma façon de travailler. J'ai donc fait du Scrum et de l'Xp seul (ok ce n'est pas vraiment du Scrum). Tiens ça me fait penser à Jean Jacques.

Hey hop, c'est parti, je récupère un tableau en carton, j'ai un mur juste derrière moi, impeccable,  ça sera mon scrum board. Un petit tour par la compta : "Heu, vous auriez des post-its? Ha, vous n'avez que cette couleur, ok ça ira très bien pour commencer. Vous pouvez en commander d'autres? et de plusieurs couleurs?".


Un ou deux jours passent...

Réaction 1 : "Ha c'est comme ça que tu travailles?"
Réaction 2 : "C'est jolie tous ces post-its derrière toi, c'est quoi, ça marche comment?"


Côté pratique d'ingénierie, pas d'intégration continue, pas de DVCS (en tous cas pas celui que je voulais :-)), pas de suivi de qualité, pas de déploiement continu. Ok, qu'à cela ne tienne, "Just Do It". C'est parti pour mettre en place une forge logicielle complète sur une machine virtuelle dans un coin de serveur (apache, jenkins, git, sonar, maven, ...).

Réaction 3 : "C'est quoi l'intégration continue?"

J'avais maintenant tous les outils que je souhaitais pour développer. C'est parti. Les semaines passent, les post-its s'entassent...

Réaction 4 : "C'est pas mal ton tableau avec les post-its pour voir l'avancement du travail"

A force de question et de discussion autour de Scrum avec l'équipe de développement, je me propose de leur faire une présentation de Scrum. C'est parti pour une présentation de 2h très conviviale. L'objectif est de faire découvrir les principes du framework. Rien de plus.

Réaction 5 : "C'est vraiment très différents, ça n'est pas du tout aujourd'hui notre façon de travailler, ça fait un peu peur"

Les semaines passent... et qu'est-ce que je vois sur le bureau du collègue à côté de moi, le livre "Scrum" de Claude Aubry. Je lui dis que c'est un super bouquin qu'il a bien fait de l'acheter.

Réaction 6 : "C'est ma compagne qui me l'a acheté car je lui avais parlé de la présentation que tu avais faite"

Alors là je suis scotché!

Les semaines passent... et un gros sujet à traiter par toute l'équipe nous tombe dessus. On ne sait pas par quel bout le prendre. Je propose aux membres de l'équipe qui connait le mieux le sujet de faire un mind map pour modéliser le travail à effectuer ainsi qu'une réunion tous ensemble où l'on ajuste le Mind Map pour tous obtenir une bonne vision de ce qu'on va devoir faire.  J'extrais ensuite le contenu du Mind Map dans un fichier Excel.

Réaction 7 : "C'est un peu comme un Backlog ce fichier Excel, non?"

Je l'ai ensuite renommé en "Backlog".

Réaction 8 : "Par quoi on commence?"

Je propose de refaire une réunion avec toute l'équipe pour qu'on priorise les sujets/tâches tous ensemble pour traiter les tâches les plus urgentes.

Réaction 9 : "On priorise tout, tout de suite?"

Je propose alors de faire un point tous ensemble toutes les semaines et de prioriser/reprioriser les sujets.

Réaction 10 : "On migre les applis existantes sur git"?

Yes!

Réaction 11 : "Comment on fait pour rajouter un Job dans Jenkins"?

Yes! Je te montre!

Les semaines passent... et je discute avec le directeur général. Il m'apprend qu'il s'est documenté sur Scrum et les méthodes Agiles qu'il trouve ça très intéressant et qu'il souhaite qu'on fasse des petites réunions tous les matins.

Aujourd'hui, nous ne pouvons pas dire que nous "faisons du Scrum" mais tous ce qui est mis en place nous aident réellement au quotidien. L'utilisation d'un backlog et la réalisation du Daily Scrum du matin sont maintenant une évidence. J'espère que cette démarche (non préméditée) de contamination va se poursuivre.

Alors que je pensais que Scrum ne pouvait fonctionner sur le principe du tout ou rien, je me rends compte que l'agilité progressive est un succès dans notre cas.

Vous en pensez quoi?

Tuesday, December 13, 2011

Cassandra pour les développeurs Java

Hier soir, au Ch'ti JUG il y a eu une double session sur NoSQL.

Steven Noels a présenté en première partie Lily,  une solution d'indexation basé sur HBase.
En deuxième partie, j'ai effectué une présentation de "Cassandra pour les développeurs Java" où j'y ai abordé les principaux concepts de Cassandra, présenté Hector et cassandra-unitl e tout avec un peu de live coding.

Voici les slides de cette présentation :


Ça a été une bien belle soirée et un after bien sympa et convivial :



@bientôt à une autre session du Ch'ti Jug!


Tuesday, October 4, 2011

Cassandra : Les problématiques à traiter lorsqu'on développe une application java

Cassandra fait parti de la famille des bases de données NoSQL. C'est une base de données dont on entend de plus en plus parler dès que l'on est confronté à devoir gérer de gros volumes de données, à être très performant et à vouloir monter en charge facilement.

De part sa conception, Cassandra a été nativement pensé pour être hautement distribué, hautement performant et avec une forte capacité de montée en charge. 

Cassandra est une très belle implémentation du modèle p2p. Tous les noeuds au sein d'un Cluster Cassandra ont le même rôle. Il n'y a pas de notion de maître/esclave...

Bref, Je ne vais pas vous énumérer les avantages à utiliser Cassandra car d'autres l'ont déjà très bien fait avant moi. Vous trouverez sur le wiki de Cassandra un ensemble de liens vers des présentation qui  décriront les concepts clés autour de Cassandra. Juste un dernier mot pour vous dire que Cassandra va bientôt sortir en v1.0.

Une fois votre choix arrêté : "ok, on part sur Cassandra", quelles sont les problématiques auxquels vous allez être confronté lors de sa mise en oeuvre? Je vais tenter d'apporter quelques réponses... C'est parti!

Design de votre modèle de données :
Une des premières choses à faire quand on commence à travailler avec Cassandra, c'est d'oublier tout ce qu'on vous a dit et ce que vous faisiez avec une base de données relationnelle : Le maître mot est dénormalisation.

Cassandra propose un modèle orienté "Column Family" inspiré par BigTable de Google. Je vous conseille dans un premier temps de bien comprendre le modèle de Cassandra (Keyspace, ColumnFamily, Column, SuperColum, Counter) avant de vous lancer. La documentation de DataStax sur le sujet ainsi que l'article sur le wiki sont un bon point départ.

Une fois le modèle de Cassandra compris, il faut axer la réflexion sur la façon dont vous allez requêter vos données. Le système de requêtage de Cassandra est limité (pas de jointures par exemple...). Il faut donc commencer par là pour être sûr de pouvoir faire ce que l'on veut faire.

Installer et paramétrer un cluster Cassandra
La force de Cassandra est de fonctionner avec un grand nombre de noeud dans un cluster. Le plus gros cluster dont j'ai entendu parler (dans cette interview de Jonathan Ellis) serait constitué de 400 noeuds... Juste énorme. Sans aller jusque là, il faut malgré tout rapidement vous familiariser avec le fonctionnement et l'administration d'un cluster Cassandra. Bref, il faut mettre les mains dedans. Je vous conseille cet articlecette video ou encore cette documentation DataStax décrivant la mise en oeuvre rapide d'un cluster cassandra. Cassandra fonctionne aussi en Single Node, cela peut toujours servir en terme de développement mais j'y reviendrai plus tard.

Il vous faut aussi comprendre le fichier de configuration principal de chaque noeud Cassandra : cassandra.yaml. Voici sa documentation.

Si vos serveurs acceptent le packaging Debian, Je vous conseille fortement d'utiliser celui proposé par Cassandra. Il vous permettra très rapidement de l'installer et surtout de le mettre à jour facilement!

Il faut aussi un peu de moyens... Pour pouvoir faire des tests sur votre cluster, il faut un environnement machines permettant de mettre en valeurs les capacités de Cassandra. Cela permet aussi pour vous rassurer avec des tests de performances valables avant d'arriver dans un environnement de production. La virtualisation de plusieurs noeuds sur un ("petit") serveur ne permettra pas de faire des tests de performances concluants.

Administrer et monitorer un cluster Cassandra
Cassandra fournit nativement un ensemble d'outils permettant d'administrer votre cluster :
  • cassandra-cli : c'est l'utilitaire en ligne de commande permettant de lire/ecrire dans votre cluster
  • nodetool : c'est l'utilisaire en ligne de commande permettant de monitorer et administrer les noeuds du cluster
En plus de ça, DataStax propose une application Web de monitoring et d'administration de votre cluster Cassandra : OpsCenter. C'est vraiment un superbe outil. Il y a une version gratuite pour le développement. J'ai cru comprendre (mais je me trompe peut être) qu'il y aura bientôt aussi une version production gratuite mais qui ne l'est pas pour le moment.


Gérer le "Eventuellement Consistant"
Cassandra propose un modèle "Eventuellement Consistant". Ces mots doivent normalement mettre la puce à l'oreille à n'importe quel développeur et faire un peu peur. 

Pour faire simple, selon le théorème CAP, il n'est pas possible d'avoir à la fois de la consistance (Consistency) , de la disponibilité (Availability) et une résistance au morcellement (Partition tolerance). Il n'est possible que d'en avoir 2 sur 3. Cassandra a choisi de mettre l'accent sur le "A" et le "P" et d'offrir la possibilité de choisir son niveau de consistance. Il est donc possible d'avoir un consistance forte avec Cassandra mais au détriment d'une dégradation du temps de latence (car il faut demander à plus de noeud dans le cluster de se mettre d'accord sur la valeur d'une donnée lors d'une lecture par exemple).

Il y est donc possible de choisir parmi plusieurs niveaux de consistances. Voici une documentation sur le site de DataStax sur le sujet pour vous guider dans votre choix.

Lock
Cassandra ne sait pas faire de Lock. C'est un inconvénient lié à son architecture. Il ne permet donc pas d’empêcher plusieurs clients de lire ou d'écrire un ensemble données portant sur les mêmes clés de votre modèle au même moment. Ce qui peut être fortement gênant, il ne faut pas le nier... Dans ce cas : "la réponse est ailleurs".

Il n'est pas impossible de faire du lock sur vos données mais en utilisant un système externe qui va gérer cela. Zookeeper va vous permettre de faire cela. C'est un système de synchronisation distribué de type sémaphore qui va vous permettre de faire des locks. Zookeeper n’entraîne pas de SPOF car il fonctionne aussi en cluster. Cage est une libraire Java qui s'appuie sur zookeeper et propose un système de lock basé sur des chemins. Voici un article qui vous explique en détail son utilité pour compléter l'utilisation de Cassandra. 

Transaction
Ok, vous faites du lock mais lock ne veut pas dire transaction... Cassandra assure une atomicité des données au niveau d'une même clé (même dans des columnFamily différentes). En revanche, comment faire si vous avez besoin d'une atomicité de données sur plusieurs clés car vos données sont fortement couplés et que vous ne pouvez pas faire autrement.

La réponse est "Just do it (yourself)". Une des approches est de mettre en oeuvre un système de transaction log dans une columnFamily dédiée. Le principe est donc : 
  • de logger la transation en sérialisant les données qui ont besoin d'être atomiques (json, xml, ...) et en insérant le résultats de la sérialisation en une fois dans une colonne d'une columFamily.
  • effectuer votre traitement en insérant vos données dans votre modèle.
  • de marquer ou supprimer la log de la transaction une fois le traitement terminé.
Ce système vous donne alors la possibilité de rejouer la log de la transaction si un souci est survenu pendant votre traitement. Ce système est abordé dans cette présentation (à partir du slide 24).


Comment dialoguer avec Cassandra
Cassandra expose toute son Api cliente via Thrift. L'utilisation native de thrift est déconseillée car c'est plutôt une Api de bas niveau s'adressant à des clients développeur plutôt qu'à des applications clientes.
Il faut donc choisir votre client pour vous adresser à Cassandra : Ils sont listés ici.

En java, il en existe plusieurs. Hector semble clairement le plus utilisé et le plus configurable. C'est celui que j'utilise.

Environnement de développement
Si vous utilisez maven, la plupart des librairies dont vous avez besoin sont mavenisées et disponibles dans les repository centraux (l'exception est Cage qui nécessite de déclarer un repository spécifique).

Vous aimez faire des tests unitaires et du TDD, pas de problèmes, c'est possible et ça se fait même très bien. Il est possible de lancer Cassandra et Zookeeper de façon "embedded" dans votre JVM.

Il est même possible si vous le souhaitez de lancer Cassandra de façon embarquée et d'y charger des données avant d’exécuter vos tests unitaires. Je vous propose d'aller jeter un oeil du côté de cassandra-unit si vous souhaitez faire ça.

Ecosystème en évolution permanente
Que ce soit sur les fonctionnalités de Cassandra, son outillage, son écosystème, il y a beaucoup de changements, d'évolutions et d'améliorations.

De grosses et nouvelles fonctionnalités apparaissent constamment. Par exemple, il y a quelque mois, entre la version 0.7.8 et la 0.8.0, un langage de requêtage le "CQL" est apparu et très prochainement Cassandra sort en version 1.0... Ça va très vite.


Il faut globalement rester en veille sur les blogs, twitter, les mailing list (Cassandra et Hector par exemple) pour voir ce qui se fait, ce qui sort. La communauté autour de Cassandra est grossissante et est très réactive.


Ne pas avoir peur de défaire
Comme les choses changent et évoluent, Il ne faut pas avoir peur de jeter un peu, de modifier souvent, de refactorer beaucoup votre code. C'est dû soit à une évolution de compréhension de Cassandra qui vous fait dire qu'il faut mieux faire autrement, soit à l'apparition d'une nouvelle fonctionnalité soit à un lecture sur un blog...

Il n'y a pas de secret, ma meilleure arme pour gérer ses changements sont : mes tests unitaires et mes tests d'intégrations et ça se passe bien!

Pour aller plus loin
Vous pouvez aller jeter un oeil dans le code source de Cassandra sous svn ici ou sur le miroir sous Git ici.
Vous pouvez aller lire la documentation sur le wiki sur l'architecture interne de Cassandra ici et voir cette vidéo.
Vous pouvez contribuer en commençant ici.

Pour Conclure
Utiliser Cassandra comme backend pour stocker vos données à un réel impact sur votre façon de développer votre application. C'est quelque part assez normal dans le sens si vous utilisez Cassandra, c'est que vous avez normalement beaucoup de données à gérer et qu'il faut de toute façon obligatoirement prendre ça en compte pour développer votre application...

Une fois les efforts produits, quel plaisir de rajouter un noeud dans le cluster pour monter en charge...
En fait, Cassandra, c'est très "DevOps" :-).