Je travaille sur mon premier projet Drupal sur XAMPP dans mon MacBook. C'est un prototype et il reçoit un retour positif 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 ?
Merci
Quelques conseils :
Utilisez le contrôle de source, PAS le 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'il ait un endroit où consigner les bogues, mais la première étape cruciale est de placer l'arbre source complet de votre site dans le contrôle de version. Lorsque des changements sont apportés sur le serveur de test ou de préparation, vous voyez s'ils fonctionnent, vous les validez, puis vous les mettez à jour sur le serveur réel. Les retours en arrière et le déploiement deviennent beaucoup, beaucoup plus simples. Pour les grappes de plusieurs webheads, vous pouvez répéter le processus ou effectuer un rsync à partir d'un seul serveur "canonique".
Cependant, 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 cohabiter avec bonheur.
Pour les dossiers volumineux comme le répertoire des fichiers, utilisez un lien symbolique dans l'emplacement "approprié" pour pointer vers un répertoire côté serveur en dehors du webroot. Cela permet à votre répertoire 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 ; le nettoyage de la base de données de développement/stage et sa mise en ligne est plus facile pour le déploiement initial, mais il y a quelques difficultés lors des mises à jour incrémentielles de la base de données si les utilisateurs du site en ligne génèrent également du contenu.
J'ai fait une présentation sur Meilleures pratiques de déploiement de Drupal l'année dernière. N'hésitez pas à consulter les diapositives.
Features.module est un outil extrêmement puissant pour gérer les changements de configuration de Drupal.
Les types de contenu, les paramètres CCK, les vues, les variables Drupal, les contextes, les préréglages Imagecache, les menus, les taxonomies et les autorisations peuvent tous être regroupés dans une fonctionnalité, qui peut être contrôlée dans le contrôle de version. À partir de là, le déploiement d'un nouveau site ou la modification d'un site existant sont facilement gérés par l'interface utilisateur des fonctionnalités ou par Drush.
Assurez-vous d'installer Strongarm.module pour exporter la configuration de Drupal qui est stockée dans votre table Variables. Vous pouvez également transformer du contenu ou des nœuds statiques (par exemple : about us, faqs, etc) en Features en installant le module uuid_features.
De loin, c'est le meilleur moyen de travailler avec d'autres développeurs sur le même site, et de faire passer votre site du stade du développement à celui des tests, puis à celui du stockage et de la production.
Nous avons eu une discussion approfondie à ce sujet sur mon lieu de travail, et la méthode que nous avons finalement adoptée consiste à pousser les mises à jour du code (y compris les modules et les thèmes) du développement vers la production. Nous utilisons Subversion pour cela, et cela fonctionne bien jusqu'à présent.
Ce qui est particulièrement important, c'est que vous automatisez un processus pour pousser la base de données arrière de la production, afin que vos développeurs puissent conserver leurs copies de la base de données aussi proches que possible de la production. Dans un environnement critique, vous voulez être absolument certain qu'une mise à jour de module ne va pas endommager votre base de données. Le processus que nous utilisons est le suivant :
Et c'est tout. Une chose à laquelle vous ne pouvez pas vraiment vous attendre avec un framework communautaire tel que Drupal, c'est de pouvoir déplacer votre base de données de testing à production après la mise en production. À partir de ce moment-là, tous les déplacements de bases de données se font de la production vers les tests, ce qui complique quelque peu le processus de déploiement. Soyez prudent ! :)
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
