Un Electron Libre... - gestion de projet

Nginx, Redmine et PostgreSQL

NiCoS — Thu, 01 May 2008 22:03:00 +0200

Cela a été testé sur une Ubuntu "Hardy 08.04" & Debian "Testing/Lenny". Les utilisateurs d'Ubuntu rajouteront un sudo aux endroits qui vont bien

Pré-requis

Installons le socle de base

aptitude install nginx ruby rubygems ruby-pkg-tools ruby1.8-dev build-essential postgresql

Utilisons ensuite les gems pour installer les "paquets" ruby dont on a besoin :

gem install rails mongrel mongrel_cluster postgres-pr --include-dependencies

Dans ~/.bash_profile ou ailleurs (/etc/profile, /etc/environment, etc) tant qu'au final, ce bout de chemin soit ajouté à votre PATH.

export PATH="$PATH:/var/lib/gems/1.8/bin"

Création de la base postgresql

Nous allons d'abord changer un paramètre d'authentification de postgres en éditant le fichier @@ /etc/postgresql//8.3/main/pg_hba.conf@@ afin d'avoir la ligne suivante :

local   all         all                               md5

Redémarrez ensuite postgresql pour que votre modification soit prise en compte :

/etc/init.d/postgresql-8.3 restart

En root, devenez l'utilisateur "postgres", compte technique d'administration de postgres :

su postgres

Créer un utilisateur redmine et une base redmine

