Freelance, ce que j'aurais aimé savoir avant de l'utiliser

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,
Une information que j'aurais aimé avoir avant de toucher à Drupal c'est la fréquence de mises à jours des modules. Tout dépend bien sûr du nombre de modules utilisés.
Je suis drupal depuis la version 4 et j'ai eu bien du mal à me décider quand j'ai fait mon premier site sur la version à adopter. 5, 6, 7 ?
Mon choix s'est porté sur la 6 car les modules qui m'intéressaient commençaient à être supportés.
Je me retrouve aujourd'hui avec un seul site réalisé pour un client (5 autres en attente, mais ce sont des projets perso). En production depuis 1 mois, et une moyenne de 3 mises à jour de modules par semaine. Hier soir j'y ai passé 4 heures. Souvent c'est plus rapide, mais beaucoup plus long pour une mise à jour majeure.
Je n'ai bien sûr pas évalué ça pour chiffrer le cout de maintenance du site, et la seule solution que j'entrevois, pour éviter un ulcère, est de rembourser mon client et de le planter là.
J'ai effectué une installation multisite, mais j'ai laissé tomber mes projets perso sur cette installation, car pour chaque mise à jour, c'est la journée qu'il faudrait y passer.
Je finis par penser que Drupal pour un freelance doit être réservé aux sites qui ne nécessitent pas l'installation de modules complémentaires. Dommage, ça limite furieusement son intérêt.
Il faut aussi savoir qu'avec l'utilisation d'une dizaine de modules sympa on se retrouve vite avec 50 modules qui deviennent indispensables. Et que la possibilité d'incompatibilité se démultiplie… Un site nickel, testé trois mois peut se révéler avec une mise à jour d'un module buggué, devenir une superbe galère, et il faut quand on commence avoir à l'esprit qu'il est préférable d'être un pro de la ligne de commande pour appliquer un patch, au risque de devoir refaire son site avec un autre cms plus accessible à un non programmeur.
Drupal est donc tout sauf un CMS, c'est un superbe outil très chronophage de développement mutualisé (j'aurais donc tendance à dire : réservé aux développeurs qui ont du temps).
J'ajouterais aussi que le seul site d'info efficace est en anglais, et qu'il est préférable d'être à l'aise avec le jargon des développeurs pour s'en sortir.
Mais le plus dangereux est l'addiction ! quand on y a touché on ne peut plus s'en passer…
;-D

Version de Drupal : 

La version à utiliser est la 6. Drupal maintient 2 versions en parallèle, 5 et 6. Drupal 7 est une version de développement, donc à ne pas utiliser en production. Du coup tu dois toujours utiliser la version la plus haute des versions maintenues car si tu prenais la plus basse, tu n'aurais même pas un an avant d'avoir à tout migrer.

Je me retrouve aujourd'hui avec un seul site réalisé pour un client (5 autres en attente, mais ce sont des projets perso). En production depuis 1 mois, et une moyenne de 3 mises à jour de modules par semaine. Hier soir j'y ai passé 4 heures. Souvent c'est plus rapide, mais beaucoup plus long pour une mise à jour majeure.

Mettre un jour un site, ça s'automatise Si on faisait cela à la main on serait tous mort... Pour automatiser, une stratégie possible : http://arnumeral.fr/node/19 . Sinon la solution que moi j'utilise, c'est de mettre tes modules dans un dépôt subversion et de lier ces modules à chacun de tes projets. Ainsi une mise à jour c'est sur la machine d'intégration pour tester, puis juste un "svn up" et c'est tout. La mise à jour d'un site me prend en gros 1 minute, de temps de faire l'update SGBD.

J'ai effectué une installation multisite, mais j'ai laissé tomber mes projets perso sur cette installation, car pour chaque mise à jour, c'est la journée qu'il faudrait y passer.
Le multisite c'est le plus simple à mettre à jour !!! Un code, N bases de données, le code sur un serveur de version, on teste sur sa machine de dev, on commit, et on update sur le serveur. Ensuite le module "drush" permet de scripter les mises à jour de chaque bases en une seule commande... J'ai un multi-site avec 7 drupals dessus, j'y passe pas plus d'1/2 heure lorsque je met à jour l'ensemble.

Maintenant pour les mises à jour majeur, là c'est une autre paire de manches, c'est aussi pour cela qu'il faut faire bien gaffe à des usines à gaz comme Views. Un portage de Views1 vers Views2 sur un gros site et c'est 10 jours dans la tête...

