Какое лучшее решение для поддержания резервного копирования и контроля версий на живых сайтах?

Question

Какое лучшее решение для поддержки резервного копирования и контроля версий на живых сайтах?

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

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

К сожалению, SVN размещает скрытые каталоги .SVN везде, что вызывает проблемы, особенно когда другие разработчики вносят изменения в структуру папок или копируют / перемещают каталоги веб-сайтов. Я слышал аргумент, что это вопрос образования и т. Д., Но подход, принятый SVN, просто не является для нас практическим решением.

Я думаю, что решение для инкрементного резервного копирования может быть лучше.

Другие возможности включают в себя:

1. SVK , который является только командной строкой, которая становится проблемой. Кроме того, я не уверен, насколько это уместно.

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

   Я немного поэкспериментировал с Mercurial, но не смог найти хороший способ отделить репозиторий и постоянно синхронизировать его с рабочей копией рабочей папки. Может быть, в качестве решения для управления исходным кодом (создание хранилища и рабочей папки в одном месте) в сочетании с другим решением для резервного копирования это может быть подходящим вариантом.

   Недостатком Mercurial является то, что он не помещает пустые папки под контроль исходного кода, что проблематично для веб-сайтов, которые часто имеют пустые папки в качестве местозаполнителей для загрузки файлов и т. Д.

3. Rsync , который я на самом деле не исследовал.

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

Ответов:

• @ Кибби :

  • Речь идет не столько об образовании, сколько о незнакомстве с чем-либо, кроме VSS и нехватке времени / усилий для изучения чего-либо еще.

  • Подход xcopy / 7-zip звучит разумно, я думаю, но он быстро займет много места, верно?

  • Что касается управления исходным кодом, я думаю, что я хотел бы, чтобы управление исходным кодом просто сказало, что «это состояние папки сейчас, я разберусь с этим, и если я не смогу сопоставить материал» это твоя вина, я просто начну новую историю ", а не проваливаюсь.

• @ Стив М :

  • Да, это более хороший способ сделать это, но потребует значительных культурных изменений. Сказав, что мне очень нравится этот подход.

• @ тк :

  • Хорошо, я не думал об использовании Rsync для развертывания. Это только загружает различия? Перезапись всего действующего каталога каждый раз, когда мы вносим изменения, будет проблематичной из-за простоя сайта.

Мне все еще интересно посмотреть, есть ли более традиционные варианты

Answer 1

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

Как правило, изменения кода в производственных системах никогда не допускаются. Изменения следует вносить и тестировать в среде разработки / тестирования / UAT, а затем, подтвердив их как OK, можно пометить этот код в SVN с помощью чего-то вроде RELEASE-x-x-x. Затем в действующей системе экспортируйте код с этим тегом.

Answer 2

Мы используем вариант 3. Rsync. Я написал скрипт bash, чтобы сделать это вместе с дополнительной проверкой, но вот основы того, что он делает.

1. Сделать метку для подталкивания к жизни.
2. Запустите svn export для этого тега.
3. rsync, чтобы жить.

Пока это работает. Нам не нужно беспокоиться о конфликтах пользователей или иметь отдельного пользователя для запуска svn на рабочей машине.

Answer 3

rsync будет загружать только различия. Лично я не использовал его, но Марк Пилигрим давно писал о том, как он даже блестяще обрабатывает двоичные различия .

svn + rsync звучит как фантастическое решение. Мне придется попробовать это в будущем.

Answer 4

Любое решение по управлению исходным кодом, которое вы выберете, будет иметь проблемы, если люди перемещают, удаляют или добавляют файлы и не сообщают об этом системе контроля версий. Я не знаю ни одного элемента управления исходным кодом, который мог бы решить эту проблему.

В случае, когда вы просто не можете обучить людей, работающих над проектом [1], вам, возможно, придется просто делать ежедневные снимки. Возможно, самое простое решение, например, пакетный файл с использованием xcopy для сетевого диска и, возможно, 7-zip в командной строке для его сжатия, чтобы он не занимал слишком много места.

[1] Я бы сильно не поверил этому, вероятно, просто в том случае, если бы люди были слишком упрямы и не желали учиться или выполнять «дополнительную работу». Не берите в голову, сколько времени система контроля источников может сэкономить, когда им приходится возвращаться к предыдущим версиям, или 2 человека редактировали один и тот же файл.