28 июля 2013 в 0:40
Сервер 1. Сервер разработки.
Сервер 2. Реальный, работающий сайт.
Пока на сервере 1 ведется разработка на сервере 2 меняются и добавляются данные.
Как передать обкатанные на сервере 1 наработки на сервер 2? Что б понятно и прозрачно, в т.ч. для клиента. Желательно как-то поддерживать версионность. Что б на сервере 2 не пропали введенные данные.
Понятно что скрипты передаются в виде файловой структуры,а как быть с данными в т.ч. и настройками?
1)модуль Futures? Еще не работал с ним. Подходит ли он для этих целей? Он генерит модули. Если удалить сервер 1 (а что его пожизненно хранить?) то сервер 2 будет частично состоять из сгенерированных Futures модулей.. Что ж тут хорошего?
2)Выгружать дампы БД? Но чем их выборочно генерить (какие таблицы включать)? Кроме таблиц с настройками, могут изменится и таблицы с данными.. Вся база не подходит, т.к. нужно сохранить внесенные на сервере 2 изменения.
3)CVS? CVS+Drush? Но разве они смогут отслеживать и передавать версионность настроек в БД? Как?
В общем я пока не вижу метода без изъянов.
А ведь для крупных проектов в такой взрослой системе как Друпал вопрос должен быть тривиальный.
P.S. Клиент будет накатывать апдейты сам. Технических знаний хватит или можно обучить.
Комментарии
https://drupal.org/node/670460
Можно описать в двух предложениях как это работает?
Совсем не так как вам хотелось бы drush rsync и drush sql-sync льют туда сюда файлы и базу соответственно не разбираясь что да как.
Погуглите на тему "drupal deploy" есть сложные схемы с использованием Apache Ant или Capistrano но слишком уж морочено получается.
Лично я использую features (features_extra,ftools,strongarm,uuid_features) + git + немного изврашенный подход к разработке. Изврашенность заключается в максимальном отказе от накликивания в админке чего бы то нибыло. Благодоря этому все изменения хранятся в git.
организовывай свою разработку.
переноси настройки дописанного из базы в код,
с обновлением или новым модулем запускаешь (проверенный на свежих снимках) .install
А как вы делаете/меняете настройки модулей, например?
Фичи буду пробовать..
?
чем?
Профиль создавать?
большая часть модулей хранит настройки в таблице variable, т.е. вполне достаточно связки features и strongarm для корректного экспорта. Если что то особенное то можно дергать hook_update_N. Вообще разработка в таком стиле требует намного большего понимания того как работает drupal из нутри.
Где дергать?
а кто мешает почитать документацию и увидеть там ,что тот же sql-sync может синхронизировать только те таблицы ,которые нужны(а точнее не заливает перечисленные таблицы)
и тоже самое в rsync можно исключить ненужные каталоги
дак никто не мещает, сам активно drush пользую, но проблемы деплоя он не решает, если контент на live сайте интенсивно обновляется и на нем проводятся мелкие изменения окружения.
Да, считаем что происходят, я писал выше.
у вас друпал другой или только у меня контентная составляющая (ноды,поля,термины etc)хранятся в отдельных таблицах?
мелкие изменения окружения вы записываете в таблицу "node"
в файле .install модуля
Какого модуля?
drupby, а как передать, например, новый словарь таксономии, на Live сервере такcономия тоже меняется.
Вообще работать на уровне таблице не Drupal way вроде.
И вопрос от того кто пока не работал с features.
Модули который он генерит нужны только ради инсталла (накатить апдейты) или для постоянной работы?
На live сайте идет постоянное обновление контента (добавляются новые ноды и термины), на dev был добавлен новый тип нод с кучей полей, из них был собран еще один раздел сайта. Как вы через sql-sync разрулите ситуацию?
типы нод хранятся в таблице "node_type"
поля в отдельных таблицах -препятствий нет
ну и таблицу с конфигурацией инстансов полей обновить
вообщем если разбираться в структуре бд друпала ,можно быстро все разрулить-а так возможно все синхронизировать
а если еще дописать алиасов на команды с перечислением необходимых таблиц ,тот все возможно и главное скорость выполнения
ps хотя в некоторых случаях можно и фичами делать
в любом случае нужно пробывать варианты и искать под себя
Ваши рассуждения очень похожи на доводы "диванного теоретика". Проблема не с тем как переносить, а с тем как разрулить конфликты nid, tid и прочих id которые непременно возникнут в указанном выше ситуации. Любое не осторожное действие приведет к потере контента, а то и вовсе к простою. Деплой мало мальски сложного проекта через drush sql-sync невозможен!
Ваши рассуждения очень похожи на доводы "диванного теоретика".
Вы собрались переносить фичами ноды и термины?
я это делаю постоянно, почему вас удивляет?
Ха, возник вопрос.
А как при таком подходе обновлять модули?
пиздец)
тебе жеже говорят - переноси все в код свой, естественно.
содержишь и обновляешь ядро и контриб, поддерживаешь свое, контроль версий (тудым-сюдым).
))
и вообще!
git push bare master с dev сервера и git pull bare master && drush updb с live
Что, бля, переносить, код обновления модулей? Вырезать кусками, вручную? Мы тут говорим об автоматизации.
Ну так расскажи как работает приведенный тобой модуль Deploy. В описании сказано что он переносит контент,и usage у него не ахти.
del
git
Где не работает голова - работают руки, можешь и вручную)
А я тебе третий раз повторю, то, что говорили люди выше - git
И епт, на модуле deploy я акцента не делал - ты сам его нашел, молодец.
А я тебе предлагал в принципе определить для себя такое понятие как deploy, и в контексте drupal посмотреть, какие методики обсуждаются сообществом.
Читать офф. инфу - это хорошая практика.
Дополнительно скажу, что развернуть среду для тестирования незнакомого модуля - дело 1мин.
Т.е. нашел, ознакомился с доками, развернул, тестишь и вникаешь.
мегаразрабы тут тусят, задам вопрос.
Модуля git нет ли под друпал????
вот неугомонный, только откинулся, и опять за старое)
скрипты на компутере есть?
да вот решил ничего не держать у себя.
ищу модуль git под друпал
Друпал.ру в своем лице. Один не очень понимающий человек спрашивате, другие не очень хотящие отвечать отвечают )
Вот что гугл ответил, самая разумная штука, это да, деплой через системы контроля версий, git например.
http://www.slideshare.net/eaton/drupal-deployment-presentation