Помогаю с большим игровым сайтом в Австралии. Мы проводим соревнования с 7 утра по местному времени до 1 часа ночи следующего дня, каждый день недели. Мы не пропустили ни дня с момента релиза сайта. Естественно, это делает обслуживание чрезвычайно сложным для выполнения, и мы обнаруживаем, что наш промежуточный сервер на 50 коммитов опережает нашу производственную ветвь. Обычно основной разработчик должен проснуться очень рано, чтобы объединить ветки и убедиться, что все работает правильно.
Мы пытались сделать наш промежуточный сайт как можно более похожим на производственный, но мы можем только сделать его таким похожим.
Наш сайт основан на Laravel с сервером Node.JS для работы в реальном времени. Мы используем Laravel Forge.
Есть ли у кого-нибудь предложения о том, как можно чаще отправлять обновления? Мы открыты для всего.
Вы можете многое сделать, чтобы улучшить процесс развертывания. Некоторые из них:
Убедитесь, что ваш код хорошо протестирован.
В идеале у вас должно быть 100% покрытие модульным тестированием, а также интеграционное тестирование для всех мыслимых сценариев.
Если у вас этого нет, вам, вероятно, следует все бросить и позаботиться об этом.
Изучите разработку, основанную на поведении.
Наличие полного набора тестов позволит вам ...
Запустите непрерывную интеграцию.
Всякий раз, когда кто-то фиксирует изменение, CI может автоматически запустите на нем набор тестов. Если набор тестов проходит успешно, его можно развернуть немедленно (или запланировать развертывание). Для изменений, которые не требуют каких-либо значительных изменений в ваших базах данных, одно это сэкономит вам много времени и избавит от головной боли.
В случае возникновения проблемы CI также может выполнить откат в один клик.
CI - это много менее полезно, если ваш набор тестов не является полным и правильным, поскольку вся предпосылка основана на возможности проверки вашего кода автоматизированным способом.
Делайте атомарные обновления.
В идеале вы не должны просто копировать новые файлы поверх старых на производственном сервере. Вместо этого используйте такой инструмент, как capistrano, который копирует каждый файл в новое место, а затем использует символическую ссылку, чтобы указать на желаемое развертывание. Откат происходит мгновенно, поскольку он включает в себя простое изменение символической ссылки, указывающей на предыдущее развертывание. (Хотя это не обязательно касается миграции вашей базы данных.)
Также посмотрите, могут ли вам помочь такие контейнеры, как Docker.
Вносите меньшие, более частые изменения.
Независимо от того, есть ли у вас тесты, CI или ничего, одно это может вам значительно помочь. У каждого изменения должна быть собственная ветка git, а в развертывании должно быть как можно меньше изменений. Поскольку изменений меньше, вероятность ошибок во время развертывания меньше.
В этой связи, по возможности, делайте изменения более изолированными. Если вы внесли изменения в Омаху, и они не повлияли на техасский холдем, пятикарточный стад или что-либо еще, то это единственная игра, которая должна быть приостановлена на техническое обслуживание.
Анализируйте что-нибудь долгое.
Вы упомянули, что некоторые части вашего развертывания занимают много времени. Это наверное изменения схемы базы данных. Стоит, чтобы администратор баз данных изучал вашу базу данных вместе с каждым изменением схемы, чтобы увидеть, что может работать лучше.
Попросите профильного специалиста взглянуть на любую другую часть развертывания, которая занимает много времени.
Работа в нерабочие часы.
Возможно, вы уже делаете это, но об этом стоит упомянуть. От разработчиков (и системных администраторов!) Больше не следует ожидать, что они будут работать «с 9 до 5», особенно для круглосуточной работы. Если предполагается, что кто-то будет проводить ночные часы, присматривая за развертыванием, устраняя любые проблемы, а затем придерживаясь дневного графика, ваши ожидания нереалистичны, и вы настраиваете этого человека на выгорание.
Судя по тому, что вы говорите, у вас есть окно обслуживания с 1 до 7 каждый день, проблема не во времени, а в удобстве. Это нормально, и многие люди занимаются этим просто как бизнес.
У вас может быть 2 (или более серверных) системы с интерфейсом, который направляет трафик в то место, которое в настоящее время существует. Убедившись, что релиз работает, вы говорите клиентской части переключиться на новую систему. это должно быть легко написать сценарий и занять короткое время.
Теперь у вас есть выбор либо оставить старую систему как есть, чтобы вы могли вернуться, либо обновить ее, чтобы ее можно было использовать в качестве запасной для действующей системы, пока не придет время создавать / тестировать следующие обновления.
Внесение изменений в другие ответы: вы должны следовать сине-зеленая модель развертывания. Когда вы хотите выпустить новую версию, вы развертываете ее на внутреннем промежуточном веб-сайте. Затем вы можете запустить автоматизированные тесты на производственном сайте следующей версии. Когда тесты пройдут, вы указываете балансировщику нагрузки использовать новый веб-сайт.
Это помогает следующим образом:
Все другие проблемы, о которых вы и другие упомянули, становятся менее серьезными, если вы можете развернуть их в любое время без напряжения. Сине-зеленая модель развертывания - вполне полное решение проблем развертывания.
Что вы будете делать, если в вашем основном центре обработки данных произойдет сбой, который время от времени случается во всех центрах обработки данных? Вы можете согласиться с простоями, вы можете переключиться на другой центр обработки данных, вы можете работать в активном-активном режиме в нескольких центрах обработки данных все время или у вас может быть другой план. Какой бы из них ни был, сделайте это при выпуске релизов, а затем вы можете отключить свой главный центр обработки данных во время выпуска. Если вы готовы к простоям из-за сбоя в вашем центре обработки данных, значит, вы готовы к простоям, поэтому во время выпуска это не должно быть проблемой.
Чтобы добавить к предыдущим ответам:
Используйте стратегию развертывания, которая допускает откаты и мгновенное переключение, Capistrano или практически любая другая система развертывания поможет в этом. Вы можете использовать такие вещи, как снимки базы данных и символические ссылки кода, чтобы иметь возможность быстро вернуться к предыдущему состоянию.
Используйте полное управление конфигурацией, не оставляйте ничего управляемого вручную. Такие системы, как SaltStack, Ansible и Puppet, являются примерами. Их также можно применять к конфигурациям контейнеров Docker и бродячим ящикам.
Используйте HA, чтобы убедиться, что вы можете передавать запросы при обновлении узла. Если обновление не удалось, просто отключите узел, а когда он откатится, верните его обратно, и ваше решение высокой доступности заметит и снова отправит запросы на указанный узел. Примером может служить HAProxy, но nginx тоже работает нормально.
Убедитесь, что приложение может обрабатывать параллельные экземпляры, использовать центральные репозитории с версионными данными для некодированных данных, которые необходимо хранить на диске, таких как кеш. Таким образом, вы никогда не будете запускать обновленное приложение для кэширования файлов из другой версии. Конечно, это будет происходить поверх очистки кешей и прогрева кешей. (Кеширование - это просто пример)
Я обычно настраиваю рабочие процессы, в которых менеджеры команд могут утверждать запросы на слияние в специальную ветку, которая выполняет все обычные функции CI, но в качестве дополнительного последнего шага также начинается отправка на рабочие узлы. По сути, вы выполняете развертывание CI вручную в производственном экземпляре. Если этот экземпляр не генерирует недействительные ответы, не ломается или не делает странные вещи с вашими данными, вы затем массово обновляете все узлы, используя ваше решение CI по выбору. Таким образом, если одно развертывание работает, вы знаете, что все развертывания будут работать для определенного тега / фиксации.
Прямо сейчас это звучит так, как будто вы запускаете производственное приложение на одном узле с одним процессом развертывания, одним источником и одной целью. Практически это означает, что каждый шаг в этом рабочем процессе является точкой отказа, которая сама по себе может сломать веб-сайт. Обеспечение того, чтобы этого не могло произойти, является основой всех процессов CI, HA и аварийного переключения. Не запускайте только один узел, не запускайте только один процесс высокой доступности, не запускайте только один IP-адрес, не запускайте только один CDN и т. Д. Это может показаться дорогим, но размещение дубликата того, что у вас уже есть в стойке на сервере с собственным подключением обычно стоит меньше часа простоя на бизнес-сайте.
Я полностью согласен с Майклом по всем его пунктам (https://serverfault.com/a/739449/309477).
На мой взгляд, первое улучшение, которое вы должны сделать, - это использовать инструмент развертывания (Capistrano).
Это позволит вам спокойно выполнить развертывание, а затем мгновенно переключиться на более новую версию. Если что-то пойдет не так, вы можете мгновенно переключиться обратно на рабочую версию, просто изменив текущую символическую ссылку на рабочую версию.
И Capistrano довольно быстро запускается в первый раз (по сравнению с началом использования тестов и CI, что потребует больших временных затрат).
Во-вторых, если деньги не твои основной проблема, у вас должен быть сервер разработки iso-prod для тестирования вашего приложения перед его развертыванием в производственной среде. Используйте промышленный решение (Ansible, Chef, Puppet) для управления экземплярами VPS.