Как вновить изменения в сайт не выключая его на обслуживание?

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

Аватар пользователя misterpronin misterpronin 12 июля 2014 в 15:12

Кто-нибудь сталкивался с подобной надобностью? Как решили этот вопрос? Что предприняли? Допустим у меня есть социальная сеть, которая дорабатывается чуть ли не каждый день. Хочется чтоб изменения "просто появлялись" на рабочем сайте, не лишая людей возможности им пользоваться.

Комментарии

Аватар пользователя mbaev mbaev 12 июля 2014 в 16:53

У нас сейчас ведутся митинги по такой задаче. Пока остановились на том, чтобы переводить сайт, во время наката апдейтов, в read-only режим. Возможно, в скором времени будем проводить харднинг.

Аватар пользователя fun.boojum fun.boojum 12 июля 2014 в 20:16

Как другой вариант, посмотреть на это решение, портированное из восьмерки: https://www.drupal.org/project/configuration.
Но решение сырое, на "живом" сайте не пробовал, надо проверять.
Толковый деплой - не сильная сторона друпала, по крайней мере седьмого... Это мое мнение.

Аватар пользователя orb orb 12 июля 2014 в 20:19

"misterpronin" wrote:
Допустим у меня есть социальная сеть, которая дорабатывается чуть ли не каждый день

"misterpronin" wrote:
Хочется чтоб изменения "просто появлялись" на рабочем сайте, не лишая людей возможности им пользоваться.

У серьезных проектов нету такого что прямо "каждый день" и прямо срочно внедрить Smile
Обычно изменения копятся, пока их делают и тестят на тестовых серверах, потом например раз в неделю скопом выкладывают кучу изменений.

А если у вас, "что-то" делают по мелочи, то чаще всего это залил на сервер и сбросил кеш стилей и опа, рюшики поменяли свой цвет!

Аватар пользователя Moel Moel 12 июля 2014 в 20:49

Тут зависит что за изменения. Если вы ядро переписываете потихоньку это одно, а если рюшечки или модульки простенькие то это другой. Но в случае с модульком и т.д. в лом случае не там запятая и сайт не грузится. Поэтому как выше сказали если сайт серьезный все тестится сначала не на рабочем сайте.

Аватар пользователя misterpronin misterpronin 12 июля 2014 в 23:46

Про то, что всё нужно тестить на нерабочем сайте это понятно. А про изменения каждый день - эт я к примеру сказал.

Ситуация, грубо говоря, будет такая, как я понял - на тестовом сервере устанавливается набор новых модулей, которые предполагается использовать в дальнейшем. Эти модули настраиваются и тестируются на работоспособность с другими модулями, темизируется вывод (ну это понятное дело самое лёгкое для переноса на рабочий сервер)... и когда становится понятно, что всё работает хорошо, рабочий сайт, как говорили выше, либо переключается в режим read-only, либо вообще переходит в режим разработки. Далее с рабочим сайтом нужно будет проделать всё, что было сделано на тестовом - т.е. заново установить и настроить все протестированные модули и пр...

Вопрос в том, есть ли какие-нибудь способы упростить этот процесс? Какие-нибудь вспомогательные программы, модули, приёмы...

Аватар пользователя misterpronin misterpronin 13 июля 2014 в 9:20

Да, я использую drush. Он значительно упрощает установку модулей, но не переносит настройки. И тут я вспомнил про features )) , который своеобразным способом переносит настройки. Вот о feauters я много слышал, но никогда не использовал. Вроде оно... то, что вместе с drush значительно может упростить перенос! Интересно удобно ли его использовать? Кто-нибудь использовал feauters? Вот здесь статья про него.

Аватар пользователя orb orb 13 июля 2014 в 9:59

Я использовал фичи, это отличная вещь, но вырубать сайт все равно нужно Smile

Представьте ситуацию, когда в момент включения модулей кто-то пишет комментарий или создает статью, а вы включаете 5 модулей связанных, которые к комментариям добавляют рюшики в базу данных. После включения первого модуля кто-то сохранит коммент и первый модуль в базу запишет свое что-то, а второй модуль еще не включился что бы тоже записать - в результате битые данные. которые будут плеваться ошибкой базы данных. А все это из-за того что админу жалко было на 20 минут сайт потушить!!!

Вон даже хабрахабра сайт тушит, только они не боятся тушить на полдня, а вы за 5-20 минут переживаете.

Аватар пользователя misterpronin misterpronin 13 июля 2014 в 10:25

Я не переживаю за 5 минут, а ищу самый идеальный из возможных вариантов. Идеальный - это конечно не выключать )) А так как features помогает значительно сократить количество времени для переноса, то, соответственно, мы будем ближе к идеалу ))

Мне интересен вопрос: если я через фичу перенёс тип материала, потом на нерабочем сайте внёс изменения в этот тип материала... при следующем переносе мне нужно будет переносить только эти изменения через отдельный "фич-модуль" или можно просто заменить весь существующий "фич-модуль" целиком на новую версию?

Аватар пользователя orb orb 13 июля 2014 в 13:18

"misterpronin" wrote:
если я через фичу перенёс тип материала, потом на нерабочем сайте внёс изменения в этот тип материала

у фич есть админка и весь козырь данного модуля в том что ты куски базы данных сохраняешь в файл, например, тип материала ты записал в модуль в код.
Когда ты в админке что-то поменял у этого типа материалов и зайдешь на страницу фич у тебя будет написано что код в файле и состояние БД не совпадают и перечень пунктов по корому они не совпадаю (поля, настройки и т.д.).
Из возможных действий есть 2 варианта:
1. пересоздать фичу и внести в код новое состояние базы данных
2. сделать возврат базы данных к тому что написано в коде

это если кратко на пальцах обьяснять