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

Question

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

Answer 1

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

Если у вас есть какая-либо «бета» сборка, не разворачивайте ее на работающем сервере. Если у вас есть «живой, занятый сайт», есть вероятность, что люди собираются на него взломать и что-нибудь сломать. *

Это типичная настройка высокой доступности, для поддержания высокой доступности вам потребуется минимум 3 сервера. 2 живых и 1 тестовый сервер. Плюс любые другие дополнительные серверы, если вы хотите иметь выделенную БД или что-то еще.

Answer 2

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

Это достаточно мощный, чтобы проверить много JavaScript или динамические вещи тоже.

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

Это спасло меня несколько раз, ловя тонкие ошибки, которые Я бы пропустил только ручное перелистывание.

Кроме того, если вы поместите живой сайт за своего рода «обратный прокси» или балансировщик нагрузки (если он большой), что облегчает переключение вернуться к предыдущей версии, если есть проблемы.

Answer 3

Запустите основной сервер на порту, отличном от 80. Вставьте облегченный сервер (например, nginx) перед ним на порт 80. Когда вы обновляете свой сайт, запустите другой экземпляр на новом порту. Тестовое задание. Когда вы убедитесь, что он был правильно развернут, отредактируйте файл конфигурации прокси и перезапустите его. В случае nginx это приводит к нулевому времени простоя или неудачным запросам, а также может обеспечить повышение производительности по сравнению с более типичным вариантом хостинга только для Apache.

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