Bonnes pratiques déploiement sites dev / test / prod

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

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

Forum : 
Support général
Version de Drupal : 
7.x

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

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

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.

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.