Je finis par penser que Drupal pour un freelance doit être réservé aux sites qui ne nécessitent pas l'installation de modules complémentaires. Dommage, ça limite furieusement son intérêt.
Être freelance (j'en suis) ne dédouane pas de mettre en place des procédures de maintenance !Tu ne capitalises pas ton code, tu ne fais pas de qualité logiciel pour tes projets clients ? pourquoi le déploiement et la maintenance y échapperait ?

Il faut aussi savoir qu'avec l'utilisation d'une dizaine de modules sympa on se retrouve vite avec 50 modules qui deviennent indispensables. Et que la possibilité d'incompatibilité se démultiplie… Un site nickel, testé trois mois peut se révéler avec une mise à jour d'un module buggué, devenir une superbe galère, et il faut quand on commence avoir à l'esprit qu'il est préférable d'être un pro de la ligne de commande pour appliquer un patch, au risque de devoir refaire son site avec un autre cms plus accessible à un non programmeur.
Désolé mais c'est encore un problème d'organisation. Tu auras le même avec n'importe quel CMS organique qui te permet de faire TOUT ce que Drupal permet. Et l'organisation ici c'est d'avoir un serveur d'intégration et/ou de développement pour tester ses mises à jour avant de les balancer en production... Après il y a sûrement des cas d'effets de bord mais ça se gère. J'ai comme cela un module qui me casse les pieds pour un multi-site, ben pour l'instant il sort pas de la machine de dev tant que c'est pas réglé, et ça se règle très bien avec des outils de dev de base (eclipse, xdebug, etc;)

Drupal est donc tout sauf un CMS, c'est un superbe outil très chronophage de développement mutualisé (j'aurais donc tendance à dire : réservé aux développeurs qui ont du temps).
Ben ouais, c'est pas un CMS, c'est un framework de CMS :-) Tu devrais lire ce qu'en dit wikipedia qui en fait une très bonne description. En fait, rien que l'expression de Dries pour qualifier Drupal est assez parlante :"Un système pour CONSTRUIRE rapidement des applications WEB".

Maintenant j'ai dans mon entourage des tonnes de non-développeurs (thèmeurs ou administrateurs) qui l'utilise à très haute dose, avec les bonnes méthodes, ça fonctionne très bien. Mais en effet, ce n'est pas un produit "clef en main", en tout cas pas pour autre chose qu'un site perso. Ceci dit, tu peux regarder des choses comme "Open Attrium" qui s'oriente dans le sens "on the shelf".

J'ajouterais aussi que le seul site d'info efficace est en anglais, et qu'il est préférable d'être à l'aise avec le jargon des développeurs pour s'en sortir.
Clairement oui, mais il commence à y avoir des bouquins bien fait en français ceci dit.

Mais le plus dangereux est l'addiction ! quand on y a touché on ne peut plus s'en passer…
Ben disons qu'il n'a pas vraiment d'équivalent :-) Mais comme toute bête complexe il demande à être apprivoisée.

Bonjour Yoran,
J'ai survolé la réponse que tu m'avais déjà donné dans un autre fil mais je n'avais pas eu le temps de regarder en détail ni de te répondre et surtout de te remercier (((:-°

Je teste svn en ce moment (c'est pas gagné ;-), MAIS je bosse bien sur un serveur de dev (même s'il est distant : j'ai aussi sur ma bécane mais pas d'alerte avec le dernier module menu-dhtml alors que mon serveur linux fait chier) avant de mettre en place sur le site de prod (même si je fais ça en ftp).
Pour le module views je ne vois malheureusement pas trop comment m'en passer, même si j'ai eu la chance de n'avoir que 4 vues à reprendre au moment de passer de views 1 à 2, j'ai carrément supprimé le module et refait les 4 vues. Panel aussi m'a donné du fil à retordre et je ne parlerai pas de fck et imce… (bon comme par hasard ils étaient mis à jour juste au moment où je commençais à les intégrer, je vais moi aussi prendre un chat noir comme avatar)

Mais m'étant largement planté en sous-évaluant la quantité de maintenance, je pensais utile de prévenir. D'autant qu'on peut voir partout drupal élu meilleur CMS de l'année.
Disons aussi que le boulot obligé de technicien de surface m'a toujours un peu gonflé. Passer l'aspirateur une fois par semaine me semble suffire largement, 3 fois ça me gonfle, surtout que cette semaine il y avait des gobages sous ma fenêtre et qu'avec drupal j'ai pas eu le temps de monter mes mouches ! ;-)

