Здравствуйте, mr.sashich, Вы писали:
MS>Проектная команда состоит из 2-х разработчиков. Периодически возникает необходимость уйти в бранч и там "барахтаться". Так вот такие "походы в бранч" никак не регламентированы. Все интуитивно. MS>Есть ли какие-нибудь формальные правила когда следует уходить в бранч и когда возвращаться из него(мержить)? MS>Метрики, Критерии, Личный опыт... MS>Прошу прощения за размазанную формулировку вопроса =)
Branching Patterns for Parallel Software Development
Коллеги, доброго времени суток.
A>- девелоперы делают изменения — отращивают девелопмент-бранч от релиз-бранча. A>- когда кто-то из них считает, что изменения пофиксили багу или внесены нужные изменения но новой фиче — он мержит их с последней имеющейся стабильной версией (если она изменилась со времени отращивания) и отдает на ревью A>- проходит ревью кода (или не проходит — тогда огрехи исправляются) A>- код отстраивается и тестируется A>- если тесты проходят, бага пофиксена, и новых багов не внесено — код считается стабильным A>- стабильный код мержится на релиз-бранч и метится релизной меткой
A>Фух... это вкраце, упрощенно, под твою ситуацию.
Меня интересует следующий вопрос.
При обсуждении различных стратегий работы с бранчами авторы многих топиков (вот как и данный автор) указывают на то, что после того, как закончена разработка, идет операция мержа и лишь затем ревью, тестирование и т.п. Также я читаю сейчас книгу от коллег из МС и там практически дословно написано в частности, что одним из главных поводов использовать технику бранчевания является необходимость нескольким группам разработки параллельно работать над одним и тем же набором файлов. Они также пишут, что ревью, тестирование и прочие активности идут после мержа.
У меня же цель, которую я преследую используя в работе бранчи, в корне отличается от всего вышесказанного. Подскажите пожалуйста, я действительно чего-то не понимаю? Может быть у меня все же есть единомышленники?
Дело в том, что в работе мы используем методику, когда есть центральная ветка проекта, над которой автоматически работает билдовая машина и каждый вечер она собирает и тестирует продукт (к утру успевает закончить тесты). Каждый раз когда девелоперу или группе разработки необходимо сделать какую-либо фичу или пофиксить какой-либо баг — они всегда обязательно создают бранч, работают в нем, затем интегрируют изменения в основную ветку. Так делается всегда на любые изменения — новые фичи, исправление багов — всегда бранч. И цель вовсе не в том, чтобы обеспечить комфортную работу нескольким группам.
У нас слияние происходит только тогда, когда внутри бранча уже пройдены все стадии ревью, которые необходимы, билдовая машина сделала успешный пробный билд из этого бранча, на этом бранче успешно были выполнены все автоматические тесты и т.п. Т.е. именно в тот момент когда бранч готов к слиянию настолько, что вероятность развалить основную ветку сводится к минимуму — именно тогда осуществляется слияние. И цель всего этого процесса — качество.
Еще один нюанс. Мы разрабатываем некий коробочный продукт — инструмент для других девелоперов. Пусть например мы делаем MS VS. Наши билдовые скрипты — это не просто процесс компиляции исходных кодов и получение набора бинарных модулей. Конечным продуктом билдовой машины является готовая программа установки нашего продукта скопированная на файл-сервер. Естественно, что компиляция исходных кодов программных модулей продукта — это лишь один из многих шагов большого билдового скрипта, направленный на получение этой инсталляции.
Теперь пример. Я разработчик. Мне дали задачу реализовать некоторую фичу. Я ее делаю, что-то создаю новое, что-то меняю в существующем коде. Проверил — вроде работает. Можно сливать изменения в основную ветку? НЕТ! Система большая, имет много связанных друг с другом подсистем. Разработчик никогда не может быть уверен в том, что сделанный им локальный кусочек нового функционала (пусть даже на машине разработчика этот кусочек и работает нормально) не развалил ту же программу установки! Программа установки элементарно может перестать компилироваться. У нас например непосредственно с самой программой установки сами разработчики не работают — она им не нужна, они работают над какими-то конкретными изолированными подсистемами в рамках своих полномочий и сам продукт целиком на компьютер себе не ставят. И уж тем более у них нет на компьютерах среды, в которой разрабатывается эта программа установки. Если разработчик сейчас произведет слияние с основной веткой, он может ее развалить. Следующий цикл интеграционного тестирования возможно запустится только через час. За это время другие разработчики из основной ветки могут разнести смерженные изменения в свои бранчи — начнется эпидемия.
Поэтому мерж идет только тогда, когда был успешно выполнен билд над "готовым" к слиянию бранчем и когда автоматизированные тесты показали, что в бранче вроде все в порядке.
Это конечно частный пример, просто пример.
Таким образом после того, как руководитель бранча (есть такое ответственно лицо) его создал — он сразу рисует план работ по этому бранчу (фиче), в котором описывает список активностей, которые необходимо сделать, чтобы достичь главной цели — мержа в основную ветку. В плане есть задачи на проектирование архитектуры фичи, на создание спецификаций, на создание юнит тестов, на создание функциональных тестов, на внесение корректив в инсталляцию или другие подсистемы, на ревью всех артефактов разработки, затем задачи на пробные билды, тестирование — много еще чего и наконец задачу на слияние с основной веткой.
Есть вот такая особенность разработки, которая регламентирует делать слияние веток только по достижению стабильного состояния бранча. Задачи назначаются на людей и процесс закрутился-завертелся. В конце бранч слили и уничтожили, перешли к следующему.
Здравствуйте, mr.sashich, Вы писали:
MS>Есть ли какие-нибудь формальные правила когда следует уходить в бранч и когда возвращаться из него(мержить)? MS>Метрики, Критерии, Личный опыт...
Зависит от типа разрабатываемого продукта. Например, если это коробка, то, как правило, разработка ведется в основной ветке, а каждый релиз выделяется в бранч и стабилизируется там. Тогда все просто, по бранчу на релиз. Если же это какой-то внутренний продукт или под конкретного заказчика, где нет четких релизов, то релизной фактически является основная ветка и выделяется по бранчу на фичу. По завершении реализации фичи и мердженья его с основной веткой, бранч ликвидируется.
Многое так же зависит от конкретной VCS..
Здравствуйте, Aikin, Вы писали:
A>У меня ситуация следующая:
... A>либо объясняем заказчику, что этот фикс совсем не хот и вполне может потерпеть до релиза
Короче, используемый тул диктует процесс работы... Хотя должно быт наоборот — устанавливается процесс — и потом берутся инструменты...
A>Не могу отдать предпочтения ни первому, ни второму варианту. Но так как здесь советуют второй он стал доминировать над первым ( ). Кроме того, на второй вариант хорошо ложиться CI сервер (которого еще нет, но в скором времени, надеюсь, будет установлен).
В твоем конкретном случае я бы сделал так:
— на транке держал последние стабильные версии со всеми хофиксами
— ежемесячные релизы отпочковывал в отдельные теги АКА бранчи (в SVN метки — это и есть бранчи, так что буду называть их бранчами)
— разрабочики коммитят свою работу только на свои рабочие бранчи (например, по одному на фикс или новый фнкционал)
Когда разработчик сделал что-то, например фикс, и оттестировал — он подает изменения на транк. В конце месяца с транка делается срез, тестируется и отпочковывается в очередной релиз. Важный момент — тестирование перед мержем (но это к политике бранчевания не относится) и держание каждого фикса на отдельном бранче, пока он не понадобится в хотфикс-релизе или деплой-релизе.
Здравствуйте, Aikin, Вы писали:
A>Ну тогда я не понимаю разницы между ними. Это просто пометка (тэг)? Для истории? Можешь объяснить?
Если отвлечься от описанного тобой примера (небольшая команда, специфичный процесс), то, как правило, навешивание метки — это элемент выпуска стабильных релизов АКА бэйзлайнов (мы их в шутку называем вазелинами ). Бэйзлайн — это основа для дальнейшей разработки, а также для поставки стабильных версий продуктов заказчику. Т.е. выделив бэйзлайн (неважно как — навешиванием метки в CVS или отбранчеванием тэга в SVN), ты говоришь — вот код, который я считаю стабильным, который прошел тестирование и показал достаточный (для данного проекта и этапа работы) уровень пройденных тестов, и может быть использован как основа для дальнейшей разработки. Далее этот стабильный релиз может оправится заказчику, может пока приежаться. В любом случае — разработчики могут брать его как эталон и базу. Эталон — потом что он стабилен и любая поломка функционала будет видна на его фоне. Как базу — потому что имено от него можно отращивать свои изменения (а не от непонятного транка, куда могли по ошибке засабмитить плохие изменения).
В целом — вот так. Это я рассказываю о бэйзлайне в понимании configuration management'а. Кроме того, примерно такое же объяснение дается в рамках CMM/CMMI. Что это такое — это уже совсем другая история
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте! Извиняюсь, что на вопрос вопросом: А>Вы (и может кто отвечал) какую используете систему контроля версий и учета PCR. А>А то никак себе выбрать не можем
Контроль версий — IBM (Rational) Clearcase. Его "спустил сверху" заказчик. Для внутренних нужд иногда используется SVN и CVS.
Багтрекинг (учет PCR) — Rational DDTS (его модифицированная версия) — спущен сверху. Для всего остального, причем не только в качестве побочного, используется eTraxis. Супергибкая штука, рекомендую!
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, Aquary, Вы писали:
A>> Для всего остального, причем не только в качестве побочного, используется eTraxis. Супергибкая штука, рекомендую!
I>не увидел с наскоку. интерируется с свн?
Нет. Но никто не мешает дописать такой функционал, ведь етрахис идет под GPL.
Здравствуйте, Aikin, Вы писали:
A>Комрады, вот я задумался над тем как закрывать бранч.
A>Полазил по докам и по списку доступных команд и оказалось что ближе всего закрытию соответствует удаление этой ветки нафик. Прав ли я? Или есть более цивилизованный вариант закрытия ветки?
S>В реалиях — имеется ввиду на проектах, похожих на наш. Мы сейчас используем SourceSafe. Приложение: ASP.NET. Тяжолое. S>Solution состоит из 15-16 взаимосвязанных проектов.
S>Выпускается релиз. Начинается разработка новых модулей. В стабильной версии обнаруживаются критические баги. Их нужно S>исправлять, генерировать новый "стабильный" релиз. Параллельно в это время идёт разработка новых модулей, которые S>должны учитывать внесённые в релиз изменения.
Ну да — а в чем проблема? Как именно делать разделения на бранчи — это зависит от вашей специфики, но основные действия тут — бранч/мерж.
Допустим, в trunk лежит текущий релиз и его патчи, в бранчах идет работа над релизами, включающими новый функционал.
Поправили баги на trunk, протестировали, поставили заказчику, сделали мерж на релизные бранчи, заморозили.
Когда релизные бранчи созрели, тестируем, поставляем, мержим на основной.
Это одна из возможных схем, их можно придумать произвольное количество. В чем именно проблема или опасения?
Здравствуйте, Spidola, Вы писали:
S> Мы сейчас используем SourceSafe. S>Приложение: ASP.NET. Тяжолое. Solution состоит из 15-16 взаимосвязанных проектов. S>Появилась жёсткая необходимость разделять версии.
Сочувствую. В SS бранчинг просто убогий, да и вообще....
S>Вот эта модель сейчас и продумывается...
В SVN такая модель реализуется элементарно. Тут главное за бранчами следить, чтобы не расползались, но это в любой VCS... Главное внятно прописатьполитику бранчинга и жестко ее придерживаться.
Здравствуйте, Spidola, Вы писали:
S>Открывал уже, смотрел оглавление. Там, к сожалению, ничего нет об интеграции с VS.
К студии не прикручивал (давно ей непользуюсь), но видел плагин.
А реально в своих проектах использую обычно tortoisesvn, который в проводник интегрирован.
Основной финт на мой взгляд — в "нормальных" VCS файлы не блочатся эксклюзивно, т.е. действие "checkout" не является обязательным (как при "лоченьи" файлов)
S>P.S. вообще, насколько я понимаю, модель разработки меняется в плане сборок — сейчас сборка может быть сделана в любой S>момент (в VSS всегда лежит последняя "законченная" весрия), а при использовании SVN предполагается специальная S>операция мерджа.
В этом плане все практически так-же — последняя стабильная версия, которая гарантированно собирается,
лежит в основной ветке — trunk. А вот бранчи, которые могут сломать билд — туда не попадают, и соответственно этот билд не сломают.
Хотфиксы можно коммитить на основной бранч, под ответственность коммитящего.
Проектная команда состоит из 2-х разработчиков. Периодически возникает необходимость уйти в бранч и там "барахтаться". Так вот такие "походы в бранч" никак не регламентированы. Все интуитивно.
Есть ли какие-нибудь формальные правила когда следует уходить в бранч и когда возвращаться из него(мержить)?
Метрики, Критерии, Личный опыт...
Прошу прощения за размазанную формулировку вопроса =)
Здравствуйте, mr.sashich, Вы писали:
MS>Есть ли какие-нибудь формальные правила когда следует уходить в бранч и когда возвращаться из него(мержить)? MS>Метрики, Критерии, Личный опыт...
Обычная практика — это держать на релиз-бранче (HEAD, trunk, в общем каком-то "главном" бранче) стабильные версии, а отращиваться каждый раз, когда требуются изменения. Типичный сценарий работы такой (упрощенно):
— девелоперы делают изменения — отращивают девелопмент-бранч от релиз-бранча.
— когда кто-то из них считает, что изменения пофиксили багу или внесены нужные изменения но новой фиче — он мержит их с последней имеющейся стабильной версией (если она изменилась со времени отращивания) и отдает на ревью
— проходит ревью кода (или не проходит — тогда огрехи исправляются)
— код отстраивается и тестируется
— если тесты проходят, бага пофиксена, и новых багов не внесено — код считается стабильным
— стабильный код мержится на релиз-бранч и метится релизной меткой
Фух... это вкраце, упрощенно, под твою ситуацию.
Возвращаясь к начальному вопросу бранчеваться надо каждый раз, когда происходят изменения. В нормальных конторах для изменения (найденной баги, фичи) заводится PCR (problem or change request). Если он есть — это повод начать изменять — соответственно, отращиваться. На релиз бранч кладутся только стабильные изменения.
Здравствуйте! Извиняюсь, что на вопрос вопросом:
Вы (и может кто отвечал) какую используете систему контроля версий и учета PCR.
А то никак себе выбрать не можем
Re[2]: Управление ветками. Практики. Метрики...
От:
Аноним
Дата:
23.08.07 11:00
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, mr.sashich, Вы писали:
А>Здравствуйте! Извиняюсь, что на вопрос вопросом: А>Вы (и может кто отвечал) какую используете систему контроля версий и учета PCR. А>А то никак себе выбрать не можем
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте! Извиняюсь, что на вопрос вопросом: А>>Вы (и может кто отвечал) какую используете систему контроля версий и учета PCR. А>>А то никак себе выбрать не можем
A>Контроль версий — IBM (Rational) Clearcase. Его "спустил сверху" заказчик. Для внутренних нужд иногда используется SVN и CVS.
Эх, посмотреть бы как люди используют SVN в реалиях...
S>>Эх, посмотреть бы как люди используют SVN в реалиях...
dmz>В каких реалиях?! А какие проблемы-то?
В реалиях — имеется ввиду на проектах, похожих на наш. Мы сейчас используем SourceSafe. Приложение: ASP.NET. Тяжолое. Solution состоит из 15-16 взаимосвязанных проектов.
Появилась жёсткая необходимость разделять версии. Как где-то рядом писали, есть необходимость отпочковывать ветки. Причём ситуация упрощённая — поддержка нескольких веток требуется временная.
Опишу проще.
Выпускается релиз. Начинается разработка новых модулей. В стабильной версии обнаруживаются критические баги. Их нужно исправлять, генерировать новый "стабильный" релиз. Параллельно в это время идёт разработка новых модулей, которые должны учитывать внесённые в релиз изменения.
Когда новый модуль закончен, то это всё должно сливаться, делаться релиз и дальше по кругу.
Здравствуйте, Spidola, Вы писали:
S>Когда новый модуль закончен, то это всё должно сливаться, делаться релиз и дальше по кругу. S>Вот эта модель сейчас и продумывается...
Не совсем понял — а чего тут думать?
Упрощенно процесс я написал вот здесь
. Тебе остается только:
— опробовать на одном из проектов солюшена, определив вначале форматы именования бранчей
— описать этот процесс как-то в виде хаутушки, провести по необходимости тренинг с демонстрацией
— постепенно начать внедрять на каждый проект.
Я с VSS работал давно, не помню — есть ли там ветки... вроде нет... Хороший повод для перехода на другие системы контроля версий Внедрение — по тому же сценарию — опробовать, вкраце описать для новичков и начать постепенно внедрять.
Здравствуйте, IB, Вы писали:
S>>Вот эта модель сейчас и продумывается... IB>В SVN такая модель реализуется элементарно. Тут главное за бранчами следить, чтобы не расползались, но это в любой VCS... Главное внятно прописатьполитику бранчинга и жестко ее придерживаться.
Т.е. правильно ли я понимаю, что:
— есть главная ветка, в которой лежит релиз (назовём A);
— когда требуется разрабатывать новую функциональность, делается дополнительный бранч (назовём B);
— если возникает критическая ошибка в релизе, то делается ещё один бранч от главной ветки, исправляется ошибка, тестируется, потом накладывается на A и B.
— когда работы в B завершены — изменения накладываются на A и фиксируется релиз.
Здравствуйте, dmz, Вы писали:
dmz>Допустим, в trunk лежит текущий релиз и его патчи, в бранчах идет работа над релизами, включающими новый функционал. dmz>Поправили баги на trunk, протестировали, поставили заказчику, сделали мерж на релизные бранчи, заморозили.
Ок, понятно всё кроме слова "заморозили".
Вы уж меня простите, поскольку с SVN не работал, некоторые термины непонятны... (но подтянемся ))
dmz>Когда релизные бранчи созрели, тестируем, поставляем, мержим на основной.
Это тоже понятно.
dmz>Это одна из возможных схем, их можно придумать произвольное количество. В чем именно проблема или опасения?
Опасения как всегда в незнании пока... Основное — это интеграция с VS. С точки зрения разработчика — как это выглядит? Как выглядит работа с SVN? Сейчас всё достаточно просто — сделали check-out в студии, поправили, сделали check-in. Всех делов.
Возможно, в SVN то же самое? А как выглядит, если есть несколько веток?
A>Я с VSS работал давно, не помню — есть ли там ветки... вроде нет... Хороший повод для перехода на другие системы контроля версий Внедрение — по тому же сценарию — опробовать, вкраце описать для новичков и начать постепенно внедрять.
Угу. А вот вопрос — есть ли какое-либо вразумительное описание по внедрению? Например, что-то вроде пошагового перехода с VCC на SVN... Я, конечно, понимаю, что всё изучаемо, но копий по-ходу наломается много, если с нуля всё разбирать...
A>Как что — пиши сюда
Здравствуйте, Spidola, Вы писали:
S>Угу. А вот вопрос — есть ли какое-либо вразумительное описание по внедрению? Например, что-то вроде пошагового перехода с VCC на SVN... Я, конечно, понимаю, что всё изучаемо, но копий по-ходу наломается много, если с нуля всё разбирать...
Не совсем, конечно, то, но вот книжка от SVN мне в своё время очень пригодилась для понимания работы с ним.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Spidola, Вы писали:
S>>Угу. А вот вопрос — есть ли какое-либо вразумительное описание по внедрению? Например, что-то вроде пошагового перехода с VCC на SVN... Я, конечно, понимаю, что всё изучаемо, но копий по-ходу наломается много, если с нуля всё разбирать...
К>Не совсем, конечно, то, но вот книжка от SVN мне в своё время очень пригодилась для понимания работы с ним.
Открывал уже, смотрел оглавление. Там, к сожалению, ничего нет об интеграции с VS.
Здравствуйте, Spidola, Вы писали:
S>Открывал уже, смотрел оглавление. Там, к сожалению, ничего нет об интеграции с VS.
Что-ты зашел совсем с противоположной стороны... путаешь теплое с мягким....
Решение твоей задачи имеет 3 стади:
1. понимание практик управления конфигурацией (сиречь СМа)
2. умение работать с контретной системой контроля версий (SVN)
3. возможность интегрировать с твоими тулами (VS), перенос исходников из одного места в другое (SVN->VSS)
Предложенная умным человеком книжка — решение 2 стадии проблемы . Она показывает как работать с конкретной системой контроля версий.
То, что писал я — очень краткое описание самой 1 стадии. Очень краткое. 1-й стадии, т.е. концепция — как и когда правильно растить бранчи.
Ты же интересуешься 3-й, последней стадлией, конкретными подробностями того, как тебе перейти с одного тула на другой.
Итак:
1. читаешь и проникаешься мыслью о бренности всего сущего и о важности отращивания веток. Прочитали, переварили, закрепили.
2. читаешь про SVN: общая концепция, как разбивается работа между сервером и клиентом, что делается на чьей стороне, как делается чекаут-чекин (в терминах VSS, хотя это и неполное соответствие), как растить бранчи. Ставишь SVN себе и тренируешься на кошках. Заодно выбираешь тул для интеграцией со Студией или просто для работы с SVN — их немного, но для твоих задач существующих должно хватить.
3. зная в теории и немного в практике SVN, зная досконально твои задач — приступаешь к переносу исходников из существущей системы в другую.
При этом не надо искать магических тулзов для перегона из VSS в SVN. Выбираешь последнюю стабильную версию кода солюшена, загоняешь в SVN (это совсем недолго). Всё. Начинаешь работать. Все предыдущие версии твои элементов будут доступны в VSS. Это на случай если они тебе понадобятся (ведь ты же возьмешь стабильную версию, значит с большой вероятностью откат назад тебе не понадобится).
Вот...
P.S. А у вас отслеживание ошибок хоть как-то производится?
S>Ок, понятно всё кроме слова "заморозили". S>Вы уж меня простите, поскольку с SVN не работал, некоторые термины непонятны... (но подтянемся ))
Сode freeze, это общеупотребимый термин, к SVN не относится. Вообще, он на ваше усмотрение, но лучше бы что бы во время мержа никто не гадил в те ветки, которые мержат.
S>Опасения как всегда в незнании пока... Основное — это интеграция с VS. С точки зрения разработчика — как это выглядит? S>Как выглядит работа с SVN? Сейчас всё достаточно просто — сделали check-out в студии, поправили, сделали check-in. S>Всех делов.
S>Возможно, в SVN то же самое? А как выглядит, если есть несколько веток?
Честно говоря, не знаю как в плане интергации с VSS, всегда пользовались консольными клиентами.
Вероятно, это выглядит также, как в случае SS, просто будете выбирать, с каким бранчем работать.
Но по моему в случае неблокирующих VCS, интеграция с IDE практически не нужна — без нее можно легко
обходиться. А вот для мержа нужны, как правило, какие-то достаточно умные графические тулзы.
A>Что-ты зашел совсем с противоположной стороны... путаешь теплое с мягким....
Конечно, как всегда ))
A>Решение твоей задачи имеет 3 стади: A>1. понимание практик управления конфигурацией (сиречь СМа) A>2. умение работать с контретной системой контроля версий (SVN) A>3. возможность интегрировать с твоими тулами (VS), перенос исходников из одного места в другое (SVN->VSS)
Здесь не совсем согласен, поскольку для меня сейчас главное — это третья стадия по вашей классификации, поскольку если третья стадия нерешаема (т.е. интеграция проблематична, невозможна или сверхтрудоёмка), то вторая стадия в общем не нужна. Что касается первой стадии, здесь проблем особо нет с теорией.
A>Предложенная умным человеком книжка — решение 2 стадии проблемы . Она показывает как работать с конкретной системой контроля версий. A>То, что писал я — очень краткое описание самой 1 стадии. Очень краткое. 1-й стадии, т.е. концепция — как и когда правильно растить бранчи.
Спасибо.
A>Ты же интересуешься 3-й, последней стадлией, конкретными подробностями того, как тебе перейти с одного тула на другой.
Меня в первую очередь интересует даже не конкретные подробности, а опробованная возможность (для чего завёл отдельный топик
). Если таких примеров нет, то быть первопроходцем ледоколом желания, конечно же, тоже нет.
[SKIPPED]
A>P.S. А у вас отслеживание ошибок хоть как-то производится?
Xто вы имеете ввиду? Фиксация ошибок? Сообщения об ошибок от пользователей?
В принципе, есть и первое и второе. Первое — есть база ошибок, в которую записываются все ошибки системы автоматом. Второе — встроенная в основную систему подсистема, позволяющая заявить пользователю об ошибке с автоматической регистрацией контекста ошибки. Всё потом собирается в одно место и там обрабатывается... Надо будет подробнее — расскажу.
Здравствуйте, BulatZiganshin, Вы писали:
A>>При этом не надо искать магических тулзов для перегона из VSS в SVN. Выбираешь последнюю стабильную версию кода солюшена, загоняешь в SVN
BZ>а что делать с изменениями, сделанными после неё но до миграции?
Ну, поскольку они будут от неё отрощены — т.е. стабильные врсии файлов будут взяты на основу и просто поправлены — не составит труда отрастить бранчи уже в SVN и положить на них свои версии Мы ведь возьмем для миграции самую последнюю стабильную версию АКА метку
Это как раз самое простое во всей задаче
Здравствуйте, dmz, Вы писали:
S>>Опасения как всегда в незнании пока... Основное — это интеграция с VS. С точки зрения разработчика — как это выглядит? S>Как выглядит работа с SVN? Сейчас всё достаточно просто — сделали check-out в студии, поправили, сделали check-in. S>Всех делов.
S>>Возможно, в SVN то же самое? А как выглядит, если есть несколько веток?
dmz>Честно говоря, не знаю как в плане интергации с VSS, всегда пользовались консольными клиентами. dmz>Вероятно, это выглядит также, как в случае SS, просто будете выбирать, с каким бранчем работать.
Вот это как раз и интересно, поскольку я пока слабо себе представляю, как это выглядит даже в теории...
dmz>Но по моему в случае неблокирующих VCS, интеграция с IDE практически не нужна — без нее можно легко dmz>обходиться. А вот для мержа нужны, как правило, какие-то достаточно умные графические тулзы.
Как правильно сказали, "проблемы в головах разработчиков" Пока модель блокирующей VCS наоборот кажется в нашем случае более привлекательной, так как конкретным участком кода у нас в одно время работает один разработчик. Можно решать этот вопрос административно, конечно, как и делается в основном, поскольку все запросы на изменения проходят через одну "воронку", но блокировка — дополнительная защита (в контексте модели VSS).
dmz>Мы пользуемся gvimdiff, но есть много вариантов
Посмотрим, спасибо.
P.S. вообще, насколько я понимаю, модель разработки меняется в плане сборок — сейчас сборка может быть сделана в любой момент (в VSS всегда лежит последняя "законченная" весрия), а при использовании SVN предполагается специальная операция мерджа. Это тоже неплохо, поскольку точка фиксации релиза жёстче — это тоже хорошо...
К>К студии не прикручивал (давно ей непользуюсь), но видел плагин. К>А реально в своих проектах использую обычно tortoisesvn, который в проводник интегрирован. К>Основной финт на мой взгляд — в "нормальных" VCS файлы не блочатся эксклюзивно, т.е. действие "checkout" не является обязательным (как при "лоченьи" файлов)
В VSS такой режим тоже не является обязательным. Зависит от настроек сервера.
Но отсутствие бранчей ломает всю философию контроля версий
Подниму старую тему, так как она меня очень интересует
A>1. понимание практик управления конфигурацией (сиречь СМа)
... A>Итак: A>1. читаешь и проникаешься мыслью о бренности всего сущего и о важности отращивания веток. Прочитали, переварили, закрепили.
Где можно более углубленно почитать про политику создания веток, про способы их наименований? Да и вообще, было бы круто получить список бестпрактик работы с СВН (сцуко: написал вопрос, решил погуглить и нашел: Subversion Best Practices ).
У меня ситуация следующая:
Команда из 3-х человек. Разрабатываем вэб-приложение. SVN (пользуемся около года). Релизы каждый месяц (последняя пятница). Критические багфиксы и мелочевка (не требующая большого тестирования) могут деплоиться между релизами (благо деплой автоматизирован).
Работаем мы в одной ветке (trunk). Поэтому когда между релизом и хотфиксом проскакивает большой кусок (не до конца оттещенной) функциональности, то мы либо скрестя пальцы деплоим хотфикс вместе с новой функциональностью, либо объясняем заказчику, что этот фикс совсем не хот и вполне может потерпеть до релиза
Уже месяца 3-4 в голове крутиться мысль, что мы что-то делаем не так Что неплохо бы разделять задеплоенную ветку (в которую хотфиксить) и ветку текущей разработки, чтобы они друг другу не мешали. Идея не прижилась, так как не смогли составить четкого понимания того, как это будет работать и что именно мы должны делать.
Планировалось (в точности наоборот с тем, что советуют в этом топике ) в транке держать текущую разрабатываемую версию (т.е. как мы делаем сейчас), а после каждого релиза отпочковывать для него бранч. Тогда, если нужен хотфикс, в релизный бранч вносятся изменения, они деплоются, а потом мержуться с основной линией.
Здесь же (тут
) советуют в транке держать стабильную версию (готовую к релизу), а все фисы (критические и нет) производить в отдельных специально созданных ветках которые потом мержить на транк.
Не могу отдать предпочтения ни первому, ни второму варианту. Но так как здесь советуют второй он стал доминировать над первым ( ). Кроме того, на второй вариант хорошо ложиться CI сервер (которого еще нет, но в скором времени, надеюсь, будет установлен).
Хотелось бы узнать вашего мнения, уважаемые форумчане, но этот вопрос.
A>В твоем конкретном случае я бы сделал так:
Какая-то комбинация обоих вариантов получилась (со смещением к 2)
A>- ежемесячные релизы отпочковывал в отдельные теги АКА бранчи (в SVN метки — это и есть бранчи, так что буду называть их бранчами)
Что-то не догоняю, зачем отпочковывать релизы, если разработчики работают в своих ветках и мержат с транком только стабильный и оттещенный функционал. У нас ведь вэб-приложение, которое существует в единственном экземпляре (на сервере) и его не требуется распространиять клиентам. Ну задеплоится вместе с фиксом новая фича (стабильная, иначе ей нечего делать в транке), ну и что?
A>Когда разработчик сделал что-то, например фикс, и оттестировал — он подает изменения на транк. A>держание каждого фикса на отдельном бранче, пока он не понадобится в хотфикс-релизе или деплой-релизе.
Как-то непонятно когда же делать мерж с транком? После того как стабилизировали фикс или фичу, или же когда собрались ее релизить? Я, интуитивно, за первое.
A>Subversion Best Practices
В статье грамотно расписано про стратегии создания бранчей. Причем чел(-ы) (молодец(-цы)) не говорят, что подход Х просто крут и все остальные в лес, а дают три разных подхода к созданию веток: совсем без веток, ветка на каждое изменение и ветка по необходимости.
The Never-Branch system
(Often used by nascent projects that don't yet have runnable code.)
* Users commit their day-to-day work on /trunk.
* Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.
Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge. Cons: Chaotic development, code could be unstable at any time.
The Always-Branch system
(Often used by projects that favor heavy management and supervision.)
* Each user creates/works on a private branch for every coding task.
* When coding is complete, someone (original coder, peer, or manager) reviews all private branch changes and merges them to /trunk.
Pros: /trunk is guaranteed to be extremely stable at all times. Cons: Coders are artificially isolated from each other, possibly creating more merge conflicts than necessary. Requires users to do lots of extra merging.
The Branch-When-Needed system
(This is the system used by the Subversion project.)
* Users commit their day-to-day work on /trunk.
* Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
* Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
* Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.
Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare. Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.
Здравствуйте, Aikin, Вы писали:
A>В статье грамотно расписано про стратегии создания бранчей. Причем чел(-ы) (молодец(-цы)) не говорят, что подход Х просто крут и все остальные в лес, а дают три разных подхода к созданию веток: совсем без веток, ветка на каждое изменение и ветка по необходимости.
Заметь — они просто перечислили самые частоиспользуемые (типовые) подходы и назвали это Best Practices... Т.е. не сказали — этот лучший, но сказали — эти лучшие. Т.е. тебе остается выбрать тот, что подходит именно твоему проекту. На разных моих проектах применялись как "ветка на изменение", так и "ветка по необходимости" — в зависимости от задачи. Но чаще всего (да и сейчас на направлениии с использованием Clearcase) — использовался именно подходи "по ветке на изменение". Но совсем без веток — это бардак.
Здравствуйте, Aikin, Вы писали:
A>>В твоем конкретном случае я бы сделал так: A>Какая-то комбинация обоих вариантов получилась (со смещением к 2)
А идеала вообще не бывает. Процесс разработкии его инструментальная поддержка — они обтачиваются постоянно. Политики СМа (configuration management'а) — не исключение.
A>>- ежемесячные релизы отпочковывал в отдельные теги АКА бранчи (в SVN метки — это и есть бранчи, так что буду называть их бранчами) A>Что-то не догоняю, зачем отпочковывать релизы, если разработчики работают в своих ветках и мержат с транком только стабильный и оттещенный функционал. У нас ведь вэб-приложение, которое существует в единственном экземпляре (на сервере) и его не требуется распространиять клиентам. Ну задеплоится вместе с фиксом новая фича (стабильная, иначе ей нечего делать в транке), ну и что?
Важный момент — я написал метка АКА бранч. Важен именно факт выделения метки, т.е. бэйзлайна, для дальнейшей работы. В случае с SVN метка совпадает по реализации с веткой (так уж разработчики задумали). Если ты спроецируешь описанное на CVS, картина станет более понятной... Ключевое слово здесь — выделение и релиз бэйзлайна.
A>Как-то непонятно когда же делать мерж с транком? После того как стабилизировали фикс или фичу, или же когда собрались ее релизить? Я, интуитивно, за первое.
Верно. Мержите то, что считаете стабильным, т.е. то, что является приемлемого качества (например, проходит 98% тестов).
A>>Какая-то комбинация обоих вариантов получилась (со смещением к 2) A>А идеала вообще не бывает. Процесс разработкии его инструментальная поддержка — они обтачиваются постоянно. Политики СМа (configuration management'а) — не исключение.
Так я и отметил потому что это мне понравилось
A>Важный момент — я написал метка АКА бранч. Важен именно факт выделения метки, т.е. бэйзлайна, для дальнейшей работы. В случае с SVN метка совпадает по реализации с веткой (так уж разработчики задумали). Если ты спроецируешь описанное на CVS, картина станет более понятной... Ключевое слово здесь — выделение и релиз бэйзлайна.
Ну так не будет дальнейшей работы над этой веткой Зачем ее выделять?
A>Твой случай — решать тебе
Да, этим я и люблю альтернативы
В общем, для себя я решил использовать подход "ветка по необходимости" (что мы решим в команде -- вопрос отдельный): т.е. все мелкие фичи, багфиксы и прочая мелкота идут сразу в транк (предварительно протестированные на машине девелопера), а на крупные фичи будем отделять ветки, а потом мержить с транком. Делоиться на продакшен будет транк.
Мне кажется это естественный шаг от отсутствия бранчей (то что есть сейчас) к их наличию (чего хочется достичь).
Здравствуйте, Aikin, Вы писали:
A>>Важный момент — я написал метка АКА бранч. Важен именно факт выделения метки, т.е. бэйзлайна, для дальнейшей работы. В случае с SVN метка совпадает по реализации с веткой (так уж разработчики задумали). Если ты спроецируешь описанное на CVS, картина станет более понятной... Ключевое слово здесь — выделение и релиз бэйзлайна. A>Ну так не будет дальнейшей работы над этой веткой Зачем ее выделять?
Я говорил не о выделении ветки, а о выделении бэйзлайна... то, что в SVN метка — это ветка — это частный случай
Здравствуйте, Aikin, Вы писали:
A>Мне кажется это естественный шаг от отсутствия бранчей (то что есть сейчас) к их наличию (чего хочется достичь). A>Aquary, спасибо тебе большое за помощь.
A>Я говорил не о выделении ветки, а о выделении бэйзлайна... то, что в SVN метка — это ветка — это частный случай
Ну тогда я не понимаю разницы между ними. Это просто пометка (тэг)? Для истории? Можешь объяснить?
A>а не от непонятного транка, куда могли по ошибке засабмитить плохие изменения
В принципе понятно.
Хотя если на транк натравлен CI сервер и код достаточно хорошо покрыт тестами (важные его части), то о неработоспособности транка разработчики узнают практически сразу. А еще если наличие в транке рабочего кода проходящего все тесты является первостепенной задачей, то время нестабильности снижается до минимума (10-20 мин, ... ну час).
Здравствуйте, Aikin, Вы писали:
A>Хотя если на транк натравлен CI сервер и код достаточно хорошо покрыт тестами (важные его части)
Что ты будешь без такого бранча, когда в процессе создания новой версии вдруг обнаружится критическая бага и потребуется написать и выпустить хотфикс как можно раньше?
A>>Хотя если на транк натравлен CI сервер и код достаточно хорошо покрыт тестами (важные его части) O>Что ты будешь без такого бранча, когда в процессе создания новой версии вдруг обнаружится критическая бага и потребуется написать и выпустить хотфикс как можно раньше?
Хотфиксим на транке. В чем проблема?
Нет, я понимаю, что наличие релизного бранча дает некоторые преимущества, но есть у него и недостатки как "путаница" с ветвями, лишие "мержи", (может еще что)... Чисто интуитивно, плюсов меньше чем минусов.
Здравствуйте, Aikin, Вы писали:
A>Хотфиксим на транке. В чем проблема?
Проблема в том, что выпустить хотфикс вы не сможете раньше, чем закончите работу над новой версией, т.к. на транке будут лежать новые фичи из нее.
O>Проблема в том, что выпустить хотфикс вы не сможете раньше, чем закончите работу над новой версией, т.к. на транке будут лежать новые фичи из нее.
Перечитайте всю тему плиз, а точнее: Re[14]: Управление ветками. Практики. Метрики...
ЩЕ>При обсуждении различных стратегий работы с бранчами авторы многих топиков (вот как и данный автор) указывают на то, что после того, как закончена разработка, идет операция мержа и лишь затем ревью, тестирование и т.п.
... ЩЕ>У нас слияние происходит только тогда, когда внутри бранча уже пройдены все стадии ревью, которые необходимы, билдовая машина сделала успешный пробный билд из этого бранча, на этом бранче успешно были выполнены все автоматические тесты и т.п. Т.е. именно в тот момент когда бранч готов к слиянию настолько, что вероятность развалить основную ветку сводится к минимуму — именно тогда осуществляется слияние. И цель всего этого процесса — качество.
Камрад, я не совсем понял — чем описанное тобой отличается от того, что написал выше я ("данный автор")?.. Это достаточно стандартный подход — проревьюить и протестировать до мержа с основным релизом. То, что в МС ревью происходит после мержа — ещё не означает, что так должны делать все.
Комрады, вот я задумался над тем как закрывать бранч.
Полазил по докам и по списку доступных команд и оказалось что ближе всего закрытию соответствует удаление этой ветки нафик. Прав ли я? Или есть более цивилизованный вариант закрытия ветки?
Здравствуйте, Ziaw, Вы писали:
A>>Полазил по докам и по списку доступных команд и оказалось что ближе всего закрытию соответствует удаление этой ветки нафик. Прав ли я? Или есть более цивилизованный вариант закрытия ветки? Z>Копирование в completed_branches и удаление?
А зачем ее копировать в completed_branches? Типа для истории? Так у нас же есть история ревизий...
Здравствуйте, Aikin, Вы писали:
Z>>Копирование в completed_branches и удаление? A>А зачем ее копировать в completed_branches? Типа для истории? Так у нас же есть история ревизий...
В транке остается история только одной ревизии, когда был выполнен merge. Возможно будет интересен лог самого бранча.
Здравствуйте, Ziaw, Вы писали:
Z>Впрочем чегото я туплю, после удаления история останется.
Да, я именно про это. Короч бум удалять Спасибо.
Z>Жара, усталость, два дня до отпуска...
Завидуюмс. Самому надо
Здравствуйте, Aikin, Вы писали:
A>Комрады, вот я задумался над тем как закрывать бранч.
A>Полазил по докам и по списку доступных команд и оказалось что ближе всего закрытию соответствует удаление этой ветки нафик. Прав ли я? Или есть более цивилизованный вариант закрытия ветки?
Камрад, странного хочешь... Что вообще значит "закрыть бранч"? Есть у тебя бранч, на нём версии... ну и пусть живет... Место экономишь?
Здравствуйте, Aquary, Вы писали:
A>Камрад, странного хочешь... Что вообще значит "закрыть бранч"? Есть у тебя бранч, на нём версии... ну и пусть живет... Место экономишь?
Да где-то начитался (сейчас вон найти не могу), что работа с бранчем идут так:
— отрастил
— изменил
— закомитил
— изменил
— закомитил
— изменил
— закомитил
...
-- смержил с транком
-- закрыл бранч // вот про это я и задумался
Смысл в том, чтобы он не болтался в папке branches ибо через год в этой папке будет "тысчимильенов" бранчей -- хрен что разберешь в этой свалке, а если удалять, то будут только актуальные ветки болтаться.
Здравствуйте, Aquary, Вы писали:
A>Камрад, я не совсем понял — чем описанное тобой отличается от того, что написал выше я ("данный автор")?.. Это достаточно стандартный подход — проревьюить и протестировать до мержа с основным релизом. То, что в МС ревью происходит после мержа — ещё не означает, что так должны делать все.
Наверное невнимательно прочитал. Но вопрос собственно остается — во многих источниках, в том числе и в МС пишут, что поводом использовать технологию бранчевания должна служить необходимость группам разработки параллельно работать над одним и тем же набором файлов. Насколько это справедливо? Вот в моем выше описанном случае это не так.
Здравствуйте, Aikin, Вы писали:
A>Да где-то начитался
Как найдешь — приходи..
A>Смысл в том, чтобы он не болтался в папке branches ибо через год в этой папке будет "тысчимильенов" бранчей -- хрен что разберешь в этой свалке, а если удалять, то будут только актуальные ветки болтаться.
Ну и ладно... для того и нужны системы контроля версий — чтобы всё это хранить...
Не нравится захламление папки branches — переходи на CVS, там идеология работы с бранчами и метками другая.
Здравствуйте, Щербатов Евгений, Вы писали:
ЩЕ>Наверное невнимательно прочитал. Но вопрос собственно остается — во многих источниках, в том числе и в МС пишут, что поводом использовать технологию бранчевания должна служить необходимость группам разработки параллельно работать над одним и тем же набором файлов. Насколько это справедливо? Вот в моем выше описанном случае это не так.
Вообще, обеспечение параллельности разработки — это одна из задач CM'а (configuration management'а). Подчеркиваю — одна из, т.е. этим дело не заканчивается. Это я тебе как СМ-инженер говорю
Здравствуйте, Aquary, Вы писали:
A>>Да где-то начитался A>Как найдешь — приходи..
Сразу не смог найти и было подумал, что это у меня глюк какой произошел.
А сегодня мержил две ветки, углубился в документацию к Черепаше и нашел слудеющее:
Reintegrate a branch
After the merge, all branch development has been completely merged back into the main development line. The branch is now redundant and can be deleted.
In this case you will not need the feature branch again because the new feature is now integrated into the trunk. The feature branch is redundant and can be deleted from the repository if required.
А это у меня болталось с попытки ответить
A>>Смысл в том, чтобы он не болтался в папке branches ибо через год в этой папке будет "тысчимильенов" бранчей -- хрен что разберешь в этой свалке, а если удалять, то будут только актуальные ветки болтаться. A>Ну и ладно... для того и нужны системы контроля версий — чтобы всё это хранить...
Ну так в то-то и дело, что при удалении бранча (папки) в N-ой ревизии она не будет болтаться в следующих, но просмотреть изменения сделанные (если такое понадобится) в ней будет возможно, так как SVN ведет историю изменений.
Т.е. данные хранятся, но в прошлых ревизиях -- поэтому не болтаются под ногами.
A>Не нравится захламление папки branches — переходи на CVS, там идеология работы с бранчами и метками другая.
Так вот сразу и на CVS
Здравствуйте, Aquary, Вы писали:
A>Типичный сценарий работы такой (упрощенно):
A>- девелоперы делают изменения — отращивают девелопмент-бранч от релиз-бранча. A>- когда кто-то из них считает, что изменения пофиксили багу или внесены нужные изменения но новой фиче — он мержит их с последней имеющейся стабильной версией (если она изменилась со времени отращивания) и отдает на ревью A>- проходит ревью кода (или не проходит — тогда огрехи исправляются) A>- код отстраивается и тестируется A>- если тесты проходят, бага пофиксена, и новых багов не внесено — код считается стабильным A>- стабильный код мержится на релиз-бранч и метится релизной меткой
A>Фух... это вкраце, упрощенно, под твою ситуацию.
Это для двух-то разработчиков?! Да вы батенька шутник, однако.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Aquary, Вы писали:
A>>Типичный сценарий работы такой (упрощенно):
S>Это для двух-то разработчиков?! Да вы батенька шутник, однако.
Это общая схема работы с помощью бранчей. С уменьшением команды и упрощением процесса разработки каие-то практики будут лишними, само собой...
Мы уже победили, просто это еще не так заметно...
). Бэйзлайн — это основа для дальнейшей разработки, а также для поставки стабильных версий продуктов заказчику. Т.е. выделив бэйзлайн (неважно как — навешиванием метки в CVS или отбранчеванием тэга в SVN), ты говоришь — вот код, который я считаю стабильным, который прошел тестирование и показал достаточный (для данного проекта и этапа работы) уровень пройденных тестов, и может быть использован как основа для дальнейшей разработки. Далее этот стабильный релиз может оправится заказчику, может пока приежаться. В любом случае — разработчики могут брать его как эталон и базу. Эталон — потом что он стабилен и любая поломка функционала будет видна на его фоне. Как базу — потому что имено от него можно отращивать свои изменения (а не от непонятного транка, куда могли по ошибке засабмитить плохие изменения).
Что неплохо бы разделять задеплоенную ветку (в которую хотфиксить) и ветку текущей разработки, чтобы они друг другу не мешали. Идея не прижилась, так как не смогли составить четкого понимания того, как это будет работать и что именно мы должны делать.
