Какое лучшее решение для поддержания резервного копирования и контроля версий на действующих веб-сайтах?
-
09-06-2019 - |
Вопрос
Какое лучшее решение для поддержания резервного копирования и контроля версий на действующих веб-сайтах?
В рамках своей работы я работаю с несколькими живыми веб-сайтами.Нам нужен эффективный способ сохранения резервных копий действующих папок с течением времени.Кроме того, обновление этих сайтов может быть болезненным, особенно если по какой-либо причине происходят изменения в живой среде.
Идеальным вариантом было бы беспроблемное управление версиями.Некоторое время я внедрял SVN, который был великолепен как полурешение для резервного копирования, а также для контроля версий (простой возврат временных или критических изменений) и т.д.
К сожалению, SVN размещает .Повсюду скрытые каталоги SVN, которые вызывают проблемы, особенно когда другие разработчики вносят изменения в структуру папок или копируют / перемещают каталоги веб-сайтов.Я слышал аргументы о том, что это вопрос образования и так далее.но подход, используемый SVN, просто не является для нас практическим решением.
Я думаю, что, возможно, инкрементное решение для резервного копирования может быть лучше.
Другие возможности включают в себя:
- SVK, который доступен только из командной строки, что становится проблемой.Кроме того, я не уверен, насколько это было бы уместно.
Переменчивый, возможно, с некоторыми триггерами для скрытия распределенного компонента, который в данном случае не требуется и был бы излишне сложным для других разработчиков.
Я немного поэкспериментировал с Mercurial, но не смог найти хорошего способа отделить репозиторий и постоянно синхронизировать его с рабочей копией live folder.Возможно, в качестве решения для управления версиями (делающего репозиторий и оперативную папку в одном месте) в сочетании с другим решением для резервного копирования это могло бы быть правильным решением.
Одним из недостатков Mercurial является то, что он не помещает пустые папки под управление версиями, что проблематично для веб-сайтов, которые часто имеют пустые папки в качестве мест заполнения для загрузки файлов и т.д.
- Rsync, который я на самом деле не исследовал.
Я был бы очень признателен за ваш совет о наилучшем способе создания резервных копий действующих веб-сайтов, в идеале с простым способом быстрого извлечения прошлых версий.
Отвечать на ответы:
@Кибби:
Дело не столько в образовании, сколько в отсутствии знакомства ни с чем, кроме VSS, и нехватке времени / усилий для изучения чего-либо еще.
Я думаю, подход xcopy / 7-zip звучит разумно, но это быстро заняло бы много места, не так ли?
Что касается системы управления версиями, я думаю, я бы хотел, чтобы система управления версиями просто говорила, что "это состояние папки сейчас, я разберусь с этим, и если я не смогу сопоставить данные, это ваша вина, я просто начну новые истории", а не буду сильно ошибаться.
@Стив М:
- Да, это более приятный способ сделать это, но для этого потребуются значительные культурные изменения.Тем не менее, мне очень нравится такой подход.
@mk:
- Хорошо, я не думал об использовании Rsync для развертывания.Загружает ли это только различия?Перезаписывать весь текущий каталог каждый раз, когда мы вносим изменения, было бы проблематично из-за простоя сайта.
Мне все еще любопытно посмотреть, есть ли какие-нибудь более традиционные варианты
Решение
Вы все еще можете использовать SVN, но вместо того, чтобы выполнять проверку в вашей живой среде, выполните экспорт, таким образом, каталоги .svn не будут созданы.Недостатком, конечно, является то, что никаких изменений кода в вашей рабочей среде произойти не может.Это хорошая вещь.
Как правило, изменения кода в производственных системах никогда не должны быть разрешены.Изменение должно быть внесено и протестировано в среде разработки / тестирования / UAT, затем, после подтверждения как OK, вы можете пометить этот код в SVN чем-то вроде RELEASE-x-x-x.Затем в операционной системе экспортируйте код с этим тегом.
Другие советы
Мы используем вариант 3.Rsync.Я написал скрипт bash для этого вместе с некоторыми дополнительными проверками, но вот основы того, что он делает.
- Создайте тег для подталкивания к жизни.
- Запустите svn export для этого тега.
- rsync жить.
До сих пор это удавалось.Нам не нужно беспокоиться о конфликтах с пользователями или заводить отдельного пользователя для запуска svn на рабочем компьютере.
Любое выбранное вами решение для управления версиями будет иметь проблемы, если люди перемещают, удаляют или добавляют файлы и не сообщают об этом системе управления версиями.Я не знаю ни одного элемента управления версиями, который мог бы решить эту проблему.
В случае, когда вы просто не можете обучить людей, работающих над проектом [1], вам, возможно, придется ограничиться ежедневными снимками.Вероятно, самым простым решением было бы что-то столь же простое, как пакетный файл с использованием xcopy на сетевом диске и, возможно, 7-zip в командной строке для сжатия его, чтобы он не занимал слишком много места.
[1] Я бы очень не поверил в это, вероятно, это просто случай, когда люди слишком упрямы и не желают учиться или выполнять "дополнительную работу".Неважно, сколько времени система управления версиями могла бы сэкономить им, когда им пришлось бы вернуться к предыдущим версиям, или 2 человека отредактировали один и тот же файл.
rsync загрузит только различия.Лично я им не пользовался, но Марк Пилигрим давным-давно писал о том, как это даже блестяще обрабатывает двоичные различия.
svn + rsync звучит как фантастическое решение.Я должен буду попробовать это в будущем.