Mercurial/GIT

[Strannik]

снова про сорс контрол

кто-нибудь пользуется меркуриал или гит?

если да, то каким образом код добирается в продакшн? используются бранчи, или клоны мастер репо? есть ли возможность выпускать в продакшн отдельные фичи? например задевелопили фичи X, Y, Z для релиза, бизнес сказал что Y они пока не хотят. как лучше всего придержать Y.

на данный момент в SVN все решается патчами в релиз бранч, интересует возможно ли это облегчить в меркуриал

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

[xelaz]

кто-нибудь пользуется меркуриал или гит?

Последнее что я пользовался - был Гит. (Системка получше SVN будет, главным образом за возможность вносить отдельные изменения в файле, но не весь файл)

если да, то каким образом код добирается в продакшн?

у нас все фонарно было - финны делали код у себя, там же отслеживали в гите. Я гит держал только для себя, отслеживал их изменения и свои. В двух рахных главных бранчах. Это далеко не лучшее использование, конечно, и код передавался в зип файлах, что есть, конечно, позор.

используются бранчи, или клоны мастер репо? есть ли возможность выпускать в продакшн отдельные фичи? например задевелопили фичи X, Y, Z для релиза, бизнес сказал что Y они пока не хотят. как лучше всего придержать Y.

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

В целом же идея такая - на каждую фичу делается отдельная ветка, которая постоянно синхронизируется с основной (т.е. основная мерджится в бранчи дабы бранчи был всегда последней версии. Изменения бранча придерживаются в бранче и в основную не сливаются). Если нужно релиз сделать с набором фич - все нужные бранчи плюс основная ветка мерджатся в релизную, либо в основную.
Т.е ветка Y содержит те самые изменения которые нужно придержать.

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

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

[Strannik]

да вот и у меня такое чуство что придется использовать фичеветки....

у нас основная система сейчас SVN но на проекте используем Mercurial в виде эксперимента. вот пытаюсь понять позволит(поможет) ли он нам делать то что планируется.

про модульность кода - это отдельная проблема, если все свалено в кучу то тут никакая система сорс контроля не поможет

[xelaz]

да вот и у меня такое чуство что придется использовать фичеветки....

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

[Strannik]

feature toggles уже есть в принципе все major releases делаются таким способом, так как код с транка каждые 6 недель идет в продакшн.

но цель стоит иметь возможность выпускать код в продакшн каждый день, а тут feature switches создаст слишком много геморроя.

пока для решения это задачи используются патчи, т.е девелопер кодит на транке, после получения отмашки от бизнеса код патчится в релиз бранч, делается sanity test и релизится, но это не sustainable long term

[Karadur]

Гит сильно лучше Свна, особено когда речь идёт о бранчах и слиянии бранчей.

[Strannik]

мы по ряду причин выбрали mercurial, но принцип там тот же