php, загруженные пользователем файлы, контроль версий и развертывание веб-сайта

Question

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

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

PHP пока не имеет встроенной функциональности svn, поэтому я не мог сделать много программно для загруженных пользователем файлов. Мое решение состояло в том, чтобы создать дополнительный веб-сайт files.website.com, который расположен в параллельном каталоге для обслуживаемого веб-сайта и обслуживается из каталога, который находится под контролем версий. Таким образом, они не стираются, когда я обновляю сайт. Время от времени я вручную добавляю загруженные файлы в проект svn, удаляю удаленные пользователем и фиксирую новую версию. Я работаю над сценарием оболочки для запуска из cron, чтобы сделать это, но это не моя сильная сторона, поэтому он стоит на заднем плане, так как это не является насущной необходимостью.

Есть ли лучший способ сделать это?

Answer 1

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

Answer 2

Я обычно не сохраняю сгенерированные пользователем данные / файл в svn. только код, схема БД / данные испытаний. Что я обычно делаю для развертывания - это rsync из современной рабочей копии, исключая каталоги для загрузки и каталоги .svn. Содержимое IMO должно обрабатываться более традиционными механизмами резервного копирования файловой системы / базы данных, а не контролем версий.

EDIT:

Просто чтобы прояснить, ваша стратегия символических ссылок кажется хорошей практикой. Вы просто упустили резервную часть, как он думает. Я бы, вероятно, просто tar | gzip загрузил материал в задании cron вместо того, чтобы взаимодействовать с SVN. И затем, вероятно, есть отдельный, который будет использовать mysqldump для выгрузки БД и gzip, что также.

Answer 3

Вместо того, чтобы вручную выполнять экспорт и управлять символическими ссылками, вы можете сделать каталог развертывания извлечением из Subversion (из производственной ветви). Таким образом, развертывание так же просто, как проверка ваших обновлений в производственной ветке.

Это работает, если у вас есть достаточный контроль над сервером Subversion и настройкой хостинга, а хранилище Subversion "готово к работе". В этой ситуации ваш пользовательский каталог может быть пустым заполнителем в Subversion и будет оставлен в покое процессом обновления, который выполняется при фиксации (как обычно для svn update). Я бы по-прежнему рекомендовал (как упоминали @ Flash84x и @prodigitalson) отдельный процесс для резервного копирования пользовательского контента.

Есть статья Ars Technica с описанием того, как это настроить.

Обновление : если вы следуете такому подходу, убедитесь, что ваш веб-сервер не разрешает доступ к файлам .svn при проверке развертывания.