Какое оптимальное решение для управления резервным копированием и контролем версий на живых веб-сайтах?

Question

Какое оптимальное решение для управления резервным копированием и контролем версий на живых веб-сайтах?

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

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

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

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

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

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

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

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

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

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

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

Ответ отвечает:

• @Kibbee:

  • Это не столько об образовании, как не знакомство с чем, кроме ВСС и нехватки времени/усилий, чтобы узнать что-нибудь еще.

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

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

• @Steve M:

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

• @mk:

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

rsync будет загружать только различия. Я лично его не использовал, но Mark Pilgrim написал давно о том, как это даже handles binary diffs brilliantly.

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