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