Когда вы развертываете изменения в реальном веб-сайте, как вы собираетесь проверять правильность работы живой системы? Какие инструменты вы используете? Кто это делает? Блокируете ли вы доступ к сайту в течение периода тестирования? Какое количество времени простоя приемлемо?
Я стараюсь выполнять все свои тесты в другой среде (не вживую!). Это позволяет мне нажимать обновления на сайт, зная, что код должен работать нормально, и я просто проверяю работоспособность на живых данных - убедитесь, что я где-то не забыл файл, или что-то странное пошло не так.
Итак, надлежащее тестирование в тестовой или промежуточной среде, а затем просто тривиальная проверка работоспособности. Нет необходимости в простоях.
Уже много хорошего совета.
Как уже упоминалось, если у вас нет единственной точки, просто просто изменить фазы при обновлении сервера приложений за раз. Но это редко случается, поэтому пусть игнорирует это и фокусируется на сложных битах.
Обычно там есть db, который является общим для всего остального. Таким образом, это означает время простоя для всей системы. Как вы минимизируете это?
Автоматизация. Script вся процедура развертывания. Это (особенно) включает в себя любые изменения схемы базы данных. Это (особенно) включает любую миграцию данных, которая требуется между версиями схемы.
Контроль качества. Убедитесь, что есть тесты. Автоматизированные приемочные испытания (то, что пользователь видит и ожидает от бизнес-логики/опыта). Подумайте о наличии тестовых учетных записей в производственной системе, которые вы можете Script для проверки активности в режиме readonly. Если вы не взаимодействуете с другими внешними системами, подумайте о том, как делать записи. Возможно, вам придется отфильтровать активность тестового аккаунта в определенных частях системы, особенно если они имеют дело с деньгами и учебой. Bean счетчики расстраиваются по уважительным причинам, когда beans не совпадают.
репетиции. Развертывание в промежуточной среде, максимально возможной для производства. Делайте это с объемами производственных данных и производственными данными. Вам нужно почувствовать, сколько времени занимает таблица alter. И вам нужно проверить, что таблица alter работает как структурно, так и со всеми внешними ключами в фактических данных.
Если у вас массивные объемы данных, изменения схемы потребуют времени. Может быть, больше времени, чем вы можете себе позволить. Одним из решений является использование поэтапных миграций данных, так что изменение схемы заполняется данными "последние" или "текущие" (пусть говорят, один или три месяца) во время простоя, а данные для оставшиеся пять лет могут просочиться после того, как вы снова в сети. Для конечных пользователей все выглядит нормально, но некоторые функции недоступны еще пару часов/дней/независимо.
На работе мы проводим период времени с кодом, замороженным в тестовой среде. Затем, после нескольких недель уведомления, мы забираем сайт в полночь в пятницу вечером, работаем ночью, развертывая и проверяя, и выставляем его в субботу поздним утром. Статистика трафика показала нам, что это лучший период времени для этого.
Если у вас есть набор балансированных по нагрузке серверов, вы сможете отдельно отбирать отдельно и обновлять его. Нет простоя для пользователей!
У вас есть симпатичная, снятая с охраны изображение и/или страница резервного копирования. На некоторых сайтах реализованы простые javascript-игры, чтобы вы были заняты во время ожидания обновления.
Например, сбой кита.
-Adam
В последнем месте, где я работал, QA проведет тестирование в среде QA. Любые серьезные проблемы будут исправлены, протестированы и проверены до выкатывания.
После того, как сборка была сертифицирована QA, команда поддержки производства переместила код в среду Staging, где клиент просматривает сайт и проверяет, что все по желанию.
Фактический производственный свиток происходит в нерабочее время (после 9 часов вечера, если это аварийный ночной толчок или с 5 до 8 часов, если это нормально запланированный свиток).
Сайт размещен на нескольких серверах, которые сбалансированы по нагрузке с помощью F5 Load Balancer:
Это повторяется до тех пор, пока все серверы не будут обновлены до последнего кода и не позволят сайту оставаться в курсе все время.
Этот процесс является идеальным, но есть случаи, когда необходимо обновить базу данных. Если это так, то есть два варианта, в зависимости от того, будет ли новая база данных разбивать сайт или нет.
Если новая база данных несовместима с существующим интерфейсом, у вас нет реального выбора, кроме как иметь время, когда сайт не работает.
Но если новая база данных совместима с существующим интерфейсом, вы все равно можете вывести код без какого-либо фактического времени простоя, но для этого требуется наличие двух серверов производственной базы данных.
Итак, суммируем:
Когда вы развертываете изменения в реальном веб-сайте, как вы собираетесь проверять правильность работы живой системы? В лучшем случае это выполняется постепенно.
Какие инструменты вы используете? Ручные проверки для проверки правильности кода установлены вместе с некоторыми базовыми автоматическими тестами с использованием любого инструмента автоматизации. Мы использовали Selenium IDE.
Кто это делает? DBA выполняет обновления БД, Техническая поддержка/Системные администраторы нажимают/вытягивают серверы и устанавливают код, а поддержка QA или Production выполняет ручные тесты и/или работает Автоматизированные тесты.
Блокируете ли вы доступ к сайту в течение периода тестирования? Если это возможно, этого следует избегать любой ценой, особенно, как упоминал ранее Жиль, если это платный сайт.
Какое количество времени простоя приемлемо? Время простоя должно быть ограничено временем, когда пользователи будут наименее вероятно использовать сайт и должны выполняться менее чем за 3 часа.
> Примечание: 3 часа очень щедры. После практики и репетиций, как упоминалось в jplindstrom, у команды будет весь процесс вниз, и он может попасть и выходить менее чем за час.
Надеюсь, это поможет!
Некоторые из них зависят от того, обновляете ли вы базу данных. Раньше, если БД обновлялось, мы сбивали сайт на запланированный (и опубликованный) период обслуживания - обычно что-то действительно нерабочее, когда воздействие было минимальным. Если обновление не связано с БД, тогда в среде с балансировкой нагрузки мы выберем 1 пакет из состава, развернем и протестируем. Если это было успешным, он попал в микс, и другой ящик (при условии 2 коробки) был выведен и обновлен/протестирован.
Примечание. Мы НЕ тестируем код, просто развертывание прошло гладко, поэтому время простоя было минимальным. Как уже упоминалось, код должен был пройти тестирование в другой среде.
Длительность простоя IMHO (часы) приемлемы для бесплатного сайта. Если вы хорошо обучите своих пользователей, они поймут, что это необходимость. Может быть, дать им что-то поиграть до тех пор, пока сайт не вернется (например, флеш-игра, прямая трансляция веб-камеры, показывающая команду разработчиков на работе и т.д.). Для веб-сайта, который люди платят за доступ, многие люди будут тратить ваше время на жалобы, если вы кормите их регулярным временем простоя. Я бы избегал простоев, таких как чума, и обновлял обновления очень медленно и осторожно, если бы выполнял сервис, который взимает с пользователей.
В моей текущей настройке у меня есть вторичный веб-сайт, подключенный к той же базе данных и кешу, что и живая копия для проверки моих изменений.
У меня также есть несколько скриптов для просмотра страниц, работающих на заданиях cron, которые используют регулярные выражения для проверки правильности отображения ключевых страниц.
Ответ заключается в том, что "это зависит". Прежде всего, о той среде, которую вы выпускаете. Является ли это сайтом типа "привет, мир" на общем хосте или где-то на google.com с серверами на полмилла? Есть ли обычно один пользователь в день, или больше, как пара миллионов? Вы публикуете HTML/CSS/JPG или есть большой волосатый backend с SQL-серверами, серверами среднего уровня, распределенными кэшами и т.д.?
В целом - если вы можете позволить себе иметь отдельные среды для разработки, QA, постановки и производства, у них есть. Если у вас есть ресурсы - создайте экосистему, чтобы вы могли создать полный устанавливаемый пакет с 1 (одним) кликом. И убедитесь, что бинарная установка с той же самой может быть успешно установлена в DEV/QA/STAGE/PROD с помощью еще одного щелчка... Там тонна вещей написана на эту тему, и вам нужно быть более конкретным с вашим вопросом, чтобы получить разумный ответ
Запустите основной сервер на другом порту, отличном от 80. Прикрепите к порту 80 (например, nginx) легкий сервер (например, nginx). При обновлении сайта запустите другой экземпляр нового порта. Контрольная работа. Когда вы удовлетворены тем, что он был развернут правильно, отредактируйте файл конфигурации прокси и перезапустите его. В случае nginx это приводит к нулю простоям или неудачным запросам, а также может обеспечивать повышение производительности по сравнению с более типичным вариантом хостинга Apache.
Конечно, это не подменяет надлежащий сервер промежуточного уровня, это всего лишь "вежливый" способ выполнения передачи обслуживания с ограниченными ресурсами.
Проверить все, что возможно, на отдельный сайт dev перед тем, как идти вживую, я использую Selenium (тестер веб-страницы), чтобы пройти через все навигационные части сайта, заполнять фиктивные значения в формах, проверять что эти значения появляются в нужных местах в результате и т.д.
Он достаточно мощный, чтобы проверить много javascript или динамический материал тоже.
Затем быстрый переход с селеном снова после обновление сайта в реальном времени подтверждает, что обновление и что отсутствуют недостающие ссылки или ошибки базы данных.
Он несколько раз спас меня, поймав тонкие ошибки, которые Я бы пропустил просто ручное перелистывание.
Кроме того, если вы поместили живой сайт за какой-то "обратный прокси", или балансировщик нагрузки (если он большой), что позволяет легко переключаться вернуться к предыдущей версии, если есть проблемы.
Единственный способ сделать его прозрачным для ваших пользователей - это поставить его под балансированный нагрузкой прокси. Вы удаляете один сервер при обновлении другого сервера. Затем, когда вы сделаете обновление, вы добавите тот, который вы обновили онлайн, и отпустите другой. Как мы это делаем.
Если у вас есть какая-то "бета-версия", не перекачивайте ее на реальном сервере. Если у вас есть "живой, занятый сайт", вероятность того, что люди будут бить на нем и что-то сломать.
Это типичная установка высокой доступности, для поддержания высокой доступности вам потребуется минимум 3 сервера. 2 живых и 1 тестовый сервер. Кроме того, любые дополнительные серверы, если вы хотите иметь выделенный DB или что-то еще.
Создайте класс хоста и разверните свой веб-сайт в этом хост-классе. По классу хоста я имею в виду набор хостов, на которых настраивается балансировка нагрузки, и его легко добавлять и удалять хосты из класса.
Когда вы закончите с бета-тестированием и готовы к производству, вам не нужно забирать ваш сайт, просто удалите хост из производственного хост-класса, добавьте его в новый класс хоста и разверните свой последний код и проверьте его правильно. Как только вы убедитесь, что все работает, полностью переместите весь ваш хост на новый и укажите новый класс хоста в качестве класса хоста. Или вы можете использовать то же, что вы использовали на начальном этапе, вся идея этой деятельности - убедиться, что вы тестируете свое развертывание в продуктовых ящиках, где ваш сайт будет запущен после развертывания, поскольку проблемы с развертыванием страшны и трудно отлаживаются.