Это слабость. У Drupal нет встроенных инструментов разработчика, которые делают разработку и развертывание такими же, как Rails (например). Одна из проблем заключается в том, что Drupal не знает об окружающей среде. Во-вторых, существует слишком много различных методов и модулей, которые требуют особого внимания. Это может быть очень запутанным. Но все становится лучше с drush и drush make.
Я предполагаю, что у вас есть среда разработки на вашем локальном компьютере и живой или промежуточный сервер, на который вы загружаете.
Первое, что вам нужно сделать, это выяснить, как быстро получить базу данных и код на сервере и с вашего сервера в среду разработки. Вам нужно сделать это как можно более безболезненным, чтобы вы могли поддерживать разные версии своего сайта без особых усилий. Это будет означать, что вы, надеюсь, сможете управлять меньшими изменениями при каждом развертывании. Надеюсь ...
Перемещение базы данных вокруг не слишком сложно. Вы можете использовать phpMyadmin или mysqldump, но модуль резервного копирования - мой любимый инструмент.
Чтобы загрузить код из своего локального репозитория или сайта, можно сделать несколькими способами. Если вы используете систему управления версиями, такую как git, вы можете зафиксировать ее на своем локальном компьютере и снова проверить на промежуточном сервере. Существуют также специальные инструменты развертывания, такие как capistrano, на которые вы должны обратить внимание. (если вы уже знаете это, это может принести пользу другим людям). Если вы используете FTP, вы, вероятно, должны попробовать что-то другое.
Если вы работаете с сайтом, который все еще находится в производстве, вы можете позволить себе внести небольшие инкрементные изменения на свой локальный сайт, а затем повторить на живом сайте и загрузить новую версию базы данных, когда ваши изменения будут на месте. Это означает, что вы дважды обрабатываете базу данных, но можете быть безопасным способом делать что-то. Он держит вашу базу данных ближе друг к другу и минимизирует риск.
Вы также можете экспортировать резервные копии видов на свой сервер в своем коде или импортировать их на свой сайт. Существует взлома, чтобы обойти развертывание изменений cck здесь: http://www.tinpixel.com/node/53 работает нормально, но не может действительно управлять изменениями, такими как откаты. (Уважение к парню, который написал это)
Вы также можете использовать hook_updateN для захвата изменений, а затем запустить update.php для их применения. Я работал на сайте d5 с десятками разработчиков, и это был единственный способ удержать дело. Это может быть хорошим вариантом, если ваш сайт активен или вам нужны все изменения схемы базы данных, зафиксированные в системе управления версиями (чтобы вы могли откатить).
Также: взгляните на drush и drush make. Эти инструменты могут принести большую пользу. Я не помню, сколько поддержки для d5.
Один из последних способов борьбы с этим - не использовать cck или представления (и использовать обновления крюка). Но это действительно подходит только для корпоративных сайтов, где у вас есть большие ресурсы для разработчиков. Это может показаться странным предложением, но оно может полностью отрицать всю эту проблему.
Извините, я не мог дать вам четкого ответа. Это потому, что его еще нет. В конце концов вы обретете свой собственный ритм, как только сможете. Просто сохраняйте резервные копии своей базы данных, если вы можете легко вернуться к ним.