Вы здесь

Как деплоить сайт?

0

Вопрос не новый, но я не нашёл для себя удовлетворительного решения.

Есть рабочий сервер с боевым сайтом, на котором меняется информация. И девелоперский сервер, на котором делается новый функционал.

  1. Как синхронизировать два сайта между собой?

  2. С файлами можно настроить систему версий. А что делать с базой данных?

  3. Или поставил я новый модуль, оттестировал, настроил. Как перенести модуль со всеми настройками, которые он хранит в базе данных?

  4. Ещё пример. Я сделал какие-то изменения в настройках views. Как перенести?

Какие рабочие решения вы используете?

Версия Drupal: 
7.x
Вопрос задан 09.02.2016 - 09:47
Аватар пользователя shu
shu
178

Ответы

2
  1. Если речь идет о синхронизации инфраструктуры, то это можно делать либо используя provisioning tools (сложно), такие как chef, puppet, ansible, etc, или используя контейнерную виртуализацию Docker (проще, но тоже не ахти), смотрите статью на хабре как развернуть друпал с докером. Либо можно воспользоваться Wodby (проще некуда), эта платформа позволяет переносить код/бд/файлы с одной копии сайта на другую, причем эти копии могут находится на любых серверах.

  2. По-хорошему БД полностью с дева на прод переносить не надо (обратно еще можно, но надо чистить персональные данные). Настройки модулей и прочие метаданные выгружать через модуль features (для D7) или встроенный configurations manager в друпале 8, и ложить в гит. Последний я честно сказать еще не пробовал. Вот статья от луллабота (инглиш) про configurations management. Кстати, файлы под контролем версий держать не надо, их можно переносить ручками, либо через сторонние инструменты, либо есть вариант с использованием модуля stage file proxy

  3. см пред, пункт

  4. см пред, пункт
Ответ дан 09.02.2016 - 10:39

Спасибо за подробный ответ. Решил пока остановится на изучении features и Wodby

Комментарий оставлен 09.02.2016 - 12:16
2

В свое время очень много и долго экспериментировали с различными вариантами миграции настроек в базе данных с тестового сайта на "боевой". Я лично консультировался со многими умными людьми, которые съели гораздо больше собак на сложных проектах.
Ответ у всех однозначный - для Drupal 7 только features

Проблема с "фичами" в том, что их нужно очень тщательно тестировать - всегда есть шанс, что забыли указать какую-то переменную. На тестирование обычно уходит на порядок больше времени, чем на создание "фичи".
Именно поэтому Configuration management в восьмой версии стал "глотком свежего воздуха".
Есть, кстати, backport Configuration Management под "семерку", но мы его, если честно, не пробовали. Будет интересно узнать о результатах, если пойдете этим путем.

P.S. Если нужна помощь с features, пиши - поможем.

Ответ дан 10.02.2016 - 13:36
Аватар пользователя ALS
ALS
20
1

я использую для БД кастомный модуль с hook_install, ознакомьтесь http://dru.io/question/5156
API узнаю с каждой итерацией всё больше и больше

Ответ дан 09.02.2016 - 11:55

hook_update_deploy_tools всего лишь вспомогательный модуль, говоря о hook_update я имел в виду хук в .install файле своего модуля, включающий код, который пишется руками. механизм такой же, как и при обновлении ядра или contrib модулей, если они что-то делают в БД (порядковые номера)

Комментарий оставлен 09.02.2016 - 13:43

То есть по сути - это features написанная руками. Сложновато реализуемо, если много изменений на сайте.

Комментарий оставлен 09.02.2016 - 17:27

да, нетривиально. но, что будете делать, если features не поддерживает то, что необходимо задеплоить? а он далеко не всё умеет

Комментарий оставлен 11.02.2016 - 20:24
0

Не знаю, возможно ли это в случае с Drupal и деплой ли это вообще, то что я напишу. Но в Joomla я делал так:

Если нужно синхронизировать локальный и серверный сайт после установки нового модуля на локальном:

  1. Ставлю модуль на **локальный **сайт, изучаю, тестирую и настраиваю его.
  2. После того как все готово, делаю дамп базы данных **локального **сервера (с настройками модуля)
  3. Далее, на сервере, ставлю модуль тоже руками.
  4. Затем делаю дамп базы **сервера **(скачиваю к себе на компьютер).
  5. Этот **серверный **дамп накатываю (импортирую) на **локальную **базу (чтобы обновить пользовательские данные: комментарии, посты и пр.).
  6. Затем сразу после этого снова на **локальную **же базу накатываю ранее сделанный (см. п.2) **локальный **дамп с настройками нового модуля.
  7. Делаю повторный дамп **локальной **базы (уже с настройками нового модуля, постами и комментариями).
  8. Этот повторный **локальный **дамп импортируем в **серверную **базу.
    пс
    Все эти дампы и импорты делаю через десктопную программу для работы с базами данный (Navicat). Дамп базы размером в несколько десятков мегабайт делается за секунды. Коннект мгновенный и без необходимости вводить пароли (если включить запоминания). Нет необходимости прыгать по вкладкам браузера, все базы данных всех сайтов, и локальных и на сервере в одной программе перед глазами: из одной - дамп и тут же в другую - импорт. Имеется возможность делать дампы отдельных таблиц и планировщик задач. Очень удобно. По крайней мере ничего удобнее не знаю.
Ответ дан 11.02.2016 - 15:11

В принципе, если знать, в каких именно таблицах каждый модуль хранит свои настройки, то можно обновлять только эти таблицы и тогда дамп серверной базы будет не нужен, а импорт настроек пройдет гораздо быстрее и пользовательские данные не затрутся. Настройки же Views-ов тоже в таблицах лежат? Подготовили новые вьювсы на локальном сайте или изменили существующие, затем сделали дамп только нужных таблиц локальной базы и вторым шагом импортировали их на сервер. Синхронизация в два шага

Комментарий оставлен 11.02.2016 - 15:33
0

В Друпале все проще, - залили на сервер изменения кода, запустил update.php и всё готово.

Ответ дан 12.02.2016 - 10:05