Использование SVN с промежуточным и живым веб-сайтом - PullRequest
9 голосов
/ 19 января 2011

У меня в настоящее время есть хранилище SVN на моем размещенном веб-сервере. Я работаю локально, фиксирую свои изменения в репозитории на моем сервере, а затем запускаю «svn update» через ssh в моей рабочей папке, когда я готов выложить изменения.

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

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

  1. Предположим, что мой локальный, промежуточный и живой сайт начинаются с ревизии 1.
  2. Я делаю крупные изменения локально, фиксирую их и обновляю свой промежуточный сервер. Локальные и промежуточные версии находятся на ревизии 2, прямая трансляция по-прежнему включена 1.
  3. Кто-то просит простого изменения текста на живом сайте.
  4. Тьфу. Теперь я должен вернуть свою локальную копию в редакцию 1, внести небольшое изменение и зафиксировать его. Теперь я обновляю сайт до версии 3, в которой есть небольшое изменение.
  5. Я хочу продолжать работать над своими основными изменениями, поэтому я обновляю свою локальную копию до версии 2 и продолжаю работать.
  6. И так далее ...

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

Спасибо, Ионы

Ответы [ 2 ]

9 голосов
/ 19 января 2011

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

  • Разработчики фиксируют все улучшения или исправления ошибок в нашей ветке 'dev', прежде чем отмечать работу как завершенную.
  • Задания тестируются на промежуточном ящике с последним кодом в ветке dev.
  • Как только задание проходит тестирование, редакции этого задания объединяются с нашей внешней ветвью.
  • На наших живых веб-серверах работает магистральная ветка. Периодически они обновляются с помощью сценария публикации, который обновляет SVN на живых серверах, а также выполняет некоторые другие функции (например, запутывает и минимизирует CSS и JavaScript).

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

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

Фактически, этот метод отражает методы, которые системы версионирования, такие как Git и Mercurial, пытаются продвигать путем структурирования своих репозиториев. В этих системах управления версиями у каждого разработчика есть свой «локальный» репозиторий. Когда они хотят изменений из другого «хранилища», они должны объединить их со своим локальным кодом, а затем зафиксировать действительную «объединенную» версию.

Вы также можете использовать пометки, как Энди упоминал в своем ответе на этот вопрос. Это может сработать для вас, но я предпочитаю возложить ответственность за слияние на разработчиков, которые пишут код, а не на центрального старшего разработчика или менеджера публикации. Как правило, они идут более гладко.

1 голос
/ 19 января 2011

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

Основные разработки

  1. Вы делаете ваши основные разработки на стволе.
  2. Каждый раз, когда вы выпускаете копию своего программного обеспечения для работы, вы создаете тег из ствола и переключаете свой веб-сайт, чтобы он указывал на новый тег.

Когда вам нужно внести небольшое изменение в жизнь, вы можете теперь сделать следующее:

  1. Создайте ветку из живого тега и выполните работу здесь.
  2. Как только вы будете довольны этим изменением, вы создадите новый тег из этой ветви и переключите свою рабочую копию на новый тег.
  3. Вы также можете объединить это изменение из ветви в ствол, чтобы это изменение также было в вашей следующей основной версии.

Существует очень хорошая книга о подрывной деятельности, которая объясняет все это в мельчайших подробностях:

http://svnbook.red -bean.com /

Если вы можете найти время, я настоятельно рекомендую прочитать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...