Je suis très étonné du temps que tu passes à mettre à jour. Je suis aussi freelance, avec des install multisites. Si tu veux faire propre, et sans rien automatiser :
- dump des bases.
- ftp global.
- test en local.
- Si test ok, MAJ et update.php

Ce que je fais le plus souvent : :
- dump
- ftp global
- MAJ en prod (je sais, c'est mal)
- vérif.

Si ça marche pas, on revient à l'état antérieur et on bosse, mais c'est assez rare.

Ceci dit, je ne fais que du petit site pour petite PME ou pour artiste, du coup, une interruption de service 1h le soir n'est pas un drame.

En tout, 1/2 heure pour une MAJ de version et quelques modules.

J'ai tenté de faire ça à l'arrache, c'est coll quand ça se passe bien, sinon c'est d'office une demi journée de plantée.
Je suis dans un trou (et c'est peu de le dire : http://www.4fly.fr/noailles-mars.html ) avec une connexion toute pourrie, adsl 2mega mais qui rame plus qu'un vieux modem 56k… C'est même pas le FTP qui prends le plus de temps, mais l'accès aux pages pour le dump ensuite la MAJ et surtout la vérif, le temps d'affichage de la page modules… (Comme hier c'était le ctool 4 passes successives pour le désactiver)
le temps de vider le cache… déconnexion visite du site pour s'apercevoir qu'il n'y a plus un seul lien dans mes menus, que le panel de la page d'accueil m'envoie une erreur 404 etc…

Le temps que je retrouve le site comme je l'avais laissé 2h30 pour le serveur de test, c'est clair que j'ai intérêt à penser sérieusement à SVN.
Je teste gratuitement un serveur chez gandi j'en ai profité pour l'installer c'est automatique, mais pour se connecter c'est à nouveau l'enfer :
http://wiki.gandi.net/fr/hosting/using-linux/tutorials/gandiai/subversion

Bon je vais pas me plaindre, j'ai j'ai eu du bol avec le passage à views2, j'ai jamais perdu 10 jours, mais je ne trouve pas ça vraiment rassurant pour la suite ;-)

J'ai survolé la réponse que tu m'avais déjà donné dans un autre fil mais je n'avais pas eu le temps de regarder en détail ni de te répondre et surtout de te remercier (((:-°
Pas de soucis :)

e teste svn en ce moment (c'est pas gagné ;-),
Tu verras, c'est un investissement utile. Une approche (juste la mienne, pas forcement la meilleur) est d'avoir un projet "maître", avec un dossier sites/all/modules/mes_contribs (nom débile pour l'exemple) dans lequel je place les modules utilisés sur 9/10ième des projets. Le projet maître est sous subversion et j'utilise le tréééés pratique SVN:externals pour greffer ce dossier sur les autres projets. Ainsi lorsque une MAJ arrive sur un module, et que cette MAJ m'intéresse (tu n'es pas obligé de mettre à jour si 1/ ce n'est pas un pb de sécurité 2/ Les nouveautés ne t'apportent rien), je valide sur le projet maître, puis commit, puis je mets à jours les autres projets. Ensuite l'ami Drush permet une mise à jour automatisé des différentes bases de données. Pour l'instant ma technique roule bien. Tu peux pousser un cran l'automatisation (je l'ai fait sur un projet) en déployant automatiquement les mises à jours dés lors que tu les as commité (utilisation des hooks svn).

Si cela t'intéresse quelques tutos que j'ai réalisé :
Mise en oeuvre du serveur SVN - http://artisan.karma-lab.net/node/29
Utilisation de SVN - http://arnumeral.fr/node/96

Pour le module views je ne vois malheureusement pas trop comment m'en passer...
Si tu n'es pas dev (et une fois de plus, ce n'est pas péjoratif, je parle ici de dev dans l'esprit de la trilogie drupalienne devs/admins/thèmeurs) ce n'est pas possible de s'en passer. En revanche Panels, tout bon thèmeur y arrive sans soucis. D'une manière générale, un projet simple à maintenir est un projet où il y a le moins de modules possible :)

Wahooo !
Merci de ces liens reste plus qu'à transposer tout ça avec MAMP !
C'est pas gagné j'ai installé svn et ne le trouve pas sur mon disque
Je ferai un tuto si j'y arrive ;-)
Une demi journée passée avec 3 personnes sur la hotline de free et plus de micro-coupures, c'était lié à l'arrivée de mon IP fixe… une galère de moins, et l'impression que mon G5 est redevenu une bombe :-p