Как вы обновляете живой, загруженный веб-сайт самым политически возможным способом?

Question

При развертывании изменений на живом веб-сайте, как вы проверяете, что система live работает правильно? Какие инструменты вы используете? Кто это делает? Вы блокируете доступ к сайту на период тестирования? Какое количество простоя допустимо?

Answer 1

Я склонен проводить все свои тесты в другой среде (не в живой!). Это позволяет мне размещать обновления на живом сайте, зная, что код должен работать нормально, и я просто проверяю работоспособность данных на реальных данных - убедитесь, что я где-то не забыл файл или что-то странное пошло не так.

Итак, правильное тестирование в тестовой или промежуточной среде, а затем просто тривиальная проверка работоспособности. Нет необходимости в простоях.

Answer 2

Много полезных советов уже.

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

Обычно там есть БД, общий для всего остального. Так что это означает время простоя для всей системы. Как вы минимизируете это?

Автоматизация . Сценарий всей процедуры развертывания. Это (особенно) включает любые изменения схемы базы данных. Это (особенно) включает любую необходимую вам миграцию данных между версиями схемы.

Контроль качества . Убедитесь, что есть тесты. Автоматические приемочные тесты (то, что пользователь видит и ожидает с точки зрения бизнес-логики / опыта). Подумайте о наличии тестовых учетных записей в производственной системе, которые вы можете написать для проверки действий только для чтения. Если вы не взаимодействуете с другими внешними системами, подумайте также о выполнении операций записи. Вам может понадобиться отфильтровать активность тестового аккаунта в определенных частях системы, особенно если они связаны с деньгами и бухгалтерским учетом. Счетчики бобов по понятным причинам расстраиваются, когда бины не совпадают.

Репетиция . Развертывание в рабочей среде, максимально идентичной производственной. Сделайте это с производственными данными и производственными данными. Вы должны почувствовать, сколько времени занимает изменение таблицы. И вам нужно проверить, что таблица изменения работает как структурно, так и со всеми внешними ключами в реальных данных.

Если у вас большие объемы данных, изменения схемы потребуют времени. Может быть, больше времени, чем вы можете позволить себе быть вниз. Одним из решений является использование поэтапной миграции данных , чтобы изменение схемы заполнялось данными «последних» или «текущих» (скажем, одного или трех месяцев) во время простоя, а также данными для оставшихся пять лет могут потекать после того, как вы снова в сети. Для конечного пользователя все выглядит хорошо, но некоторые функции не могут быть доступны в течение еще нескольких часов / дней / что угодно.

Answer 3

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

Answer 4

Если у вас есть набор серверов с балансировкой нагрузки, вы сможете перевести один за другим в автономный режим и обновить его. Нет простоя для пользователей!

Answer 5

В последнем месте, где я работал, QA проводило тестирование в среде QA. Любые серьезные проблемы должны быть устранены, проверены и проверены перед развертыванием.

После того, как сборка была сертифицирована QA, команда поддержки производства отправила код в промежуточную среду, где клиент просматривает сайт и проверяет, что все соответствует требованиям.

Фактический запуск производства происходит в нерабочее время (после 9 часов вечера, если это аварийный ночной толчок, или с 5 часов утра до 8 часов утра, если это обычно запланированный запуск).

Сайт размещен на нескольких серверах, балансировка нагрузки которых осуществляется с помощью F5 Load Balancer:

• Пара серверов снята с производства,
• код установлен, а
• выполняется краткая проверка на серверах перед возвратом серверов в пул.

Это повторяется до тех пор, пока все серверы не будут обновлены до последней версии, и сайт не будет работать все время.

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

Если новая база данных несовместима с существующим интерфейсом, у вас нет другого выбора, кроме как иметь окно времени, когда сайт не работает.

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

• Весь трафик направляется во вторую БД, и первый сервер БД извлекается.
• Первая БД обновляется и после завершения проверки возвращается в рабочий режим.
• Весь трафик направляется в первую БД, а вторая БД извлекается.
• Вторая БД обновляется и после завершения проверки возвращается в рабочий режим.
• Следующим шагом является частичное обновление, как описано выше.

Итак, подведем итог:

