Poster une réponse à un sujet: Les CMS sont-ils compatibles avec une méthodologie de dev et déploiement professionnelle ?
Attention, ce sujet est un sujet ancien (4288 jours sans réponse)
Dr_Dan
J'ai vu les 2
![:wink: :wink:](images/smileys/wink.gif)
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...
![:fumer: :fumer:](images/smileys/fumer.gif)
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...
![:kiki: :kiki:](images/smileys/kiki.gif)
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.
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
ovh
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.
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
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.
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.
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.
zion
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
Les mises à jour de Drupal/Joomla et cie, c'est vrai que ça demande un peu plus de temps, c'est chiant
![:ocube: :ocube:](images/smileys/ocube.gif)
max
J'ai quelques clients en drupal et wordpress, le reste c'est du homemade (à base de cakephp le plus souvent).
Pinou
Max> Tu travaille souvent avec des CMS ?
Je pensais que tu faisais que du "home made".
Je pensais que tu faisais que du "home made".
max
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.
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.
ovh
Permet moi de lever un doute.
![:chut: :chut:](images/smileys/chut.gif)
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.
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
J'ai vu les 2
![:wink: :wink:](images/smileys/wink.gif)
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...
![:fumer: :fumer:](images/smileys/fumer.gif)
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...
![:kiki: :kiki:](images/smileys/kiki.gif)
Pinou> merci, je vais regarder ça
![:smile: :smile:](images/smileys/smile.gif)
Pinou
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.
http://www.aegirproject.org/
Sorry, j'ai pas pris le temps de relire pour voir si c'est bien ce que je pense.
zion
Et pas
...
2. exporter les données de test.
...
4. Importer les données de test sur la prod.
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
Je me sens moins seul, merci
![:petrus: :petrus:](images/smileys/petrus.gif)
Dr_Dan
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 !
Permet moi de lever un doute.
![:chut: :chut:](images/smileys/chut.gif)
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.
![:tinostar: :tinostar:](images/smileys/tinostar.gif)