Как настроить репозиторий SVN для аварийных исправлений?

Question

Будучи разработчиком в течение нескольких лет, это то, что я должен знать, но не знаю.

Я работаю над выпущенным продуктом в небольшой команде.Я являюсь основным разработчиком, фиксирующим большую часть кода, но есть пара других разработчиков, которые время от времени делают это.В настоящее время у нас есть промежуточный сервер, на котором работает Hudson CI, который собирается после каждого коммита.Производство обновляется вручную с помощью простой команды svn up, когда транк стабилен и протестирован.

Обычно это работает нормально, за исключением тех случаев, когда у нас есть ситуации, требующие срочных / срочных изменений в производстве, когда код не завершен в транке.

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

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

т.е.В этой ситуации я хочу найти лучшее решение, потому что это происходило несколько раз

• Rev 1000 обновляется при производстве
• Rev 1001-1005 - новые запросы функций / ошибкаисправления, которые будут включены в следующую версию
• Rev 1006 - это срочное исправление, которое необходимо запустить в производство
• Rev 1007-1009 - это дополнительные обновления функций
• Rev 1010должна быть следующая версия, обновленная до рабочей версии

Обновление:

После прочтения раздела ветвления Книги SVN я подумываю о следующей настройке.

1. Создать ветку, когда будете готовы нажать на продукт

   svn copy /trunk /branches/production_01 -m 'Production release'

2. На производстве переключитесь на производствоветвь

   svn switch /branches/production_01

3. Если необходимо срочное исправление, разработчику необходимо внести изменения в ветку:

   svn checkout /branches/production_01
// make changes
svn merge /trunk # make sure changes get merged into trunk as well
svn commit -m 'Urgent fix

4. На производстве, обновление до последней версиич

   svn update

Похоже ли это на наш процесс?

Answer 1

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

В вашей ситуации я бы сохранил одну постоянную ветку production. Всякий раз, когда вы делаете нормальный выпуск, стабилизируйте его в trunk, объедините trunk в production, а затем протестируйте и нажмите.

Для исправления создайте новую ветку из production ¹ , внесите в нее изменения, затем объедините ее в production и trunk. Как и в обычном выпуске, вы тестируете и нажимаете с production.

---

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

Answer 2

Существуют различные способы решения этой проблемы, но я думаю, что наиболее эффективный способ, которым я видел это, заключается в следующем:

• Все разработчики идут в ветки, будь то исправления ошибок или новые функции. Эти ветви находятся под CI и развернуты в собственной среде для тестирования.
• Код, который должен быть запущен в производство, объединяется в магистраль из ветви (либо ветки с исправленными ошибками, либо ветвь функций). багажник тоже под CI. После проверки одобрен, он может перейти к pre-prod, а затем к prod. Только код из транка выпускается в производство.

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

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

Answer 3

Действительно, есть много способов достичь этого.Способ применения исправлений зависит от общего процесса контроля версий и выпусков проекта.Таким образом, я поставлю перед моим ответом префикс, описав базовый контроль версий , который мы используем для всех наших проектов:

1. /trunk содержит основную ветку разработки, используемую для активнойразработка, за исключением тех случаев, когда выполняется большая работа, такая как новые важные функции или рефакторинг.В этом случае разработчик сделает копию на /branches/foo, а затем вернется к /trunk, когда работа будет завершена.Выбор, работать ли в основном в /trunk или использовать ветки, зависит от количества разработчиков, сложности проекта, стадии проекта и скорости разработки.В любом случае, лучше постараться, чтобы /trunk был как можно более стабильным.
2. Как только пройден этап и работа в /trunk готова к выпуску на производственную площадку, /trunkскопировано, например, в /tags/2.5.0 (номер версии для этого выпуска).
3. Этот выпуск сначала применяется к сайту с песочницей (например, test.example.com ) с использованием svn switch ^/tags/2.5.0 (примечание в виде каретки (^) в URL;) и показывается клиентуили команда QA для проверки.
4. Если настройки запроса клиента или команды QA повторяются, шаги 1–3 повторяются, а дополнительный номер версии увеличивается (например, до /tags/2.5.1).
5. Один разсайт с песочницей был протестирован и одобрен для выпуска, те же шаги, которые использовались для запуска сайта с песочницей, применяются к производственному сайту (т. е. svn switch ^/tags/2.5.1).

Итак, в случае, если мынеобходимо установить срочное исправление на производственный сайт, мы будем:

1. Применить исправление непосредственно к версии выпуска на /tags/2.5.1, используя локальную рабочую копию /tags/2.5.1 или непосредственно на сайте с песочницей..
2. Если изменения были сделаны в локальной рабочей копии, мы зафиксируем изменения и обновим (svn up) сайт песочницы.Затем мы повторяем процесс проверки / утверждения.
3. После утверждения просто обновите (svn up) производственную площадку.
4. Изменения, внесенные в выпускную версию на /tags/2.5.1, объединяются обратно в/trunk.