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é :

1. Copier le code source provenant du serveur de version vers l'environnement cible.
2. Nettoyer l'arborescence de tout ce qui est inutile pour le fonctionnement de l'appli (doc, tests, scripts sql... ).
3. 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).
4. 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

Je pige pas ta question (mais je suis naze). En gros les CMS pour la plupart, tu as des procédures de mise à jour du code qui leur sont spécifique. Mais jamais tu perds tes données. Même avec Joomla

Ce que je veux dire, c'est que les modules des CMS créent des tables en base, où ils stockent leur configuration.
Donc si je veux déployer un nouveau module que j'ai installé en dev sur la prod, il ne suffit pas d'uploader le code source, mais aussi les modifs de base. Et ça, je ne vois pas comment, ça n'a pas l'air très documenté, ni standardisé. Souvent ce que je trouve c'est des solutions qui disent : "backup ta base de dev et importe-la sur la prod", mais à ce moment-là tu écrases tout le contenu "live" généré par les utilisateurs sur la prod, ce qui est bien entendu inadmissible !
Ce problème ne se pose pas dans un dev spécifique, puisque par définition tu connais les changements de base que tu fais, et tu les versionnes dans des scripts de migration SQL.

Pour illustrer, voici un exemple typique de solution que je veux éviter :
http://www.saintsjd.com/2011/01/continuous-deployment-for-wordpress-using-git-and-fabric/
(voir aussi les commentaires)

J'avais vu un truc pour Drupal qui permet de faire des scripts pour automatiser des déploiements.
Je pense que c'est Drush http://drupal.org/project/drush.
En un autre truc, mais je reviens plus sur le nom, pour gérer une infrastructure de sites (dev, prod, Staging, etc.)
Je pense que c'est un outils basé sur Drush qui te permet de gérer une 'ferme de sites', de vérifier les mises-à-jour, cloner etc.

Mais je pige pas ton soucis toujours. De la même manière que l'install en dev va modifier la base, l'install de ton module en prod va la modifier pour que ça tourne. Sinon franchement faut changer de CMS

Mon souci n'est pas qua la base soit modifiée (c'est en effet parfaitement normal), mais que je ne trouve aucune manière de faire la migration proprement, en douceur, sans écraser les autres données déjà présentes sur la prod, car éditées en live par les utilisateurs (qui postent des articles, des commentaires, des topics de forum, que sais-je).

Je vois toujours pas le problème

Permet moi de lever un doute.
Je suppose que tu a compris que l'export-import de la DB c'est:
1. Arrêter la prod.
2. Exporter les données de prod.
3. Mettre à jour le cms/modules/ plugins
4. Importer les données de prod.
5 Démarrer la prod.

Et pas
...
2. exporter les données de test.
...
4. Importer les données de test sur la prod.

Je me sens moins seul, merci

Je viens de retomber sur le nom : aegir
http://www.aegirproject.org/
Sorry, j'ai pas pris le temps de relire pour voir si c'est bien ce que je pense.

J'ai vu les 2

Mais aucune des solutions n'est acceptable.

En effet, certes la solution 1 n'écrase pas de données de prod, mais elle requiert de couper la prod à chaque fois qu'on veut faire un correctif ou une évolution sur le site ! Impensable...
De mon point de vue, quand on coupe un site de prod, ça devrait être à peine quelques (milli)secondes lors d'un déploiement automatique...
Le développement doit pouvoir se faire en parallèle d'une prod qui tourne ! C'est inimaginable de devoir couper un site de production le temps que dure chaque itération du développement...

Et on est bien d'accord que la solution 2 n'est valable que pour la mise en prod initiale; mais pourtant c'est cela qu'on trouve le plus souvent "expliqué" dans des articles sur internet qui parle de déploiement de CMS...


Pinou> merci, je vais regarder ça Pour Drush le nom me dit qqch, j'avais entendu parler, je vais regarder aussi.

D’expérience avec drupal ou wordpress, ce que je fais en générale, avec www le site de prod, new le nouveau site, sur le même serveur, dans un répertoire parallèle.


1 geler la prod, le site fonctionne mais n'accepte plus d'input.
2 je mets à jour dev avec les données de la prod.
3 je mets en ligne la prod sur new
4 je renomme les répertoires
5 prod est à jour, profit.

Avec de l'automatisme, ça prend entre 5 et 15 min. Parfois j'ajoute une étape test intermédiaire pour le client vérifie (ça le rassure).

Généralement, on ne fait pas ça en pleine journée, mais plutôt en week-end ou en fin de soirée.

Max> Tu travaille souvent avec des CMS ?
Je pensais que tu faisais que du "home made".

J'ai quelques clients en drupal et wordpress, le reste c'est du homemade (à base de cakephp le plus souvent).

Je plussoie max plus ou moins, j'ai opté pour un dev/prod (et je rajoute bientôt pré prod pour qqs soucis), mais le déploiement est totalement automatisé. Modif de DB, de code, tout est mis à jour en un coup, et les coupures dépassent rarement 30s pour du passage en prod.

Les mises à jour de Drupal/Joomla et cie, c'est vrai que ça demande un peu plus de temps, c'est chiant

max> Cool s'il est possible de rendre la prod read-only, c'est déjà plus acceptable du point de vue utilisateur (sauf si c'est un forum ).


Question sur le 2 : Comment fais-tu si tu as par exemple installé un nouveau module sur le dev ? Tu n'importes que certaines tables de la base de prod (genre celles que les utilisateurs peuvent avoir modifiées) ? C'est un script que tu as fait toi-même ou il y a module pour ça ?
Parce que si tu importes la base de prod intégralement sur ton dev, ça veut dire que tu es obligé de faire les modifs de config (ajout de module, paramétrage etc.) après, et donc de potentiellement bloquer la prod en read-only pendant plusieurs jours, le temps du dev quoi.

D'accord pour la solution 2
Cependant,la solution 1 , est la solution standard (en gros) lors d'un upgrade applicatif après mise en production.
Il existe des solutions non-stop, mais c'est destiné à des applications critiques qui ne peuvent s'arrêter. Et qui coûtent 10 à 100 fois le budget d'une solution standard.

En théorie, ce serait le rêve. En pratique, ce n'est pas rêveur qui est le payeur.