createuser redmine --no-superuser --no-createdb --no-createrole --login --pwprompt --encrypted
(pour le tutoriel, j'ai pris le mot de passe redmine)
createdb --owner=redmine --encoding=utf-8 redmine
exit

Pour tester votre compte :

psql -U redmine redmine

Installation de Redmine

Récupération de Redmine

Même si la version 0.7 de Redmine est sortie il y a quelques jours, un bug fait qu'il vaut mieux attendre la version 0.7.1...

J'utilise donc la branche 0.6-stable pour ce tutoriel et je récupère le tout par svn. A vous d'adapter selon votre besoin et votre expérience

cd /srv/rails/ 
(adapter ce chemin à l'endroit où vous voulez mettre redmine, pas besoin que ce soit dans /var/www)
svn co http://redmine.rubyforge.org/svn/branches/0.6-stable redmine-0.6

Configuration de la base de données

Créer le fichier config/database.yml...

cp config/database.yml.example config/database.yml

... avec le contenu suivant :

production:
  adapter: postgresql
  database: redmine
  host: localhost
  username: redmine
  password: "redmine"

Remplissez la base

Au niveau du répertoire de redmine :

rake db:migrate RAILS_ENV="production"
rake redmine:load_default_data RAILS_ENV="production"

Test de bon fonctionnement

Toujours depuis le répertoire de redmine :

mongrel_rails start --environment=production

En vous rendant sur http://localhost:3000/, vous devriez voir une instance redmine tourner et pouvoir vous y connecter avec les identifiants admin/admin.

Mise en place du cluster mongrel

Note : je voulais faire tourner redmine via fastcgi mais j'ai rien trouvé à ce sujet. Tous les tutoriels sont basés sur mongrel donc je fais comme les autres...

Créer le fichier config/mongrel_cluster.yml dans le répertoire Redmine :

user: vous
cwd: /srv/rails/redmine-0.6
port: "9000"
environment: production
group: vous
address: 0.0.0.0
pid_file: log/mongrel.pid
servers: 2

et lancer le cluster :

mongrel_rails cluster::start

Vous devriez pouvoir accéder à votre instance redmine via http://localhost:9000/ et http://localhost:9001/

Faire en sorte que le cluster démarre lors du démarrage de votre pc/serveur :

mkdir /etc/mongrel_cluster
ln -s /srv/rails/redmine-0.6/config/mongrel_cluster.yml /etc/mongrel_cluster/redmine.yml
cp /var/lib/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/
chmod +x /etc/init.d/mongrel_cluster
update-rc.d mongrel_cluster defaults

Configuration de nginx

Dernière étape, accéder à votre instance redmine sur le port 80 via nginx :

Dans /etc/nginx/sites-available/ ajouter un fichier "redmine" par ex contenant :

server {
        listen 80;
        server_name localhost;
        root /srv/rails/redmine-0.6/public;

        location / {
                proxy_set_header  X-Real-IP  $remote_addr;
                proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_redirect false;
                proxy_read_timeout 300;

                if (-f $request_filename/index.html) {
                        rewrite (.*) $1/index.html break;
                }

                if (-f $request_filename.html) {
                        rewrite (.*) $1.html break;
                }

                if (-f $request_filename.txt) {
                        rewrite (.*) $1.txt break;
                }

                proxy_pass http://127.0.0.1:9000/;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
                root html;
        }

        access_log /var/log/nginx/redmine.access.log;
        error_log /var/log/nginx/redmine.error.log;
}

Activez le site :

ln -s /etc/nginx/sites-available/redmine /etc/nginx/sites-enabled/redmine

et relancer nginx :

/etc/init.d/nginx restart

En vous rendant sur http://localhost/ vous devez avoir accès à votre instance redmine...

Connaissant pas du tout rails et mongrel, il y a peut être des améliorations à apporter. Pour nginx, idem. Je suis preneur d'améliorations

Maintenant, il me reste à étudier la migration de Trac vers Redmine...

Liens utiles :

Setting up a Redmine site on Ubuntu (pour redmine, postgresql et mongrel)
Installer et configurer switchpipe (pour la configuration nginx)
Doc Ubuntu-fr : Postgresql pour postgresql

Lecture : Petit guide à l'usage du développeur agile

NiCoS — Wed, 31 Oct 2007 00:06:00 +0100

Je n'en finis pas de mes lectures. Dernier livre donc sur ma liste : Petit guide à l'usage du développeur agile.

Le livre m'a bien plu et surtout les derniers chapitres sur le Test Driven Development (TDD), Document Driven Development (zut, pas de bon lien à mettre) (DDD) et la gestion de projet. La partie sur Python en tant que telle m'est globalement passée au dessus de ma petite tête du fait de mon niveau actuel sur le langage (j'ai néanmoins glané quelques trucs ici et là, directement applicable dans mes dev en cours).

Ce livre ne vous aidera pas à appréhender python (enfin moi, cela ne m'a pas aider) et à la limite il n'aborderait pas python, ce ne serait pas grave. L'intérêt du livre n'est pas là mais bien dans les conseils, méthodo, bonnes pratiques qui sont énumérées. Bon faut quand même l'avouer, quand on voit comment TDD et DDD s'appliquent à Python, ça laisse rêveur (et l'équivalent n'existe pas pour PHP ou même Ruby apparemment, surtout pour DDD).

Les seules choses que j'ai trouvé un peu pénible dans le livre tiennent plutôt sur la forme (le formatage du code pourrait être amélioré, pas mal de typo/fautes d'orthographe, etc.)

En tous cas, à lire pour tout (bon) développeur / chef de projet qui se respecte !

D'autres critiques du livre :

David, Biologeek : Envie de développer agilement en Python ? Suivez le guide !
Luvit, fiche de Petit guide à l'usage du développeur agile

Comment assurer la pérénité de son projet ?

NiCoS — Tue, 09 Oct 2007 21:50:00 +0200

Etant en train de mettre à jour un site réalisé sous SPIP 1.7 vers SPIP 1.9.2c (soit un écart proche de *21* versions intermédiaires (majeures ou mineures), voici quelques retours :

Ne pas suivre la mise à jour de l'outil qu'on utilise, c'est très mal. Avoir en tête tous les changements qui ont eu lieu entre ces versions relèvent parfois du casse-tête. Bon en même temps, un bug sur le critère titre_mot a empêché une mise à jour de l'outil pendant longtemps (au moins la version 1.8.2e, soit déjà 10 versions d'écart).
Ne pas documenter le code (php ou les squelettes SPIP), c'est mal aussi.
Ne pas conserver les sources des animations flash, c'est mal aussi (pour le coup, cela m'a simplement obligé à utiliser un lien symbolique suite à la réorganisation du bazar)

Du coup, on peut raisonnablement se dire que pour assurer la pérénité de son projet, il faut :

Documenter le code de façon satisfaisante :
- Utilisation de la javadoc, phpdoc, ...
- Utilisation de la balise REM pour les squelettes SPIP expliquant chaque boucle ou bloc de boucle (notamment avec les boucles HIERARCHIES)
- Documenter le fonctionnement du site, les règles de gestion, la raison d'être des différents articles, etc que ce soit dans un document externe ou au sein des squelettes par ex
Le code ne correspondant pas au code source de l'application doit être clairement identifiable.
- Seul le code source spécifique au projet doit dès lors être dans le gestionnaire de source du projet
Suivre les mises à jour de l'outil au fur et à mesure en tirant parti des nouvelles fonctionnalités
- Le nouveau compilateur (plus oblige a réécrire certaines boucles vu qu'il est moins laxiste que précédemment.
- L'apparition de #DOSSIER_SQUELETTE puis de CHEMIN{} permet ainsi de centraliser tous les éléments de vos squelettes et vous donne une plus grande flexibilité (plus de chemin en dur par ex)
- Le coût de la mise à jour est alors minime et réparti - plutôt qu'un gros coup prohibitif lors de la mise à jour 21 versions plus tard, risquant de plonger votre projet dans l'immobilisme total...
- La transformation de certains bouts de code en plugins SPIP (notamment pour des éléments insérés dans la partie privée) est un réel plus et améliore la lisibilité de votre site/code.
Suivre les mises à jour pour bénéficier des correctifs de sécurité
Sans oublier que la mise en page par tableaux, c'est une horreur à maintenir, illisible, etc.

La liste n'est sans doute pas exhaustive mais déjà rien que pour ce projet, je peux mettre un zéro pointé partout. Alors certes, un bug SPIP corrigé en 1.8.2e empêchait toute mise à jour vers la version 1.8 de l'outil, mais depuis, cela aurait du être fait proprement.

En tous cas, ça vous donne plein de bonnes pratiques pour vos prochains projets perso / cahier des charges / mode de gestion de projet / ... ; si ça vous en donne pas, moi si !

Getting real : impressions générales...

NiCoS — Tue, 30 Jan 2007 22:18:00 +0100

Après que le buzz soit passé et comme David remettait ça sur le tapis, je me suis dit qu'il fallait que je me mettre à lire Getting Real. J'avais lu le chapitre "There is nothing functionnal about a functionnal spec", qui m'avait fait sourire. Cela pouvait en effet être adapté à certains cas mais dans le cas de gros projets, de telles assertions me laissaient (et me laissent toujours sceptique).

Bref, je me suis dit, autant ne pas mourir idiot, autant lire le bouquin en entier pour m'en faire une vraie idée. J'ai donc acheté la version PDF que j'ai lu entre hier matin et ce matin en allant et revenant du travail (c'est dire si les 177 pages se lisent bien ).

Arrête de causer et viens en au fait me direz-vous... ok ok, j'y arrive !

Comme marqué dans le titre, ce sont des impressions générales, pour une revue détaillée, il faudra attendre un peu !

Donc globalement :

le bouquin est sympa à lire, contient de bonnes idées (pas forcément nouvelles, on retrouve des principes présents dans beaucoup de méthodes (KISS, XP, etc) ou seulement pleines de bon sens)
tout ça, c'est valable chez 37signals, il est possible de reproduire une partie de leur règles de conduites mais pour toutes les reproduires, les assertions deviennent très fortes. Comme ils le disent eux même, ça marche chez nous, ça peut ne pas marcher chez vous ou pas totalement. Comme toute méthode, il faut adapter à son propre cas,
J'ai vu pas mal de bonnes idées pour mes projets perso, voir même pro,
Certaines erreurs pointées du doigt m'ont fait penser à certains (moments de) projets ou missions ou lorsque je vois des clients repondre des méthodologies internes avec des documents de 30 pages mini (quand il est vide) pour chaque phase du projet et un reporting de dingue. Je vois mal un chef de projet faire 80% de reporting et 20% de gestion de projet.
Certaines de leurs règles sont valables pour des projets simples ou de petites tailles, voir uniquement pour des projets réalisés en interne. Par contre, je vois mal dire à un client : bon ben finalement pour le prix et le délai qu'on a, on ne développe que 50% du périmètre. Pour un engagement au forfait, c'est pas adapté par ex !

Bref, je pense que tout développeur ou chef de projet devrait lire le livre s'il en a l'occasion. Par contre, comme tout livre de méthodologie, il faut savoir l'adapter à son cas et ne pas se lancer dans une application stricte sous peine d'échec assuré à mon humble avis.

Pour ceux qui l'ont lu, qu'en avez-vous pensé ?

Pour la version commentée en détail, faudra attendre un peu