Черепаха SVN - как подготовить репо
У меня есть настройка репозитория SVN, но я не определил свой ствол, и я немного запутался, как перемещать код из одной ветви в другую.
Структура выглядит следующим образом:
--Repo
----Dev
------common
------project
----Test
------common
------project
----Prod
------common
------project
Во-первых, какой из них должен быть багажник? Я думал, что ветвь Test должна быть, но в последний раз я сказал, что ветка Dev должна быть (хотя в этом примере было только две ветки). Во-вторых, весь код уже находится в каждой из 3 веток, нужно ли мне, и если да, то как мне объявить одну из них как транк?
Наконец, при подготовке к продвижению кода в нашу тестовую ветвь (все это будет сделано через проводник Windows, а не из проекта Visual Studio/Xcode и т. Д. Просто нажмите на ветку, выполните обновление SVN, объединение SVN и выберите мой источник для слияния?
Извините за новые вопросы, удивительно, что все, что я нашел на SO, предназначено для разных сценариев, которые могут / не могут применяться, я просто хотел бы получить подтверждение, чтобы я чувствовал себя лучше, поэтому мне не нужно повторять все это в будущем,
Правка (в ответ на ответ Давида)
Итак, у меня уже есть "ствол / ветви / теги" под общей папкой. Так что я предполагаю, что могу просто удалить папки Dev/Test/Prod (и содержимое prod). "Тест" будет на самом деле размещен в Repo/ foo /branch/test, это правильно? Или я думаю, что это может пойти Repo/ ветки /test/foo/, верно? (Общее настроено как внешние SVN... к вашему сведению)
Так как я вообще не использовал SVN-синтаксис, мне нужно исследовать вещь --parents... Мы используем исключительно Tortoise, но я думаю, мне, вероятно, все равно придется изучать SVN, так как он использует Jenkins для сборка...
Все остальное из вашего ответа выглядит великолепно! У меня есть только небольшой фон Git, с большим количеством фона SourceGear Vault, поэтому переключение все еще немного сбивает с толку.
2 ответа
Вам на самом деле не нужны отдельные строки кода для тестирования, производства и разработки. Если только вы не ожидаете, что те, кто занимается тестированием и производством, будут выполнять собственное кодирование. В противном случае, вы будете копировать много вещей туда и обратно.
Редакция, над которой работают разработчики (скажем, Subversion revision #100), через некоторое время будет принята командой QA для тестирования. И, если команде QA это понравится, версия # 100 станет тем, что будет выпущено в Production. Каждая команда следует за другой. Возможно, разработчики работают над Subversion Revision 100. Тем временем QA тестирует Revision 97. И Revision 90 - это то, что находится в производстве. Единственное, что я бы порекомендовал, это пометить, что идет в производство.
Давайте возьмем типичную структуру:
repo/branches/
repo/tags
repo/trunk/common
repo/trunk/projects
Я работаю из ствола на проекте foo, Я проверяю repo/trunk/foo а также repo/trunk/common делаю свою работу и проверяю мои изменения.
Теперь, допустим, я хочу пометить Revision 90 из своей ствола, потому что она одобрена для производства, и я могу пометить свой выпуск следующим образом:
$ svn cp --parents -r 90 $REPO/trunk/foo@90 $REPO/tags/1.3/foo
$ svn cp -r 90 $REPO/trunk/common@90 $REPO/tags/1.3/common
Если мне нужно посмотреть, что было выпущено, я могу проверить тег выпуска 1.3 из своего репозитория.
Есть два способа, которыми вы обычно используете ветвление:
- Вы ветвитесь на выпуске.
- Вы ветвитесь на функцию.
Я собираюсь описать ветвление релиза, потому что это проще.
Представьте, что вы работаете над выпуском 1.3. В какой-то момент у некоторых ваших разработчиков больше нет работы над вашей версией 1.3, и они хотят работать над версией 1.4.
До этого момента работа над вашей версией 1.3 велась на транке. Ваши разработчики 1.4 не могут выполнять свою работу, потому что они не хотят вносить изменения 1.4, пока вы работаете над изменениями кода 1.3. Таким образом, они сидят весь день, играя в Candy Crush, до тех пор, пока не завершится 1.3, и каждый сможет отработать ствол на выпуске 1.4.
Чтобы сократить время Candy Crunch, я собираюсь сделать ветку релиза:
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.3/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.3/common
Теперь те разработчики, которые все еще работают над выпуском 1.3, переключают свои рабочие копии на ветку 1.3, в то время как те, кто работают над 1.4, продолжают работать над стволом. Как только ваш релиз будет завершен, вы можете пометить его прямо с ветки:
$ svn cp --parents $REPO/branches/1.3/foo $REPO/tags/1.3/foo
$ svn cp $REPO/branches/1.3/commons $REPO/tags/1.3/commons
Когда приближается релиз 1.4, вы промываете и повторяете.
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.4/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.4/common
Теперь те, кто работает над Выпуском 1.5, продолжают работать с транком, а те, кто работают над Выпуском 1.4, работают вне ветви.
Что делать, если вам нужно сделать исправление? Скажите, есть ли ошибка в версии 1.4? У вас уже есть ветка 1.4, которая, как я полагаю, больше не использовалась, когда вышел релиз 1.4 (это достаточно просто проверить. Сравните последнюю версию ветки 1.4 с ревизией, в которой был тег 1.4). Просто сделайте свою работу для версии 1.4.1 в ветке 1.4.
Как видите, не все так сложно. Кстати, нет причин, по которым вы не можете изменить имена тоже:
$REPO/foo/trunk
$REPO/foo/branches
$REPO/foo/tags
$REPO/common/trunk
$REPO/common/branches
$REPO/common/tags
В этом случае я рассматриваю каждый проект как отдельный суб-депозитарий со своими собственными ветвлениями и тегами. Я мог бы хотеть сделать это, если все мои проекты находятся на различных графиках выпуска.
отклик
Итак, у меня уже есть "ствол / ветви / теги" под общей папкой. Так что я предполагаю, что могу просто удалить папки Dev/Test/Prod (и содержимое prod). "Тест" будет на самом деле размещен в Repo/foo/branch /test, это правильно? Или я думаю, что это может пойти Repo / ветки /test/foo/, верно? (Общее настроено как внешние SVN... к вашему сведению)
Там нет необходимости в тестовой ветке. QA просто тестирует конкретный релиз Subversion прямо из ветки, которую используют разработчики. Например, предположим, что Subversion находится на Revision 100, а QA тестирует Revision 95. Если QA обнаруживает ошибку, она сообщается и включается в Revision 101. Когда QA тестирует Revision 101 или выше, они могут проверить, есть ли эта ошибка. было исправлено. Если это так, они могут закрыть ошибку. В противном случае они могут открыть его снова.
Если вы используете систему непрерывной интеграции, такую как Jenkins, которая собирает ваше программное обеспечение при каждом изменении, вы можете говорить о конкретной сборке. Последняя сборка будет Build #30, но QA тестирует Build #28. Если QA обнаружит ошибку, разработка просто исправит ее, и Дженкинс создаст сборку #31. Затем QA может протестировать сборку # 31, чтобы увидеть, была ли исправлена ошибка.
Мы использовали Джиру и Дженкинса в одном магазине, и они были объединены. Когда разработчик исправляет ошибку, он помещает этот номер ошибки в сообщение фиксации. Затем Дженкинс обновит этот билет Jira сборкой Jenkins. Если QA обнаружит исправленную проблему, они могут взглянуть на билет Jira, посмотреть сборку Jenkins, где она была исправлена, и протестировать ее.
Я надеюсь, что это имеет смысл и почему вам не нужны ветки для тестирования, производства и т. Д.
Так как я вообще не использовал SVN-синтаксис, мне нужно исследовать вещь --parents... Мы используем исключительно Tortoise, но я думаю, мне, вероятно, все равно придется изучать SVN, так как он использует Jenkins для сборка...
Всегда полезно знать версию командной строки клиента Subversion. Иногда, когда что-то идет не так в TortoiseSVN, вы можете получить больше информации из клиента командной строки, чтобы увидеть, что происходит. --parents Параметр просто означает создание родительских каталогов, которые могут быть или не быть там. Например, вы хотите создать каталог /branches/4.3/foo, но там не может быть /branches/4.3 каталог. Я полагаю, что в TortoiseSVN это будет создано автоматически. В клиенте командной строки --parents Параметр будет создавать как /branches/4.3 каталог (если он не существует) и /branches/4.3/foo каталог тоже.
Все остальное из вашего ответа выглядит великолепно! У меня есть только небольшой фон Git, с большим количеством фона SourceGear Vault, поэтому переключение все еще немного сбивает с толку.
Subversion на самом деле довольно прост по сравнению с Git, поскольку существует только один уровень хранилища. Вы оформляете заказ, изменяете, фиксируете.
Большая разница между Git и SVN заключается в том, что SVN является линейным. Ревизия 100 всегда предшествует ревизии 101. В Git ревизии не имеют реального порядка. Версии репозитория представлены в виде BLOB-объектов с контрольными суммами. Порядок наложен деревьями, которые указывают на определенные сгустки. Тем не менее, для тех, кто знаком с SVN, возможно, труднее понять Git, чем наоборот.
Подождите, еще один вопрос, как мне автоматизировать сборку для моей тестовой среды, если имя ветви будет меняться в каждом выпуске (т. Е. 1.3, 1.4 и т. Д.)?
В Jenkins у нас просто есть набор сценариев оболочки, которые дублируют проекты. Я настроил проекты, поэтому изменение между ними минимально: я просто меняю названия веток. Запустите мой сценарий, и до того, как будет создано больше рабочих мест в Jenkins. Запустите другой, и старые ветки заданий будут удалены.
Некоторые сайты используют триггер пост-фиксации для создания задания Jenkins, которое выполняется в ветви. В Jenkins вы можете передать параметр в сборку, чтобы передать ветку, в которой произошло изменение, и Jenkins строит эту ветку. Поскольку они переходят от одного выпуска к другому, им никогда не нужно создавать новые рабочие места.
Теперь, если вы выпускаете релизы на еженедельной или двухнедельной основе, вам, возможно, не понадобятся ветки релизов. Все из багажника (кроме случайных горячих пятен). В этом случае очень вероятно, что все в вашей команде работают над одним и тем же выпуском. Я разветвляюсь, чтобы позволить двум разным группам разработчиков работать над выпуском 1.3 и 1.4 (который находится на транке) одновременно. Если у вас нет этой проблемы, нет необходимости в ветке релиза (кроме случайного исправления).
Транк / теги / ветки - просто соглашение об именах. Я бы предложил вам Dev на стволе, затем объединить для тестирования при подготовке к выпуску. Для ясности вы можете переименовать вашу ветку Dev в "trunk", чтобы не запутаться в со-разработчиках.
Ветвь Prod кажется немного излишней; вы можете пометить версии в вашей тестовой ветке, которые пошли в производство.