Programmation » Les CMS sont-ils compatibles avec une méthodologie de dev ...
Catégorie:  
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 04/12/2012 @ 23:44:08,
Par ovh
Bonjour à tous :smile:

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 ? :grin:

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

Dernière édition: 04/12/2012 @ 23:59:23
Je n'ai rien à voir avec www.ovh.com
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 00:05:36,
Par zion
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 :tinostar:
Je suis le Roy :ocube:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 13:38:39,
Par ovh
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)

Dernière édition: 05/12/2012 @ 13:39:32
Je n'ai rien à voir avec www.ovh.com
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 15:08:24,
Par Pinou
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.
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 19:37:47,
Par zion
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 :ocube:
Je suis le Roy :ocube:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 22:34:17,
Par ovh
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 n'ai rien à voir avec www.ovh.com
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 05/12/2012 @ 23:40:20,
Par zion
Je vois toujours pas le problème :ddr555:
Je suis le Roy :ocube:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 01:35:36,
Par 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:
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:
Se tromper est humain ; Vraiment foutre la merde necessite le mot de passe de root. :petrus:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 07:47:33,
Par zion

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

:tinostar:


Je me sens moins seul, merci :petrus:
Je suis le Roy :ocube:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 10:39:33,
Par 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.
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 11:38:12,
Par ovh


Permet moi de lever un doute. :chut:
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:

J'ai vu les 2 :wink:

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:

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:


Pinou> merci, je vais regarder ça :smile: Pour Drush le nom me dit qqch, j'avais entendu parler, je vais regarder aussi.
Je n'ai rien à voir avec www.ovh.com
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 12:13:00,
Par 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.
Trololo
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 13:44:40,
Par Pinou
Max> Tu travaille souvent avec des CMS ?
Je pensais que tu faisais que du "home made".
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 14:03:57,
Par max
J'ai quelques clients en drupal et wordpress, le reste c'est du homemade (à base de cakephp le plus souvent).
Trololo
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 15:00:37,
Par 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 :ocube:
Je suis le Roy :ocube:
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 16:55:59,
Par 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 :tinostar: ).

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.

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.

Dernière édition: 06/12/2012 @ 16:56:15
Je n'ai rien à voir avec www.ovh.com
   
Les CMS sont-ils compatibles avec une méthodologie de dev ...
Publié le 06/12/2012 @ 17:57:20,
Par Dr_Dan

J'ai vu les 2 :wink:

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:

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:

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:
Se tromper est humain ; Vraiment foutre la merde necessite le mot de passe de root. :petrus:
Répondre - Catégorie:  
Informaticien.be - © 2002-2024 AkretioSPRL  - Generated via Kelare
The Akretio Network: Akretio - Freedelity - KelCommerce - Votre publicité sur informaticien.be ?