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

Question

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

Вот наша текущая настройка:

• 2 веб-серверов
• 1 сервер базы данных
• 1 тестовый сервер

Текущая адаптация развертывания

1. Мы разрабатываем и работаем на тестовом сервере, каждое изменение загружается вручную на тестовый сервер.
2. Когда изменение или функция завершена, мы затем совершаем изменения в репозиторий SVN.
3. После совершения изменений мы затем загружаем наши изменения в первый веб-сервер, где будет каждая минута Cronjob, чтобы синхронизировать файлы между серверами.

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

Кроме того, поскольку на 1-м веб-сервере есть файлы, которые необходимо синхронизировать с другими серверами, поэтому Cronjob был там по причине.

P / S: Мне жаль, что забыл упомянуть, что сервер SVN размещен. У нас не слишком много контроля над этим, но я верю, что могу редактировать крючки ...

Answer 1

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

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

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

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

Answer 2

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

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

Каждый веб-сервер работает независимо, поэтому они не знали друг о друге - это было оставлено на балансировке нагрузки. У каждого сервера был Cronjob, который пробежал каждые 3 часа и экспортируется Последняя версия каждого сайта live Ветвь в правильную папку на файловой системе.

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

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

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

Answer 3

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