Каковы лучшие практики для продвижения обновлений сайта из среды разработки / этапа / тестирования в производство?

Question

Сейчас у меня есть сервер разработки, работающий с базовой конфигурацией LAMP. Производственный сервер - slicehost . Но мне интересно, каков наилучший способ подтолкнуть экземпляры кода / базы данных к этапам dev> stage> production. Это связано с тем, как вы создаете сцены?

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

Я знаю, что это несколько общего, я просто смотрю в правильном направлении.

Answer 1

Я использую .htaccess для создания «режима обслуживания», где только мой IP может видеть основной сайт при обновлении. Все остальные получают возможность просмотреть короткое сообщение, чтобы они знали, что все должно быть в сети через несколько тиков.

Тогда я:

1. Вносить изменения в БД
2. SVN экспорт / загрузка файлов
3. Запустите автоматическое тестирование и по возможности быстро осмотрите, чтобы убедиться, что в этом нет ничего страшного
4. Вернуть .htaccess

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

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

Answer 2

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

Answer 3

Я бы посмотрел на какую-то автоматизированную среду в стиле «сборки» для лампы, где у вас есть сценарии, которые упаковывают и подготавливают ваши релизы для каждой среды.

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

Я не верю, что вы можете полностью устранить простои без балансировки нагрузки / сред в стиле веб-фермы. Однако самый простой способ уменьшить это в моей книге - создать согласованный процесс подготовки кода и многократно протестировать его. Автоматизация поможет там.

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

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

Answer 4

муравей apache с задачами для svn и ftp. Есть даже люди, которые делают дБ с ANT, но я склонен смотреть их лично. Как только вы получите чистую и готовую сборку для ftp во все ваши местоположения, вы удивитесь, насколько это просто.

Answer 5

У меня есть опция в конфигурации ядра, чтобы разрешить доступ к сайту или список предустановленных URL-адресов, на которые я могу перенаправить всех пользователей (и остановить любой трафик API с помощью соответствующего http-кода).

Эти URL-адреса представляют собой ссылки на статические html-файлы, объясняющие пользователю, что происходит.

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

Answer 6

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

Answer 7

Что касается отправки файлов на все веб-серверы, я обнаружил, что старый добрый robocopy делает свое дело. Мои окружения dev / stage / prod, конечно, идентичны. Просто создайте временную страницу, которая сообщает пользователям, что сайт вернется.