Les CMS sont-ils compatibles avec une méthodologie de dev et déploiement professionnelle ?

[ovh]

Bonjour à tous

Si le titre est un peu provocateur, je voudrais soulever une vraie question qui est importante à mes yeux.

Je précise que je débute dans l'utilisation des CMS, mais par contre je m'y connais en dev spécifique d'appli web en PHP (à usage professionnel). Mais j'ai pour projet de réaliser un petit site communautaire pour lequel un CMS semble tout à fait adapté (les besoins me semblent relativement standards, donc un CMS est en théorie l'idéal; le dev spécifique ayant toujours l'inconvénient majeur de prendre énormément de temps puisqu'il faut tout faire soi-même).

Pour du dev spécifique, on va en général utiliser 3 ou 4 environnements :

1. Environnement de dev en local sur son poste (site + base de données)
2. Environnement de test : après chaque modification du code, l'appli est déployée sur un serveur de test pour s'assurer que tout marche comme prévu (et sans régression) dans un environnement aussi proche possible de la réalité (prod)
3. Environnement de recette (staging) : un autre environnement de test, mais déployé moins souvent, donc plus stable, accessible à des utilisateurs "pilotes"
4. Environnement de prod : l'appli finale stabilisée

Le code applicatif est hébergé sur un serveur de version (svn, git... ), de même que les évolutions de la base de données sous forme de scripts SQL de 3 types :

1. Modification de structure des tables, relations, etc.
2. Modification des vues et procédures stockées.
3. Injection de données initiales ou migration de données (par exemple pour ne perdre aucune donnée lors des changements de structure).

Nous avons alors un script de déploiement automatisé sur les environnements test, recette et prod qui va, en résumé :

• Copier le code source provenant du serveur de version vers l'environnement cible.
• Nettoyer l'arborescence de tout ce qui est inutile pour le fonctionnement de l'appli (doc, tests, scripts sql... ).
• Eventuellement modifier à la volée certaines configurations pour s'adapter à l'environnement cible et récupérer certains fichiers de l'environnement "live" (ex : fichiers de cache).
• Exécuter les scripts SQL nécessaires pour mettre à jour la base de données "proprement", c'est-à-dire sans perte des données saisies par les utilisateurs en production.

Ce script pouvant être soit un script shell, soit un script d'un outil de déploiement spécialisé tel que Ant, Phing, Capistrano...
Le tout assure en principe des livraisons sans douleur, sans perte de données, et très aisée (un script à lancer).

Par contre, dans le cas d'un CMS, quelqu'il soit, je ne vois pas comment atteindre le même objectif...
Dans l'idéal je voudrais pouvoir réaliser le site en local, puis déployer toutes ses évolutions successives en test, recette et prod en utilisant un script de déploiement automatique... Mais alors que sur un dev spécifique on maîtrise l'appli de bout en bout, côté code et côté base, dans un CMS comment faire pour déployer l'installation et la configuration des modules/plugins du CMS sans écraser les données de production ?

En effet, j'ai vu sur internet pas mal de "solutions" à base d'un script de déploiement automatique certes, mais qui font un export-import de la base de données ! Ce qui n'est évidemment pas le but recherché, puisque ça va forcément écraser la base de données de production, et pour moi il est impensable de perdre les données saisies sur l'environnement de production !

En est-on réduit à effectuer les déploiements à la main, en gros en reproduisant toute la configuration faite en local sur la prod dans l'interface graphique du CMS, avec tous les risques d'erreur que cela comporte ? Ce qui est donc tout sauf professionnel ?
Ou existe-t-il des solutions miracles ?

J'ai cherché (en vain) des solutions plus particulièrement pour Wordpress, ensuite Drupal, mais je me rends compte qu'en fait c'est une question qui touche tous les CMS.
Ou si vous pouvez m'en conseiller un autre mais qui gère bien cet aspect, pourquoi pas ?

Un grand merci

[ovh]

Pour compléter mon propos, voici un exemple typique de solution que je veux éviter :
http://www.saintsjd.com/2011/01/cont...it-and-fabric/
(voir aussi les commentaires)