Надоело краснеть за дурацкие баги в daily builds нестабильного trunk, к тому же из-за специфики проекта приходится много времени тратить на проверку багрепортов. Хочется для тестирования выкладывать что-то постабильнее.
Возникают вопросы.
Во-первых, так как многие задачи занимают месяцы, то напрашивается вывод, что стабильная и девелоперская ветки будут существовать параллельно по 6-12 месяцев (время между релизами). Не приведет ли это к глубокой дестабилизации девелоперской ветки? Как с этим бороться? Каждый месяц заводить новую девелоперскую ветку из стабильной?
Во-вторых, как организовать merging кода в стабильную ветку, а именно, каждый сливает свои коммиты, или это делает только специально обученный сотрудник?
Здравствуйте, Xentrax, Вы писали:
X>Есть много кода, который активно меняется. X>Во-первых, так как многие задачи занимают месяцы, то напрашивается вывод, что стабильная и девелоперская ветки будут существовать параллельно по 6-12 месяцев (время между релизами). Не приведет ли это к глубокой дестабилизации девелоперской ветки? Как с этим бороться? Каждый месяц заводить новую девелоперскую ветку из стабильной?
Код, который *весь* активно меняется — это из серии "Люблю, когда народ тусуется". Слона надо есть по кусочкам, всегда сохраняя стабильную часть.
Полгода на feature branch — многовато.
X>Во-вторых, как организовать merging кода в стабильную ветку, а именно, каждый сливает свои коммиты, или это делает только специально обученный сотрудник?
Вообще это зависит от существующей культуры и процессов в команде.
Мне нравится идеология ветка на задачу.
Интеграция в транк делает тот, кто ответственен за приемку задачи и код ревью.
Таким образом в транке всегда проверенный и стабильный код ( более менее ).
Для тестов или отращивается ветка или просто помечается тегом(меткой) какая либо ревизия.
Здравствуйте, Xentrax, Вы писали:
X>Во-первых, так как многие задачи занимают месяцы, то напрашивается вывод, что стабильная и девелоперская ветки будут существовать параллельно по 6-12 месяцев (время между релизами). Не приведет ли это к глубокой дестабилизации девелоперской ветки? Как с этим бороться? Каждый месяц заводить новую девелоперскую ветку из стабильной?
X>Во-вторых, как организовать merging кода в стабильную ветку, а именно, каждый сливает свои коммиты, или это делает только специально обученный сотрудник?
То, что Вы описываете, называется Fеature branch, ветка на каждую задачу.
Отмечу самый главный ньюанс, который Вас касается — рекомендуется, что задача должна быть короткой. У Вас же получается месяцы на задачу. В принципе можно по всякому работать, возможно, в Ваших условиях это оптимальный сценарий.
По своему опыту замечу, что длинные задачи вызывают проблемы со слиянием веток, чем длиннее задача, тем больше проблемы.
Поэтому мы предпочитаем работать в trunk по максимуму, делая ветки лишь по необходимости. Однако, у нас из методологий используются SCRUM + TDD, что означает:
1) Версии выпускаются часто
2) Задачи покрыты unit-тестами
3) Есть еще и интеграционные тесты.
Т.е. длинных задач в отдельных ветках у нас в принципе не бывает ( и вообще длинных задач в месяцы), в trunk, как правило, попадает только хорошее, сейчас вот введем практику Continious Integration и после каждого commit в trunk будет запускаться сборка с основными тестами, в случае ошибок будет происходить "раздача слонов", что, надеемся, еще более улучшит качество trunk.
Я бы рекомендовал, если будете использовать Feature Branch
1) по мере возможности укоротить задачи, почаще интегрируясь со стабильной веткой. Т.е. длинная задача бьется на подзадачи, подзадачи по мере стабилизации сбрасываются в trunk, и их ветки удаляются.
2) Внедрить тестирование по commit в стабильную ветку. Или хотя бы компиляцию и сборку всего проекта.
Здравствуйте, Xentrax, Вы писали:
X>Возникают вопросы.
Тут камрад уже засылал ссылочку на перевод из моего блога. Обнаглею совсем и посоветую целую подборку статей, посвященную как основам SCM, как и ветвлению/слиянию. Специально свел их на одну страничку, чтобы удобно было читать от основ к более развернутым вещам.
Ну просто всё, что можно было бы здесь написать — там уже есть.
Две первые ссылки, когда перейдешь по указанной ссылке — это статьи на самом RSDN, так что далеко ходить не надо
Здравствуйте, Xentrax, Вы писали:
X>Есть много кода, который активно меняется.
X>Надоело краснеть за дурацкие баги в daily builds нестабильного trunk, к тому же из-за специфики проекта приходится много времени тратить на проверку багрепортов. Хочется для тестирования выкладывать что-то постабильнее.
X>Возникают вопросы.
X>Во-первых, так как многие задачи занимают месяцы, то напрашивается вывод, что стабильная и девелоперская ветки будут существовать параллельно по 6-12 месяцев (время между релизами). Не приведет ли это к глубокой дестабилизации девелоперской ветки? Как с этим бороться? Каждый месяц заводить новую девелоперскую ветку из стабильной?
X>Во-вторых, как организовать merging кода в стабильную ветку, а именно, каждый сливает свои коммиты, или это делает только специально обученный сотрудник?
Здравствуйте, Xentrax, Вы писали:
X>Надоело краснеть за дурацкие баги в daily builds нестабильного trunk, к тому же из-за специфики проекта приходится много времени тратить на проверку багрепортов. Хочется для тестирования выкладывать что-то постабильнее.
Надоело — не краснейте. Как говорится, глупый пингвин робко прячет, умный — смело достаёт. Транк — на то и транк, чтобы в нём ловилось всё, что нужно, без необходимости краснеть. Краснеть надо уже за стабильные ветки.
"Много времени на проверку багрепортов" часто означает, что плохо устроено тестирование в своей среде. Больше используйте юниттесты, локальные и групповые функциональные тесты, интеграционные тесты. В идеале, каждый найденный баг должен быть обложен на будущее тестом какого-то из этих видов. Это же позволит и как можно раньше ловить "дурацкие баги", потому что простое make blackbox или make functest в проекте позволит выловить их заметную часть.
X>Во-первых, так как многие задачи занимают месяцы, то напрашивается вывод, что стабильная и девелоперская ветки будут существовать параллельно по 6-12 месяцев (время между релизами). Не приведет ли это к глубокой дестабилизации девелоперской ветки? Как с этим бороться? Каждый месяц заводить новую девелоперскую ветку из стабильной?
Бороться — административно и технически. Крупные изменения должны быть специально проверены и явно одобрены перед включением в девелоперские ветки; они должны быть разработаны в своих ветках и добавлены в общие только по какому-то явному успеху. Не надо бояться полного разноса, но надо периодически "освежать" такие целевые ветки общими изменениями — чтобы заранее выявлять логические и кодовые конфликты.
X>Во-вторых, как организовать merging кода в стабильную ветку, а именно, каждый сливает свои коммиты, или это делает только специально обученный сотрудник?
Лучше — каждый. Потому что он лучше знает, с чем и как может конфликтовать его коммит, нужно ли для слияния сделать что-то специфическое. Но решать, что можно и когда сливать, должен менеджер.
Стабильные ветки от своего рождения должны получать политику, что в них можно делать. Наиболее простой и практичный метод — ограничение активности по времени. На одной из моих работ это называется — зелёная, жёлтая и красная зона. Во FreeBSD, например, жёлтая — это code slush, красная — code freeze. Смысл в том, что в жёлтой зоне запрещены мержи новых фич, можно только лечить баги; в момент начала жёлтой зоны для ветки на неё напускается полный цикл тестов QA отдела (это не те тесты, что у программистов, это именно полевые испытания на живых установках). Красная зона — разрешаются только фатальные фиксы функциональности и фиксы защиты, при этом каждый коммит должен быть одобрен менеджером. По выпуску релиза на ветке она размораживается, но это не значит, что можно мержить всё подряд — в конце концов, ветки релизов значат не только внутреннее устройство, но и внешние связи, которые ломать без предупреждения — значит вредить всем.
Энное количество хороших статей по управлению ветками разработки есть, например, на хабре.
Здравствуйте, rlabs, Вы писали:
R>Код, который *весь* активно меняется — это из серии "Люблю, когда народ тусуется". Слона надо есть по кусочкам, всегда сохраняя стабильную часть. R>Полгода на feature branch — многовато.
У меня была фича, которая тянулась года два. Но таки да, ели по кусочкам — собирались логические микрореформы и затем они выливались в общие ветки, а в этой ветке готовилась следующая реформа.
Здравствуйте, netch80, Вы писали:
N>У меня была фича, которая тянулась года два. Но таки да, ели по кусочкам — собирались логические микрореформы и затем они выливались в общие ветки, а в этой ветке готовилась следующая реформа.
Пардон, а что такое "реформа" в данном случае? Релиз? Стабильная конфигурация? Baseline? Впервые слышу подобный термин в разрезе управления конфигурацией
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>У меня была фича, которая тянулась года два. Но таки да, ели по кусочкам — собирались логические микрореформы и затем они выливались в общие ветки, а в этой ветке готовилась следующая реформа.
A>Пардон, а что такое "реформа" в данном случае? Релиз? Стабильная конфигурация? Baseline? Впервые слышу подобный термин в разрезе управления конфигурацией
Реформа — это крупная переделка. Например, рефакторинг с выворотом логики наизнанку.
К управлению конфигурацией это действительно не имеет отношения.
Здравствуйте, netch80, Вы писали:
N>Бороться — административно и технически. Крупные изменения должны быть специально проверены и явно одобрены перед включением в девелоперские ветки; они должны быть разработаны в своих ветках и добавлены в общие только по какому-то явному успеху. Не надо бояться полного разноса, но надо периодически "освежать" такие целевые ветки общими изменениями — чтобы заранее выявлять логические и кодовые конфликты.
Не очень понятно, откуда их освежать, если общие изменения сидят по целевым веткам и ждут явного успеха ?
Здравствуйте, maxim.ge, Вы писали:
MG>Здравствуйте, netch80, Вы писали:
N>>Бороться — административно и технически. Крупные изменения должны быть специально проверены и явно одобрены перед включением в девелоперские ветки; они должны быть разработаны в своих ветках и добавлены в общие только по какому-то явному успеху. Не надо бояться полного разноса, но надо периодически "освежать" такие целевые ветки общими изменениями — чтобы заранее выявлять логические и кодовые конфликты.
MG>Не очень понятно, откуда их освежать, если общие изменения сидят по целевым веткам и ждут явного успеха ?
Ну некоторые-то уже смержены в общие ветки? Вот их и надо в остальные целевые, чтобы ловить текстовые и логические конфликты.
Здравствуйте, netch80, Вы писали:
N>Ну некоторые-то уже смержены в общие ветки? Вот их и надо в остальные целевые, чтобы ловить текстовые и логические конфликты.
Вот тут возникает вопрос — если есть юниттесты, локальные и групповые функциональные тесты, то почему бы их срабатывание не считать признаком "явного успеха" ? Т.е. написал код, прогнал тесты, получил "зелень" => слился со стабильной веткой. И то же самое делают остальные целевые, чтобы ловить текстовые и логические конфликты. Вот так, иными словами
Здравствуйте, Aquary, Вы писали:
A>Не забываем, что цитируемый Фаулер — приверженец continuous integration. Стало быть, не всем его аргументы подойдут.
Совершенно согласен. Однако, если имеются озвученные "юниттесты, локальные и групповые функциональные тесты, интеграционные тесты" то применение практики CI прямо-таки напрашивается.
Здравствуйте, maxim.ge, Вы писали:
MG>Здравствуйте, netch80, Вы писали:
N>>Ну некоторые-то уже смержены в общие ветки? Вот их и надо в остальные целевые, чтобы ловить текстовые и логические конфликты.
MG>Вот тут возникает вопрос — если есть юниттесты, локальные и групповые функциональные тесты, то почему бы их срабатывание не считать признаком "явного успеха" ? Т.е. написал код, прогнал тесты, получил "зелень" => слился со стабильной веткой. И то же самое делают остальные целевые, чтобы ловить текстовые и логические конфликты. Вот так, иными словами
В общем-то обычно так и делается — реализованная и проверенная тестами фича вливается в общий поток. По крайней мере везде, где я работал, было именно так. Есть административный вопрос — какие тесты считать достаточными — но он решается относительно легко.
Проблема возникает дальше — когда у тебя возникает вести необходимость формально у одной версии вести несколько "потоков" разработки с разными свойствами — обычно это называется trains (и как это блин перевести?). Например, этим сильно отличилась Cisco: у Cisco IOS есть обычный трейн (типа по умолчанию), T, T1, T2 (эти тестовые для новых фич), S, SX, SR... — эти, наоборот, ориентированы на стабильность (S — от service provider)... Основная проблема — в разделении изменений — какие из них можно "оторвать" от прочих в ветке, выделить отдельно и протестировать. Тут регулярно натыкаешься на недоработки и взаимовлияния, приходится догонять другими вещами, которые не планировались... вот тут собственно нужно умение выделить логические связи и избежать лишнего.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, maxim.ge, Вы писали:
MG>> Вот так, иными словами
A>Не забываем, что цитируемый Фаулер — приверженец continuous integration. Стало быть, не всем его аргументы подойдут.
Так не требуется доводить применение чужих техник до абсурда. Вообще, по отношению к любой подобной методике работает один общий метод — проверить на соответствие задаче... может, она вообще из другого мира (по Joel'у)
Здравствуйте, netch80, Вы писали:
N>Так не требуется доводить применение чужих техник до абсурда. Вообще, по отношению к любой подобной методике работает один общий метод — проверить на соответствие задаче... может, она вообще из другого мира (по Joel'у)
Тут с ним согласен. Сам не устаю повторять — инструмент и процесс всегда выбираются под задачу.
