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

Большой хороший совет уже.

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

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

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

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

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

, Если у Вас есть значительные объемы данных, изменения схемы займут время. Возможно, больше времени, чем Вы может позволить себе снизиться. Одно решение состоит в том, чтобы использовать поэтапные миграции данных , так, чтобы изменение схемы было заполнено с "недавним" или "текущим" (скажем, один или три месяца) данные в течение времени простоя, и данные для оставления пятью годами могут сочиться в том, после того, как Вы онлайн снова. Конечному пользователю вещи смотрят хорошо, но к некоторым функциям нельзя получить доступ еще для нескольких hours/days/whatever.

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

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

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

, Например, падение сервера.

-Adam

Часть этого зависит от того, если Вы обновляете базу данных также. В прошлом, если DB обновлялся, мы победили сайт для запланированного (и опубликовал), период обслуживания - обычно что-то действительно от часов, где влияние было минимально. Если бы обновление не включает DB затем в сбалансированной среде загрузки, мы вынули бы 1 поле из соединения, развернули бы & тест. Если это было успешно, это вошло в соединение, и другое поле (принимающий 2 поля) было произведено и обновляло/тестировало.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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