Ceci est une faiblesse. Drupal n'a pas les outils de développement intégrés qui facilitent le développement et le déploiement comme le fait Rails (par exemple). Un problème est que Drupal n'est pas conscient de son environnement nativement. Deuxièmement, il y a trop de méthodes et de modules différents qui nécessitent un soin particulier. Cela peut devenir très confus. Mais les choses s'améliorent avec Drush et Drush.
Je suppose ici que vous disposez d'un environnement de développement sur votre ordinateur local et d'un serveur en direct ou de transfert sur lequel vous téléchargez. La première chose à faire est de trouver très rapidement comment obtenir votre appareil de base de données et votre code vers et depuis votre serveur vers votre environnement de développement. Vous devez rendre cette procédure aussi simple que possible afin de pouvoir synchroniser différentes versions de votre site sans trop d'effort. Cela signifie que vous serez en mesure de gérer moins de changements chaque fois que vous déployez. Espérons que ...
Déplacer la base de données n'est pas trop difficile. Vous pouvez utiliser phpMyadmin ou mysqldump mais le module de migration de sauvegarde est mon outil préféré.
Pour télécharger du code à partir de votre référentiel ou site local, vous pouvez procéder de plusieurs manières. Si vous utilisez un système de contrôle de version comme git, vous pouvez valider sur votre machine locale et vérifier à nouveau sur le serveur de transfert. Il existe également des outils de déploiement spéciaux comme capistrano que vous devriez jeter un coup d'œil. (Si vous connaissez déjà ce genre de choses, il peut être avantageux pour les autres de le lire). Si vous utilisez FTP, vous devriez probablement essayer quelque chose de différent. Si vous travaillez avec un site qui est encore en production, vous pouvez vous permettre de faire de petits changements incrémentiels sur votre site local, puis de répéter sur le site en direct et de télécharger la nouvelle version de la base de données lorsque vos changements sont en place. Cela signifie que vous doublez la gestion de la base de données, mais que vous pouvez le faire en toute sécurité. Il maintient votre base de données plus proche les uns des autres et minimise les risques.
Vous pouvez également exporter la sauvegarde des vues sur votre serveur dans votre code ou les importer dans votre site en ligne. Il y a un hack pour contourner le déploiement des changements de cck ici: http://www.tinpixel.com/node/53 cela fonctionne bien mais ne peut pas vraiment gérer les changements comme les rollbacks. (Respect du type qui a écrit cela)
Vous pouvez également utiliser hook_updateN pour capturer les modifications, puis exécuter update.php pour les appliquer. J'ai travaillé sur un site d5 avec des dizaines de développeurs et c'était le seul moyen de faire avancer les choses. Cela peut être une bonne option si votre site est en ligne ou si vous avez besoin de tous les changements de schéma de base de données capturés dans un système de contrôle de version (de sorte que vous pouvez revenir en arrière).
En outre: Jetez un coup d'oeil à la marque drush et drush. Ces outils peuvent être très utiles. Je ne me souviens plus du soutien apporté à d5. Une dernière méthode pour gérer cela est de ne pas utiliser cck ou views (et d'utiliser des mises à jour de hook). Mais ce n'est vraiment approprié que pour les sites d'entreprise où vous avez de grandes ressources de développement. Cela peut sembler une suggestion étrange mais cela peut complètement nier tout ce problème.Désolé, je ne pourrais pas vous donner une réponse claire. C'est parce qu'on n'existe pas encore. Vous finirez par trouver votre propre rythme une fois que vous entrez dans. Gardez juste les sauvegardes de votre base de données si vous pouvez revenir à eux assez facilement.