Обновления сайта - кто как...

Главные вкладки

Аватар пользователя kv4 kv4 5 января 2014 в 21:53

Периодически приходится решать один и тот-же вопрос - как обновить сайт на боевом сервере. Я имею ввиду не обновления ядра и/или модулей, а о обновления настроек сайта. Например: типы материалов, настройки их отображения, представления, переменные, блоки и т.п.

В общем, может кто-нибудь поделится своим опытом, расскажет как это делает сам, какие дополнительные модули использует, как синхронизирует версии БД с версиями кода.

Я использую модуль Features для переноса настроек (однако он не на 100% решает задачи переноса настроек) + то, что Features не может переносить, прописываю в модуле созданном Features вручную. БД храню в git вместе с кодом. Перед каждой фиксацией изменений соответственно делается дамп базы.

План обновлений примерно такой:
1. Разворачиваю на локальной машине копию рабочего сайта. Обычно это ответвление от основной ветки в git.
2. Делаю необходимые изменения.
3. Создаю/пересоздаю "особенность".
4. Создаю на локальной машине ещё одну копию рабочего сайта и устанавливаю на ней особенность.
5. Если всё в порядке на предыдущем шаге, создаю на удалённом тестовом сервере копию рабочего сайта и устанавливаю на ней особенность. (тут конфигурация сервера максимально возможно приближена к боевому серверу)
6. Заказчик гоняет какое-то время тестовый сайт, ловим ошибки, исправляем.
7. Накатываю обновления на боевой сервер (тут как бы ни старался, не всегда всё проходит гладко).

Проблема появляется тогда, когда заказчику вот прямо сейчас нужно поменять какую-нибудь мелочь на рабочем сайте. Например поменять местами поля в форме редактирования материала. В этом случае, запускать весь процесс оказывается слишком долгим мероприятием, и приходится делать это в админке. Потом ломать голову, как же всё это фиксировать, обновлять и держать под контролем. (Зачеркнул, потому что оказалось это сбивает с толку. Основной посыл выделил жирным.)

Комментарии

Аватар пользователя kv4 kv4 5 января 2014 в 22:09

"RxB" wrote:
т.е. drush fu для вас неподъёмная задача?

Хм, я как-то невнятно/непонятно видимо написал. Но, нет drush fu не неподъёмная задача...

Хотелось узнать, как у других проходит процесс публикации обновлений.

Аватар пользователя adubovskoy adubovskoy 5 января 2014 в 23:01

"kv4" wrote:
Хм, я как-то невнятно/непонятно видимо написал. Но, нет drush fu не неподъёмная задача...

Нормально написали. Вопрос очень проблемный, готового красивого решения нет.

"kv4" wrote:
Проблема появляется тогда, когда заказчику вот прямо сейчас нужно поменять какую-нибудь мелочь на рабочем сайте. Например поменять местами поля в форме редактирования материала. В этом случае, запускать весь процесс оказывается слишком долгим мероприятием, и приходится делать это в админке. Потом ломать голову, как же всё это фиксировать, обновлять и держать под контролем.

Вопрос подхода. Если регламентировано что "все идет через тестовый сервер", такого быть не должно.

Есть надежда, что с приходом Drupal8 и его конфигурациями, вопрос деплоя значительно упростится. На данный момент красиво и оптимально по времени не делает никто. Нет на рынке удобного решения. У вас описан хороший процесс, в чем-то даже избыточен. Например тестить в боевом окружении можно локально в виртуалке - почитайте про vagrantup.com, drupal.org/project/vdd . Делается на базе вашего боевого сервера img+vagrant конфигурация, на ней можно локально быстро проводить обкатку/отладку.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 6 января 2014 в 0:12

"adubovskoy" wrote:
Нормально написали. Вопрос очень проблемный, готового красивого решения нет.

Саш, ты же сам прекрасно знаешь, что если брать вопрос деплоя в общем случае - то у каждого свои приколы и велосипеды.
Но смена порядка полей, добавление нескольких и т.п. сразу на продакшене - вполне укладываются в переупаковку фичи на продакшене и хотфикс вливаемый в dev и production ветку в гите, если он используется.