Quelle est la meilleure stratégie de déploiement Drupal?
Je travaille sur mon premier projet Drupal sur XAMPP dans mon MacBook. C'est un prototype et reçoit des retours positifs de mon client.
Je vais déployer le projet sur un VPS Linux deux semaines plus tard. Existe-t-il un meilleur moyen que de "tout refaire" sur le serveur à partir de zéro?
- installer Drupal
- modules de téléchargement (CCK, vues, date, calendrier)
- créer le contenu
- ...
Merci
Quelques conseils:
Utilisez le contrôle de source, PAS FTP/etc., Pour les fichiers. Peu importe ce que vous utilisez; nous avons tendance à créer un compte Subversion Unfuddle.com pour chaque client afin qu'ils aient également un endroit pour enregistrer les bogues, mais la première étape critique consiste à obtenir l'arborescence source complète de votre site dans le contrôle de version. Lorsque des modifications sont apportées sur le serveur de test ou le serveur intermédiaire, vous voyez si elles fonctionnent, vous vous engagez, puis vous mettez à jour sur le serveur en direct. Les restaurations et le déploiement deviennent beaucoup, beaucoup plus simples. Pour les clusters de plusieurs têtes Web, vous pouvez répéter le processus ou rsync à partir d'un seul serveur "canonique".
Si vous utilisez SVN, vous pouvez également utiliser les extractions CVS de Drupal et d'autres modules/thèmes et les métadonnées SVN/CVS pourront vivre côte à côte avec bonheur.
Pour les dossiers volumineux comme le répertoire des fichiers, utilisez un lien symbolique à l'emplacement "approprié" pour pointer vers un répertoire côté serveur en dehors de la racine Web. Cela permet à votre référentiel de contrôle de source d'inclure tout le code et un lien symbolique, au lieu de tout le code et de tous les fichiers que les utilisateurs ont téléchargés.
Les bases de données sont plus délicates; nettoyer la base de données de développement/intermédiaire et la pousser à vivre est plus facile pour le déploiement initial, mais il y a quelques rides lors de la mise à jour incrémentielle de la base de données si les utilisateurs du site en direct génèrent également du contenu.
J'ai fait une présentation sur Meilleures pratiques de déploiement Drupal l'année dernière. N'hésitez pas à consulter les diapositives.
Fonctionnalités . Module est un outil extrêmement puissant pour gérer les changements de configuration Drupal.
Les types de contenu, les paramètres CCK, les vues, Drupal variables, contextes, préréglages Imagecache, menus, taxonomies et autorisations peuvent tous être intégrés dans une fonctionnalité, qui peut être vérifiée dans le contrôle de version. À partir de là, le déploiement d'un nouveau site ou l'introduction de modifications sur un site existant est facilement géré avec l'interface utilisateur des fonctionnalités ou Drush.
Assurez-vous que vous installez Strongarm.module pour exporter drupal qui est stockée dans votre table Variables. Vous pouvez également du contenu/nœuds statiques (c'est-à-dire: à propos de nous, FAQ, etc.) dans les fonctionnalités en installant uuid_features .module.
C'est la meilleure façon de travailler avec d'autres développeurs sur le même site et de déplacer votre site du développement aux tests en passant par la mise en scène et la production.
Nous avons eu une discussion approfondie à ce sujet sur mon lieu de travail, et la façon dont nous nous sommes finalement installés consistait à pousser les mises à jour de code (y compris les modules et les thèmes) du développement à la mise en scène à la production. Nous utilisons Subversion pour cela, et cela fonctionne bien jusqu'à présent.
Ce qui est particulièrement important, c'est que vous automatisiez un processus pour pousser la base de données retour de la production, afin que vos développeurs puissent garder leurs copies de la base de données aussi près que possible de la production. Dans un environnement critique, vous voulez être absolument certain qu'une mise à jour de module ne va pas arroser votre base de données. Le processus que nous utilisons est le suivant:
- Installez un module sur le serveur de développement.
- Prenez note des modifications et mises à jour nécessaires. S'il y a des problèmes, revenez en arrière et recommencez jusqu'à ce que vous ayez un processus solide et sans erreur.
- Testez vos modifications! Répétez votre processus de test en tant qu'utilisateur normal et connecté, puis en tant qu'utilisateur anonyme.
- Si le processus de mise à jour impliquait autre chose que l'exécution de update.php, alors écrivez un script pour le faire.
- Copiez la base de données de production sur votre serveur intermédiaire et effectuez immédiatement les mêmes étapes. S'il échoue, diagnostiquez l'échec et revenez à l'étape 1. Sinon, continuez.
- Testez vos modifications!
- SAUVEGARDEZ VOTRE BASE DE DONNÉES DE PRODUCTION et PRENEZ NOTE DE LA RÉVISION QUE VOUS AVEZ VÉRIFIÉE DE SVN.
- Mettez votre production Drupal en mode maintenance, exécutez "svn update" sur votre arbre de production et passez par votre processus de mise à jour.
- Sortez Drupal du mode maintenance et testez tout (en tant qu'administrateur, utilisateur normal et anonyme)
Et c'est tout. Une chose à laquelle vous ne pouvez jamais vraiment vous attendre pour un framework communautaire tel que Drupal est de pouvoir déplacer votre base de données des tests vers la production après la mise en ligne. aux tests, ce qui complique quelque peu le processus de déploiement. Attention! :)
Nous utilisons largement le module Fonctionnalités pour capturer des fonctionnalités, puis les installer facilement sur le site de production.
Je suis surpris que personne n'ait mentionné le module Déploiement . Voici un extrait de sa page de projet:
... conçu pour permettre aux utilisateurs de facilement mettre en scène le contenu d'un site Drupal à un autre. Deploy gère automatiquement les dépendances entre les entités (comme les références de nœuds). Il est conçu pour avoir une API riche qui peut être facilement étendu pour être utilisé dans une variété de situations de mise en scène de contenu.
Je ne travaille pas avec Drupal, mais je travaille beaucoup avec Joomla. Je déploie en archivant tous les fichiers dans la racine Web (tar et gzip dans mon cas, mais vous pouvez utiliser Zip), puis en téléchargeant et en développant cette archive sur le serveur de production. Je prends ensuite un vidage SQL (mysqldump -u user -h Host -p databasename> dump.sql), le télécharge et utilise la commande inverse pour insérer les données (mysql -u produser -h prodDBserver -p prodDatabase <dump.sql ). Si vous n'avez pas accès à Shell, vous pouvez télécharger les fichiers un par un et écrire un script PHP pour importer dump.sql.
Tout système de contrôle de version (GIT, SVN) + Fonctionnalités module à déployer Drupal + paramètres personnalisés (types de contenu, champs personnalisés, dépendances de module, vues, etc.).
Comme le module Déployer est toujours en mode développement, vous pouvez donc utiliser le module Exportation de nœud dans Drupal 7 pour déployer votre contenu/nœuds .
Si vous êtes nouveau dans le déploiement (et ou Drupal), assurez-vous de tout faire en une seule fois. Vous devez être très prudent lorsque des utilisateurs effectuent du contenu pendant que vous travaillez sur une autre copie.
Il est possible de laisser les tableaux relatifs au contenu réel, à la taxonomie, aux utilisateurs, etc. plutôt qu'à leur structure. Appuyez ensuite sur celles relatives à la configuration. Cependant, cela ajoute un ordre de grandeur de complexité.
Toutes mes excuses si le déploiement est quelque chose de vieux pour vous, c'est donc vaguement insultant.
Une bonne stratégie que j'ai trouvée et que j'implémente actuellement consiste à utiliser une combinaison du module de déploiement pour migrer mon contenu, puis à utiliser les dbscripts pour fusionner et mettre à jour le noyau et les modules. Il prend en charge la fusion de bases de données même si vous avez du contenu en direct, de la sécurité et des mises à jour de modules, et j'ai actuellement le mien configuré pour fonctionner avec svn.