SVN: Действительно ли сохранить тег от ошибочной выпущенной версии?

Question

Мы создали TAG для версии выпуска одного из наших продуктов (например, 4.3.0GA). Затем мы развернули его в производственных экземплярах. на следующий день производственные экземпляры полностью рухнули, сделав себя совершенно непригодными для использования. мы быстро выпускаем новую версию, исправляющую ошибку. и запустить их в производство.

Затем мы обновили наш TAG (4.3.0GA) с исправлениями ошибок. (да, мы сделали прямой коммит на TAG 4.3.0GA)

---

Тогда мы пришли к этой дискуссии внутри нашей команды:

Предложение A

Мы допустили ошибку. TAG никогда не должны обновляться. Мы должны вернуть исправленную ошибку 4.3.0GA TAG в исходное состояние. и затем создайте новую TAG с именем 4.3.0GASP1 с исправлениями ошибок. Потому что каждая выпущенная версия (даже если она работает только один день в производстве) должна иметь уникальный тег в хранилище.

Предложение B

Не изменяйте действительные теги репозитория. Потому что, если есть версия 4.3.0GASP1, кто-нибудь может по ошибке проверить версию с ошибкой 4.3.0GA. TAGS должен содержать только версии без ошибок, и, наконец, версия с ошибками работала только один день.

Что ты думаешь? Какая поза правильная (предложение А или В)?

ОБНОВЛЕНИЕ: Кстати, мы используем Соглашение о версиях Jboss .

Answer 1

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

Так что, если теги никогда не будут изменены - это вопрос, на который вы и ваши процедуры выпуска можете ответить.Никто не может сказать, что вы не правы.

Итак, какой из них подходит вам лучше всего?Это «правильный» ответ.

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

Итак, вы видите, как мы «нарушаем» лучшеепрактики контроля версий, но, поскольку она прекрасно работает для нас, нам все равно.Мы делаем то, что работает для нас.

РЕДАКТИРОВАТЬ: Я думаю, что если вы собираетесь иметь полную трассируемость, вам нужно гораздо больше, чем ветка тегов, которая имеет одну и только одну версию в нем.Редакция HEAD каждого тега все еще должна быть достаточной для вас в этом случае сломанной версии, которая быстро исправляется.Он также может предоставить трассировку исправлений, которые были необходимы для обеспечения «качества выпуска».

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

Answer 2

С точки зрения передового опыта вы должны были зафиксировать исправления ошибок в ветке, из которой вы отметили 4.3.0GA.Затем создал новый тег из фиксированной ветви.Конечно, это предполагает также с точки зрения передовой практики, что он был помечен из какой-то ветки обслуживания веток / release-4.3 вместо того, чтобы быть помеченным из ствола, который был изменен шестью способами с воскресенья с момента появления метки.Вы также оставляете глючный тег для потомков, потому что в этом смысл концепции тегирования.

С точки зрения вашей команды Subversion не имеет никаких законов об этом,ветвь - это просто ветвь, поэтому вы можете делать все, что захотите.Хотя в такой ситуации вы, вероятно, должны быть определены как ведущий программист, менеджер по выпуску или вся команда, то есть тот, кто несет ответственность за принятие этого решения.Использование дерьма olicy для RCS / VCS / SCM, вероятно, полезно для любого нетривиального проекта.

---

Хорошей практикой является создание по крайней мере двух веток для каждого выпуска.

Одна ветвь предназначена для поддержки выпущенного вами кода, а вторая никогда не записывается в «тег» того, что вы на самом деле выпустили.Любой выпуск, который пользователь может загрузить, получает тег, каждая выпущенная основная версия получает ветку обслуживания.Если коммит принадлежит в стволе и ветвях релиза, то книга SVN и Google сообщат вам, что делать.Я называю это вишневым выбором и перебазированием, но вы можете догадаться, откуда я;)

Answer 3

Я склонен упасть на сторону A :

ИМХО, теги должны быть маркерами временной шкалы, которые показывают состояние кодовой базы в конкретной версии или выпуске. Даже если эта версия была глючной, это было то, что было отправлено, и у вас должна быть запись об этом на случай, если вам нужно оформить заказ и преднамеренно воспроизвести ошибку, которую этот выпуск мог вызвать для клиентов, серверов или что -У-ты.

Кто-то может получить ошибочную версию кодовой базы, проверив этот тег, но разве многие теги также не являются исправлением ошибок? Вам не нужно сталкиваться с дилеммой «Насколько глючит этот выпуск?» , чтобы определить, что вы делаете в своей VCS. Журнал релизов, хранящийся вне Subversion, должен помочь минимизировать количество неудачных проверок.

Мое эмпирическое правило: если новый код отправляется, он входит в новый тег.

Answer 4

ИМО, А и В содержат в себе немного правды.

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

Вы можете удалить тег, если считаете, что это приводит к путанице / проблемам, поскольку svn запишет изменение и позволит вам вернуться обратно. Однако может помочь также страница Wiki или центральная электронная таблица с описанием каждого тега / выпуска # (примечания к выпуску?). Предполагая, что ваша команда следует за непрерывной интеграцией, может быть несколько сборок, помеченных тегами, прежде чем вы действительно определите правильную, поэтому удаление нежелательных тегов может оказаться непростой задачей.