Installer Hudson sur un serveur OVH

Pour installer le serveur d'intégration continue Hudson sur un serveur dédié OVH tournant Ubuntu, le plus pratique c'est de partir du package Debian et de suivre les instructions.

Le script va créer un utilisateur hudson, installer les binaires, les fichiers de configuration et le script de démarrage/arrêt.

Par défaut, l'espace disque est sous /home.

Si vous n'avez pas repartitionné votre serveur, vous pouvez déplacer la home et les logs de hudson.

# Stoppons Hudson

sudo /etc/init.d/hudson stop

# Passons sous /home/hudson

sudo mv /var/lib/hudson /home

sudo ln -s /home/hudson /var/lib/hudson

sudo mkdir /home/hudson/log

sudo mv /var/log/hudson/hudson.log /home/hudson/log/hudson.log

sudo ln -s /home/hudson/log/hudson.log /var/log/hudson/hudson.log

sudo chown -R hudson:nogroup /home/hudson

# Demarrons Hudson

sudo /etc/init.d/hudson start

La version Debian est un peu en retard sur la dernière version d'Hudson, voici comment la mettre à jour:

# Stoppons Hudson

sudo /etc/init.d/hudson stop

# Sauvegarde du war existant et download de la derniere version

cd /usr/share/hudson

sudo mv hudson.war hudson.war.old

sudo wget http://hudson-ci.org/latest/hudson.war

# Demarrons Hudson

sudo /etc/init.d/hudson start

Mise en place d'un serveur de build

Nous avions besoin d'un serveur de projet (wiki, intégration continue, subversion, ...), j'ai retenu 2 possibilités:

• Une solution "Software as a Service"
• Un serveur dédié

Software as a Service

On trouve beaucoup d'offres très bon marché (moins de 10 euros par mois pour une petite équipe) incluant un dépôt Subversion et une gestion de projet basée sur Trac ou Redmine mais il manque l'intégration continue

Atlassian propose avec JIRA Studio une solution complète a un prix correct et c'est probablement la solution que nous aurions retenue si nous n'avions pas aussi eu à installer d'autres applications comme Nexus. Donc nous sommes partis sur l'option serveur dédié en tout cas pour quelques mois.

Serveur dédié

J'ai regardé 3 solutions françaises: Dédibox, Gandi et OVH.

Gandi est une offre cloud computing très souple basée sur Xen, on achète des parts de serveur 12 € HT/mois qui correspondent à du CPU, de la RAM et du disque.

On peut provisionner plus de parts à l'heure près.

Cette offre me semblait sous dimensionnée en terme de CPU, disque et bande passante et dès qu'on rajoute des parts, la facture monte vite.

J'ai ensuite comparé un Dedibox XL et un OVH Super plan mini qui sont assez proches à 49.99€ HT/mois.

Au final j'ai opté pour OVH principalement parce qu'ils incluaient 100 Go d'espace de sauvegarde contre 10 chez Dedibox. De manière générale, quand on a beaucoup de données à sauvegarder, les prix grimpent.

Mon serveur était disponible moins d'une heure plus tard.

Créer des interfaces java est-il anti agile?

Créer des interfaces java facilite le découplage, permet d'utiliser des mocks pour les test unitaires, de changer d'implémentation, de créer des points d'interception mais peut-on considérer que c'est une pratique anti agile? Ma réponse est bien sur "Ça dépend" ;)

Oui si on considère que c'est du sur design (YAGNI) et qu'on attend d'avoir complètement défini les interfaces pour commencer a implémenter les classes concrètes.

Le Test Driven Design conduit à créer des classes concrètes, introduire des interfaces dans ce processus itératif le ralentit.

Par contre, on peut au cours d'une session TDD avoir besoin de créer une implémentation mock d'un DAO par exemple et au final en extraire une interface par refactoring quand le design s'est stabilise. On obtient ainsi une interface dont la conception a émergé du TDD et un mock utile pour les test unitaires des classes consommant cette interface.

Il ne s'agit pas non plus de créer des interfaces a tout bout de champ mais la où ça fait sens comme la couche d'accès aux données (d'où mon exemple sur un DAO) ou tout point d'intégration avec un module ou un composant de l'infrastructure.

Donc c'est plutôt le moment ou l'on crée une interface et la façon dont on la crée qui peut être non agile.