Submitted by cac on
Bonjour,
Je souhaiterais avoir vos retours d'expériences concernant votre manière de fonctionner quand il y a plusieurs environnements pour un même site
Sur un projet précédent, fait avec la version 5, nous apportons les modifications manuellement sur chaque serveur, ce qui rend la tache plutôt lourde. En gros nous développons ou apportons les corrections sur le serveur de dev, nous importons la base de données de la prod sur le test, effectuons les corrections à la main, mais comme entre temps des nodes ont pu être créées nous devons de nouveau tout faire à la main sur le serveur de production.
Certains rencontrent peut être la même problématique, dans ce cas comment faites vous? Existe t il des modules? Avez vous trouvé des solutions efficaces?
Un grand Merci
Un mot en passant pour
Permalien Soumis par DidierCastelnau le 28 Avril, 2011 - 10:10
Un mot en passant pour signaler mon intérêt pour ce sujet.
Concernant la migration de contenus, le module Backup and Migrate facilite l'import/export de tables : http://drupal.org/project/backup_migrate
En effet j’ai vu ce module,
Permalien Soumis par cac le 28 Avril, 2011 - 10:38
En effet j'ai vu ce module, et nous allons l'utiliser...
Mais je voulais savoir comment les drupaliens faisaient en général ;)
Parce qu'il reste comme pour tous les sites le souci de la prod qui continue à vivre pendant les modifications faites en dev, du coup les numéros de node etc continuent d'évoluer et il y a toujours un écart entre les différents serveurs
Autre solution, tu héberges
Permalien Soumis par kustolovic le 28 Avril, 2011 - 12:29
Autre solution, tu héberges tes sites dans le nuage (cloud computing) avec (p.ex. Amazon ec2).
En cas de besoin de faire des tests, tu dupliques rapidement une machine et hop voilà.
l’utilisation d’un système de
Permalien Soumis par mageonyme le 28 Avril, 2011 - 17:37
l'utilisation d'un système de versioning tel que https://github.com/ facilite bien les choses...
Je pensais que ça ne
Permalien Soumis par cac le 29 Avril, 2011 - 09:25
Je pensais que ça ne fonctionnait que pour le code, le versionning fonctionne également pour le contenu?
Non en effet mais avec un
Permalien Soumis par kustolovic le 29 Avril, 2011 - 09:39
Non en effet mais avec un outil comme drush et une connexion ssh c'est vite reglé.
Merci il faut que je regarde
Permalien Soumis par cac le 29 Avril, 2011 - 10:32
Merci il faut que je regarde ça, mais c'est en ligne de commandes c'est bien ça?
Peut être compliqué pour moi, vu que je ne gère que l'admin des sites et le front mais que je ne touche pas aux serveurs etc
Je viens de voir la vidéo
Permalien Soumis par cac le 29 Avril, 2011 - 11:11
Je viens de voir la vidéo d'utilisation de drush sur drupal 7 et effectivement ça a l'air bien sympa :)
Merci beaucoup
Salut, Je viens apporter mon
Permalien Soumis par cestra13 le 29 Avril, 2011 - 12:01
Salut,
Je viens apporter mon avis sur la manière de gérer différents sites (prod/dev/test).
Selon le type de site, il est préférable d'avoir qu'un seul server avec des sous domaines par exemple :
- http://www.tonsiteprod.com
- http://dev.tonsiteprod.com (avec une authentification .htaccess pour les dévellopeurs)
- http://test.tonsiteprod.com (authentification .htaccess pour les clients pour la validation)
donc sur le serveur :
- un dossier www (site de prod)
- un dossier dev (site en dev)
- un dossier test (site de validation client)
Maintenant, lorsque que tu dois apporter une modification, tu exportes ta base de données de ton site en prod sur ton site de dev. Lorsque que tu as fini, tu exportes ta base de données de ton site de dev sur ton site de test pour passer en mode de validation avec ton client. Une fois finis, tu exportes ta base de données de test sur ton site de prod.
Il est vrai que si le client apporte une modification sur le site de production entre le moment du dev et du test, cette ou ces modifications seront perdus pour la simple raison que tu n'auras pas la même base de données.
Pour pallier a ce problême, il me semble qu'il existe une fonctionnalité drupal pour exporter les contenus et de pouvoir les réimporter de manière simple.
Le plus simple, c'est de demander au client de n'apporter aucune modification sur le site en production le temps de finir le développement du site. Mais cela est aussi contraignant selon le type de site.
Je vais continuer à y réfléchir, et si je trouve une meilleur solution, je reviens vers toi.
Il existe node export en
Permalien Soumis par emerya le 1 Mai, 2011 - 21:12
Il existe node export en effet qui permet de faire cela.
Mais le meilleur moyen est en fait de bien connaître la BD et quels modules gère quelle bd (cf. module Schema pour aider).
Ainsi, l'utilisation de Backup and Migrate se fait non pas sur 100% des table, mais seulement sur les tables impactées par la dev. Il faut en effet conserver tous les contenus et ne pas les écraser. Ecraser uniquement les tables de configs.
Pour ma part, en fonction des projets, j'ai des projets où je décide où je gère quoi. Les blocs par ex. sont gérés en dev sur certains de mes projets (je sais que je peux écraser sans risque, et dans le cas d'une petite modif je la fais en prod et en dev).
Ensuite, il y a la solution du module features qui bouge pas mal de trucs de la bd vers des fichiers.
Je ne connaissais pas non
Permalien Soumis par cac le 2 Mai, 2011 - 09:50
Je ne connaissais pas non plus ces modules, je continue d'explorer :)
merci pour vos solutions
Je m’abonne à la discussion
Permalien Soumis par ledom le 30 Mai, 2011 - 21:59
Je m'abonne à la discussion car je suis également interessé.
Intéressé également.
Permalien Soumis par s0iZi le 6 Septembre, 2011 - 11:39
Intéressé également.