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.

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.

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

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

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

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.

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.

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.

Je me sens moins seul, merci

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.