Предложение развертывания сайта PHP [закрывается]

6
задан TheOnly92 13 April 2010 в 11:40
поделиться

3 ответа

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

Поскольку Phing использует XML и PHP для настройки и управления процессом развертывания, вы можете управлять версиями этого процесса. Это дополнительное преимущество, так как после этого вы можете связать развертывание с конкретными сборками вашего приложения.

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

Также рассмотрите возможность использования сервера CI .

7
ответ дан 16 December 2019 в 21:37
поделиться

Я делал то же самое на своем последнем месте. Что у нас было:

  • репозиторий для каждого сайта
  • ветка для каждого сайта, выделенная для живого сайта (т.е. /branches/live) и тестового сайта (т.е.. /branches/testing)
  • 2 веб-сервера, которые могли общаться с SVN
  • тестовый сервер, который мог общаться с SVN
  • на всех серверах был установлен клиент командной строки SVN

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

На нашем тестовом сервере это был checkout из testing ветки для каждого сайта, и никакого cronjob. Разработчики обновляли папки всякий раз, когда хотели выложить что-то для тестирования пользователями перед запуском.

Во время разработки коммиты вносились в ствол сайта. Когда изменения были готовы к тестированию, они сливались в ветку тестирования, и проверка обновлялась вручную на тестовом сервере. Когда изменения были готовы к запуску, они сливались в ветку live, и серверы обновлялись к концу дня.

За 3 года у нас была только одна проблема, когда разработчик зафиксировал что-то неправильно и пришлось откатить сайт назад.

1
ответ дан 16 December 2019 в 21:37
поделиться

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

0
ответ дан 16 December 2019 в 21:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: