Comment migrer d'un environnement de test vers un environnement de production?
La migration s'effectue de l'environnement local vers l'environnement de production. L'environnement de production a fonctionné un certain temps et a créé de nombreux articles.
Afin d'ajouter de nouvelles choses à mon site, j'ai ajouté un thème personnalisé et installé CCK, Views et d'autres modules dans mon environnement de test local. Maintenant que l'environnement de test local est terminé, comment le migrer vers l'environnement de production, sans détruire le contenu de sa base de données?
Il s'agit d'un problème non trivial pour lequel presque tout le monde a une réponse différente: il n'y a pas de moyen canonique Drupal de gérer le transfert aux poussées de production. Dries Buytaert, le gars qui dirige l'émission Drupal, en a fait l'une des initiatives clés de Drupal 8 . Bien sûr, Drupal 7 vient d'être publié, il faudra donc un certain temps avant que cela porte ses fruits.
Le problème peut être divisé en deux problèmes distincts:
- Configuration intermédiaire (variables, types de contenu, champs, vues, etc.)
- Contenu intermédiaire (nœuds, utilisateurs, etc.)
Le premier peut être principalement géré par le module Fonctionnalités , qui prendra la configuration de votre site et le transformera en un module que vous pourrez ajouter à votre installation Drupal: de cette façon, vous pouvez ajouter à votre système de contrôle de version et ne pas avoir à vous soucier qu'il soit emporté lorsque vous migrez votre contenu.
Ce dernier est vraiment délicat, car sur un site actif, il est probable que le contenu change en production même après avoir effectué la synchronisation initiale avec votre environnement de développement. Cela empêche le remplacement en gros du contenu pendant le transfert comme vous pouvez le faire avec la configuration.
De plus, Drupal n'utilise pas d'identifiants universellement uniques (UUID) pour le contenu: chaque fois qu'un nœud ou un utilisateur est ajouté, l'ID augmente de un. Donc, ce qui pourrait être le nœud 45 sur votre site de développement pourrait être le nœud 90 sur votre site de production.
Malheureusement, je n'ai pas de bonne solution: le contenu de mise en scène est une véritable faiblesse de Drupal. Ce que je fais personnellement, c'est ajouter du contenu sur le site de production uniquement. Si un client veut voir à quoi ressemble le contenu avant sa mise en ligne, je vais configurer un clone du site de production qui n'est accessible qu'au client. Ensuite, une fois approuvées, les mêmes modifications sont alors apportées directement à la production.
Il existe une autre alternative: le module Deploy . Il est censé tirer parti Services pour rendre le contenu de mise en scène relativement indolore. Mais je ne peux pas garantir son efficacité et il n'a pas de version Drupal 7.
Dans notre processus.
- Nous avons un script Shell qui extrait la base de données de prod.
Nous utilisons Hudson pour reconstruire nos branches dev/staging pour synchroniser les branches live et dev.
Puisque nous utilisons Git, chaque tâche que nous effectuons a sa propre branche, puis lorsqu'elle est transmise à QA, nous la fusionnons pour la maîtriser en tant que serveur intermédiaire pour les tests de régression.
Lorsque le maître est prêt, nous faisons une version test de notre
Release Serverqui est une réplique de live (configuration, hardware, etc).Nous utilisons le module
Featurepour déployer les configurations. Certains éléments ne sont pas encore pris en charge par la fonctionnalité, nous utilisons donc hook_update_N puis exécutons updatedb.php oudrush -vd updb- Après la libération, effectuez la restauration des fonctionnalités (
drush fra --yes) pour annuler toute fonction remplacée. Puisque nous utilisons Boost (passage à Varnish) et Memcache, nous devons vider le cache (
drush cc all).Nous utilisons rsync pour synchroniser nos images/vidéos etc ...
Pour migrer d'un serveur XAMPP vers un autre serveur, j'ai suivi les instructions sur ce site .
Assurez-vous de conserver la même structure sur votre serveur de production que sur votre serveur de développement. J'ai également dû éditer certains fichiers dans Drupal tableau de bord admin situé à: admin/config/media/file-system
Assurez-vous que votre Chemin du système de fichiers public et Répertoire temporaire ont les emplacements corrects définis.