• При развертывании изменений на действующем веб-сайте, как вы проверяете, что действующая система работает правильно? В лучшем случае это делается постепенно.

• Какие инструменты вы используете? Ручные проверки для проверки правильности установки кода вместе с некоторыми основными автоматизированными тестами с использованием любого инструмента автоматизации. Мы использовали Selenium IDE.

• Кто это делает? Администратор БД выполняет обновления БД, техподдержка / системные администраторы загружают / извлекают серверы и устанавливает код, а служба обеспечения качества или производственная поддержка выполняет ручные тесты и / или запускает Автоматизированные тесты.

• Вы блокируете доступ к сайту на период тестирования? Если возможно, этого следует избегать любой ценой, особенно, как упоминал ранее Жиль, если это платный сайт.

• Какое время простоя допустимо? Время простоя должно быть ограничено временем, когда пользователи будут реже всего использовать сайт, и должно быть менее чем за 3 часа.
  Примечание: 3 часа очень щедро. После тренировки и репетиций, как упоминал jplindstrom, команда полностью остановит процесс и может войти и выйти иногда менее чем за час.

Надеюсь, это поможет!

Answer 6

Имейте симпатичное, обезоруживающее изображение и / или страницу резервной копии. Некоторые сайты реализуют простые игры на javascript, чтобы занять вас в ожидании обновления.

Например, проваленный кит.

-Adam

Answer 7

Ответ в том, что «это зависит». Прежде всего, о среде, в которую вы выпускаете. Это веб-сайт типа "привет, мир" на общем хосте или google.com с полмиллиона серверов? Есть ли обычно один пользователь в день или больше, как пара миллионов? Публикуете ли вы HTML / CSS / JPG или у вас большой волосатый сервер с SQL-серверами, серверами среднего уровня, распределенными кешами и т. Д.?

В целом - если вы можете позволить себе иметь отдельные среды для разработки, обеспечения качества, подготовки и производства, они есть. Если у вас есть ресурсы - создайте экосистему, чтобы вы могли собрать полный устанавливаемый пакет одним (одним) щелчком мыши. И убедитесь, что та же самая бинарная установка может быть успешно установлена ​​в DEV / QA / STAGE / PROD одним щелчком мыши ... На эту тему написано множество вещей, и вам нужно быть более конкретными с на ваш вопрос получить разумный ответ

Answer 8

ИМХО длительное время простоя (часов) приемлемо для бесплатного сайта. Если вы достаточно обучите своих пользователей, они поймут, что это необходимо. Возможно, дайте им что-нибудь, с чем можно поиграть, пока сайт не восстановится (например, флеш-игра, прямая трансляция с веб-камеры, показывающая работу команды разработчиков и т. Д.). Для веб-сайта, за который люди платят за доступ, многие люди будут тратить ваше время на жалобы, если вы будете кормить их обычными простоями. Я бы избегал простоев, таких как чума, и выкладывал обновления очень медленно и осторожно, если бы я использовал сервис, который платит пользователям.

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

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

Answer 9

Отчасти это зависит от того, обновляете ли вы базу данных. Раньше, если обновлялась БД, мы закрывали сайт на запланированный (и опубликованный) период обслуживания - обычно это были действительно нерабочие часы, когда воздействие было минимальным. Если обновление не затрагивает БД, тогда в среде с балансировкой нагрузки мы бы вынули 1 блок из микса, развернуть и протестировать. Если это было успешно, то это вошло в микс, и другая коробка (предполагая 2 коробки) была выведена и обновлена ​​/ проверена.

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

Answer 10

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

Когда вы закончите бета-тестирование и готовы к работе, вам не нужно останавливать свой сайт, просто удалите некоторые хосты из класса рабочих хостов, добавьте их в новый класс хостов, разверните там свой последний код и протестируйте должным образом. Как только вы убедитесь, что все работает нормально, постепенно перенесите весь хост на новый и укажите новый класс хоста как рабочий класс хоста. Или вы можете использовать то же самое, что использовали вначале, и вся идея этого действия заключается в том, чтобы убедиться, что вы тестируете свое развертывание на производственных блоках, где ваш сайт будет работать после развертывания, потому что проблемы развертывания страшны и их трудно отладить.