Comments 26
>что полностью противоречит приципу Continuous Integration («постоянная интеграция»).
Вы хоть и настаиваете на том, что фича-ветки — это зло, все равно я не понимаю этот ваш аргумент. Я считаю, что постоянная интеграция — не самоцель, нужен баланс. Слишком часто интегрировать все (как например происходит при работе с транком) — плохо, так как разработчики мешают друг другу и вместо того, что бы разбираться в реальных проблемах интеграции, разбираются с чужими мелкими багами.
Потом совершенно не понятно как реализовать сценарий отката фичи, когда нужно будет сделать релиз, но какую-то фичу не релизить.
Вы хоть и настаиваете на том, что фича-ветки — это зло, все равно я не понимаю этот ваш аргумент. Я считаю, что постоянная интеграция — не самоцель, нужен баланс. Слишком часто интегрировать все (как например происходит при работе с транком) — плохо, так как разработчики мешают друг другу и вместо того, что бы разбираться в реальных проблемах интеграции, разбираются с чужими мелкими багами.
Потом совершенно не понятно как реализовать сценарий отката фичи, когда нужно будет сделать релиз, но какую-то фичу не релизить.
С чужими мелкими багами рано или поздно придется разбираться.
Разработчики (чем опытнее, тем охотнее) стремятся обособиться от «чужих мелких багов» и зачастую перекладывают задачу интеграции их feature-брэнчей на новичков или менее оплачиваемых коллег.
В резльтате когда речь идет о преимуществах и недостатках feature-бренчей они зачастую не понимают о чем идет речь, поскольку трудности риск и ответственность за интеграцию не лежит на их славных плечах.
Классический ответ на второй вопрос: разрабатывать фитчи в транке и держать их деактивированными до тех пор, пока они не будут готовы к релизу. Обычно такой ответ вызывает реакцию вроде «ну да… слыхали эти сказки, такое работает только на бумаге». А вот с недавних пор в моем проекте делаем именно так, и ничего страшного не случилось, даже наоборот, как бы забесплатно получили «фитчу» включать и отключать фитчи произвольно уже после выпуска, в некоторых случаях даже в рантайме.
В реальности не слышал об успешных случаях применения feature-бренчей (без кошмара интеграции и проваленных сроков) для подготовки релиза с произвольным набором фитч и тем более их последющего отката.
Разработчики (чем опытнее, тем охотнее) стремятся обособиться от «чужих мелких багов» и зачастую перекладывают задачу интеграции их feature-брэнчей на новичков или менее оплачиваемых коллег.
В резльтате когда речь идет о преимуществах и недостатках feature-бренчей они зачастую не понимают о чем идет речь, поскольку трудности риск и ответственность за интеграцию не лежит на их славных плечах.
Классический ответ на второй вопрос: разрабатывать фитчи в транке и держать их деактивированными до тех пор, пока они не будут готовы к релизу. Обычно такой ответ вызывает реакцию вроде «ну да… слыхали эти сказки, такое работает только на бумаге». А вот с недавних пор в моем проекте делаем именно так, и ничего страшного не случилось, даже наоборот, как бы забесплатно получили «фитчу» включать и отключать фитчи произвольно уже после выпуска, в некоторых случаях даже в рантайме.
В реальности не слышал об успешных случаях применения feature-бренчей (без кошмара интеграции и проваленных сроков) для подготовки релиза с произвольным набором фитч и тем более их последющего отката.
Мне кажется вы наступаете на те же грабли, что и мне довелось наступать: вы что-то пробовали и из того, что это у вас не получилось, делаете вывод, что подход не работает. Я уже в нескольких проектах работал по фича-бранч схемы, ничего описанного вами не встречал. Про то, что с чужими мелкими багами придется все равно разбираться вообще не понял: при фича бранч схеме интегрируются уже боле менее стабильные, протестированные разработчиком бранчи. Практика показывает, что фича — штука обособленная, вероятность конфликтов небольшая. Я вам расскажу больше, на одном проекте бранчи интегрировались автоматически скриптом, который вызывал тестировщик и это в 90% случаев работало, в остальных 10% процентах разработчику предлагалось поребейсить свой код на дев-ветку, в которую уже намержили других задач.
Насчет решения с деактивацией кода: это работает далеко не всегда, иногда просто декативировать нельзя, но этот подход тоже используем, он никак не противоречит фича-бранч схеме. Если деактивировать возможно, то это конечно проще, чем реверт мержа, в этом случае выбор будет за деактивацией.
Насчет решения с деактивацией кода: это работает далеко не всегда, иногда просто декативировать нельзя, но этот подход тоже используем, он никак не противоречит фича-бранч схеме. Если деактивировать возможно, то это конечно проще, чем реверт мержа, в этом случае выбор будет за деактивацией.
Моя практика показывает другое. Для начальства фитчей может быть что угодно, вплоть до полной переделки программы. Не разработчки определяют, что такое фитча. Вам должно быть везло.
Если Ваша фитча — штука обосбленная, то бренч вам видимо нужен, чтобы не нести отвественность за «чужие мелкие баги».
Представляю такую разработку: Вы, как опытный специалист, обосбливаетесь в своем фитче-бренче, отлаживаете его, запускаете, проверяете аккуратно локально, потом мерджите в транк, а там «чужие мелкие баги» (если их нет, зачем бренч?). И тогда вы со спокойной душой говорите: «это не мой баг, глядите, у меня в фитче-бранче все работает, разбираетесь там сами».
Я за то, чтобы не позволять девелоперам занимать такую позицию.
Если Ваша фитча — штука обосбленная, то бренч вам видимо нужен, чтобы не нести отвественность за «чужие мелкие баги».
Представляю такую разработку: Вы, как опытный специалист, обосбливаетесь в своем фитче-бренче, отлаживаете его, запускаете, проверяете аккуратно локально, потом мерджите в транк, а там «чужие мелкие баги» (если их нет, зачем бренч?). И тогда вы со спокойной душой говорите: «это не мой баг, глядите, у меня в фитче-бранче все работает, разбираетесь там сами».
Я за то, чтобы не позволять девелоперам занимать такую позицию.
Да и не agile это по фитча-бренчам обосабливаться.
Как по мне, если используете git, то бренчте локально сколько хотите, но в центральном репозитории количество живых ветвей надо держать минимальным.
Как по мне, если используете git, то бренчте локально сколько хотите, но в центральном репозитории количество живых ветвей надо держать минимальным.
Вы тогда теряете вообще самую мощь фича-бранч схемы — переход от push разработки к pull, когда не разработчик мержит фича-бранчи, а тот, кто собирает релиз вмерживает нужные ветки. Перед мержем еще можно делать ревью кода. Тогда транк из помойки с непонятно каким состоянием превращается в нечто готовое к релизу, при желании (это если отдавать фича бранч ветку на QA перед мержем, а на транк только смок-тест, что бы проверить что интеграция прошла успешна). Посмотрите как на гитхабе сделаны pull-request-ы. Мы кстати и через гитхаб работали, очень круто получается. Делаешь фичу в бранче, после окончания пул-реквест, далее лид ревьюит diff и аппрувит.
Что ж, Ваш процесс разработки более напоминает open source.
За мерджы выходит ответственен тим-лид (лучше, чем в моем сценарии-страшилке).
А CI вы для каждой фитче-ветки отдельно настраиваете?
Потому что так получается, что фитча-бранч начинает играть роль нормального транка команды, которая над ним работает. А транк служит скорее средством code review.
За мерджы выходит ответственен тим-лид (лучше, чем в моем сценарии-страшилке).
А CI вы для каждой фитче-ветки отдельно настраиваете?
Потому что так получается, что фитча-бранч начинает играть роль нормального транка команды, которая над ним работает. А транк служит скорее средством code review.
И еще интересно, как вы при этом раздаете версии и проводите стейджинг.
> а там «чужие мелкие баги» (если их нет, зачем бренч?).
Ды их нет только за счет того, что в главную ветку мержать только стабильные фича-бранчи. Не было бы фича-бранчей, были бы чужие мелкие баги.
Ды их нет только за счет того, что в главную ветку мержать только стабильные фича-бранчи. Не было бы фича-бранчей, были бы чужие мелкие баги.
>Не разработчки определяют, что такое фитча. Вам должно быть везло.
Да, мы перед планированием итерации делаем декомпозицию бизнес-задачи на ветки и оцениваем каждую фичу.
Да, мы перед планированием итерации делаем декомпозицию бизнес-задачи на ветки и оцениваем каждую фичу.
Что касается opensource-проектов, то они как правило завязаны очень жестким BC-контрактом, отсюда меньше пространства для рефакторинга, поэтому и изменения можно применять более постепенно.
А во внутренних проектах разработчики вольны делать все, до чего договорятся, а некоторые изменения просто не предполагают пошаговости — патчсет может быть очень большим, его ревью и доработки могут идти не один месяц. До окончания ревью мержить это крайне нежелательно. Согласен, когда идет параллельная разработка в trunk, его будет сложнее смержить, но для этого есть регулярный rebase. И, как верно заметил dborovikov, как откатить фичу полностью в случае чего?
А во внутренних проектах разработчики вольны делать все, до чего договорятся, а некоторые изменения просто не предполагают пошаговости — патчсет может быть очень большим, его ревью и доработки могут идти не один месяц. До окончания ревью мержить это крайне нежелательно. Согласен, когда идет параллельная разработка в trunk, его будет сложнее смержить, но для этого есть регулярный rebase. И, как верно заметил dborovikov, как откатить фичу полностью в случае чего?
Неразбериха с версиями происходит уже на этом этапе, поскольку одному и тому же артефакту теперь соответствуют две ревизии в VCS.При этом Вы предлагаете отказаться от SNAPSHOT, либо я неправильно что-то понял. Разве это не породит неразбериху с версиями? Если уж так важно различать каждую сборку, то в maven 3 поведение по умолчанию так и есть — не может быть двух SNAPSHOT-артефактов одной версии, они должны различаться timestamp'ом.
OpenSource прокты, согласен, отличаются от proprietary во многом.
Мои рассуждения годны скорее для последних (хотя смотря что за OpenSource проект).
А как Вы предлагаете откатить фитчу полностью в случае использования feature-бренчей? С очень большой вероятностью ваш merge будет состоять не из одного коммита, несколько позднее вскрывшихся багов непременно вызовут необходимость исправлений в транке а может быть они пойдут через feature-бренч. Как вы гарантируете, что откатив фитчу (не так-то это просто перерыть историю выискивая, что нужно откатывать) вы не разрушите систему, если паралельная разработка в транке более не совместима с состоянием вашей части до отката?
Да, наверное мою позицию можно сформлировать так: «я предлагаю отказаться от снепшотов». Как конкретно сделать это эффективно, пока могу только гадать.
Без снепшотов нераберихи с версиями меньше, потому что всегда четко видно, зависимость какой версии вошла в билд. Собственно уникальные снепшоты Maven 3, наверное попытка решить эту проблему (не совсем мне понятная), но они вызывают дргую, а именно проблему CI: винчестер на машине с репозиторем переполняется мигом. Если же использовать автоматически очищающие джобы (например Nexus поддерживает что-то подобное), то не понятно, зачем нужны уникальные снепшоты.
Мои рассуждения годны скорее для последних (хотя смотря что за OpenSource проект).
А как Вы предлагаете откатить фитчу полностью в случае использования feature-бренчей? С очень большой вероятностью ваш merge будет состоять не из одного коммита, несколько позднее вскрывшихся багов непременно вызовут необходимость исправлений в транке а может быть они пойдут через feature-бренч. Как вы гарантируете, что откатив фитчу (не так-то это просто перерыть историю выискивая, что нужно откатывать) вы не разрушите систему, если паралельная разработка в транке более не совместима с состоянием вашей части до отката?
Да, наверное мою позицию можно сформлировать так: «я предлагаю отказаться от снепшотов». Как конкретно сделать это эффективно, пока могу только гадать.
Без снепшотов нераберихи с версиями меньше, потому что всегда четко видно, зависимость какой версии вошла в билд. Собственно уникальные снепшоты Maven 3, наверное попытка решить эту проблему (не совсем мне понятная), но они вызывают дргую, а именно проблему CI: винчестер на машине с репозиторем переполняется мигом. Если же использовать автоматически очищающие джобы (например Nexus поддерживает что-то подобное), то не понятно, зачем нужны уникальные снепшоты.
ниасилил, чем вам снэпшоты не угодили. чтобы не ползать по куче модулей, меняя версии перекрёстных зависимостей перед релизом, есть master-pom или какой-то parent-pom.
версии самих артефактов меняет релиз плагин.
версии самих артефактов меняет релиз плагин.
Со снепшот зависимостью билд проекта не воспроизводим; нет информации, какая именно зависимость в него вошла. В случае уникальных снепшотов информация может и остается, но становится бесполезной, как только репозиторий почислили от старых снепшотов.
Для решения этих граблей выдумали костыли в виде релиз-плагина, использование которого с большим скрипом и трудом можно автоматизировать для использования в CI билдах. Не было бы снепшотов, не нужен был бы релиз-плагин по большой своей части.
Вообще, снепшот-зависимости наверное полезны, когда один проект под активной разработкой ссылается на другой проект под активной разработкой. Тут да, хочется сэкономить время на частое обновление версий зависимостей.
Но как часто встречается такая ситуация? Редко, и в этом случае, при аккуратном построении проектов, можно разориться и пообновлять релиз-версии зависимостей (все равно их придется обновлять при релизе, плагином или нет).
Если в зависимом проекте идет активная разработка — это далеко не всегда значит, что нужно ссылаться на ее snapshot-версию, часто можно подождать следующего релиза зависимости, оставаясь на предыдущей релиз-версии.
Если вам постоянны необходимы снепшот-зависимости, то наверное ваши интерфейсы (API) не выделены в отдельные пакеты с отдельным версионированием.
Для эффективной параллельной работы интерфейсы должны быть стабильны, а все in-house проекты не стоит бренчить автоматически (и обновлять повсюду версии) только только потому что релиз-менеджмент собрался выпускать новую общую версию всей системы. Такой подход сэкономит вам тем больше сил и времени, чем больше ваша программная система.
Для решения этих граблей выдумали костыли в виде релиз-плагина, использование которого с большим скрипом и трудом можно автоматизировать для использования в CI билдах. Не было бы снепшотов, не нужен был бы релиз-плагин по большой своей части.
Вообще, снепшот-зависимости наверное полезны, когда один проект под активной разработкой ссылается на другой проект под активной разработкой. Тут да, хочется сэкономить время на частое обновление версий зависимостей.
Но как часто встречается такая ситуация? Редко, и в этом случае, при аккуратном построении проектов, можно разориться и пообновлять релиз-версии зависимостей (все равно их придется обновлять при релизе, плагином или нет).
Если в зависимом проекте идет активная разработка — это далеко не всегда значит, что нужно ссылаться на ее snapshot-версию, часто можно подождать следующего релиза зависимости, оставаясь на предыдущей релиз-версии.
Если вам постоянны необходимы снепшот-зависимости, то наверное ваши интерфейсы (API) не выделены в отдельные пакеты с отдельным версионированием.
Для эффективной параллельной работы интерфейсы должны быть стабильны, а все in-house проекты не стоит бренчить автоматически (и обновлять повсюду версии) только только потому что релиз-менеджмент собрался выпускать новую общую версию всей системы. Такой подход сэкономит вам тем больше сил и времени, чем больше ваша программная система.
>Со снепшот зависимостью билд проекта не воспроизводим; нет информации, какая именно зависимость в него вошла
да вообще-то есть, тот самый вами нелюбимый Jenkins прямо ссылочки проставляет на все зависимые снэпшоты и т.д.
я уж молчу, что CI он на то и CI чтобы как можно раньше проблемы ловить. какой смысл расследовать проблему пять снэпшотов назад?
>Но как часто встречается такая ситуация? Редко
да как бы мой опыт говорит ровно наоборот. Если проект стабилен и в нём только вялый багфикс, тогда да. А если проект живой, то даже будучи отнюдь не стартапом основные модули постоянно перетряхиваются, включая интерфейсы. Обычно есть 3-4 core util артефакта, в которых только вялые фиксы, такие артефакты включаются версиями, а не снэпшотами и их изменения, если что, могут и подождать.
да вообще-то есть, тот самый вами нелюбимый Jenkins прямо ссылочки проставляет на все зависимые снэпшоты и т.д.
я уж молчу, что CI он на то и CI чтобы как можно раньше проблемы ловить. какой смысл расследовать проблему пять снэпшотов назад?
>Но как часто встречается такая ситуация? Редко
да как бы мой опыт говорит ровно наоборот. Если проект стабилен и в нём только вялый багфикс, тогда да. А если проект живой, то даже будучи отнюдь не стартапом основные модули постоянно перетряхиваются, включая интерфейсы. Обычно есть 3-4 core util артефакта, в которых только вялые фиксы, такие артефакты включаются версиями, а не снэпшотами и их изменения, если что, могут и подождать.
Что даст вам ссылка на бинарник снепшота из Jenkins-а, если его уже нет ни в репозитории, ни, верятно, в самом дженкинсе (не все же билды у вас в нем умещаются)?
Если же вам надо быстро расследовать проблемы при CI билде двух snapshot-зависимых проектов, то рекомендую выделить интерфейс в отдельный проект, тогда желание пользоваться снепшотами будет возникать реже.
Если же вам надо быстро расследовать проблемы при CI билде двух snapshot-зависимых проектов, то рекомендую выделить интерфейс в отдельный проект, тогда желание пользоваться снепшотами будет возникать реже.
да почему же нет? у нас по две недели лежат все снэпшоты в нексусе и дженкинсе. надо было бы дольше — лежали бы хоть год, винты стоят копейки.
«быстро расследовать» обычно значит что проблема вот она — появилась с последним коммитом. чего там расследовать? если оно косвенно всплыло из-за кода другого модуля (а это уже реже встречается) берем и смотрим сразу fisheye activity, ибо конкретные версии артефактов тут не спасут. может причина косвенной проблемы в коде другого модуля появилась неделю назад и тесты тогда не падали.
«быстро расследовать» обычно значит что проблема вот она — появилась с последним коммитом. чего там расследовать? если оно косвенно всплыло из-за кода другого модуля (а это уже реже встречается) берем и смотрим сразу fisheye activity, ибо конкретные версии артефактов тут не спасут. может причина косвенной проблемы в коде другого модуля появилась неделю назад и тесты тогда не падали.
Если разработка активна, а проект большой (наша подсистема занимает более 200Мб один билд, и это хорошо, если 6ая часть того, что попадает в нексус), устанете винты докупать :)
Нам тоже на первый взгляд так казалось, мол что такое 200Мб билд.
Но давайте посчитаем, скромно, в среднем 10 билдов в день (на самом деле куда больше, но для простоты), 2Gb в день прирост.
1Тб винта вам хватит почти на 1,5 года. Кажется много, но 1,5 года пролетают очень быстро и вот уже винт полон.
Новый стоит дешево, но его ж надо заказать, потом установить. Потом придется помучиться и расширить репозиторий на несколько винтов постфактум.
А если реально, то один срез всей нашей системы весит не 200Мб, а 1Gb и билдов не 10, а 100 в день.
Как-то жалко тратить деньги на железо и время на то чтобы сохранить кучу мусора в репозитории.
Нам тоже на первый взгляд так казалось, мол что такое 200Мб билд.
Но давайте посчитаем, скромно, в среднем 10 билдов в день (на самом деле куда больше, но для простоты), 2Gb в день прирост.
1Тб винта вам хватит почти на 1,5 года. Кажется много, но 1,5 года пролетают очень быстро и вот уже винт полон.
Новый стоит дешево, но его ж надо заказать, потом установить. Потом придется помучиться и расширить репозиторий на несколько винтов постфактум.
А если реально, то один срез всей нашей системы весит не 200Мб, а 1Gb и билдов не 10, а 100 в день.
Как-то жалко тратить деньги на железо и время на то чтобы сохранить кучу мусора в репозитории.
Немного подумав о том, что же можно предложить в замен SNAPSHOT-ам, пришел к выводу, что поприветствовал бы развитие maven (или другой билд системы и системы контроля зависимостей) в следующих направлениях:
- Поддержка «стратегий» автоматической генерации версий. Что-то вроде: «при постройке присвоить артефакту версию по таком образцу, используя генератор случайных чисел, ревизию VCS, или что угодно по вкусу» (вот где сегодня приходят на помощь гибкие EL выражения Quickbuild)
- Вместо SNAPSHOT-ов ввести понятие release-билда, чтобы maven знал, что это построенные и референциремые именно в этом билде артефакты более нельзя убирать из репозитория. Зато другие, номера версий которых не отличаются в общем случае от версий release артефактов, можно удалять со временем безболезненно. В отличие от существющей системы, по умолчанию все артефакты получают уникальную версию и являются кандидатами на удаление из репозитория. Если вдруг какой-либо из них был референцирован из «release»-билда, то он автоматически переходит в статус release-артефакта
этим не мавен занимается, а репозиторий артефактов.
собсно, читаем документацию к нексусу, раздел staging repositories, поддерживается в том числе staging snapshots.
как это решено в артифактори не в курсе, наверняка тоже что-то придумали.
собсно, читаем документацию к нексусу, раздел staging repositories, поддерживается в том числе staging snapshots.
как это решено в артифактори не в курсе, наверняка тоже что-то придумали.
Чем не занимается maven?
Если генерацией версий, тогда да, об этом и речь, предлагаю добавить.
Если разделением на SNAPSHOT и релиз версии, то это чисто maven-овское изобретение.
Если генерацией версий, тогда да, об этом и речь, предлагаю добавить.
Если разделением на SNAPSHOT и релиз версии, то это чисто maven-овское изобретение.
вы пытаетесь решить вопрос staging процесса механизмом версий мавена, тогда как он для этого не предназначен.
Вообще-то не с того я начал. Но почему бы нет? :)
Проблему стейджинга пытаются сейчас решить все кому не лень: репозитории (Nexus), билд.системы (Go), разработчкики, вручную мастерящие CI среды. Почему бы не подумать об этом разработчикам maven, которые и так уже много чего мало относящегося к dependency management'у в pom.xml добавили.
Проблему стейджинга пытаются сейчас решить все кому не лень: репозитории (Nexus), билд.системы (Go), разработчкики, вручную мастерящие CI среды. Почему бы не подумать об этом разработчикам maven, которые и так уже много чего мало относящегося к dependency management'у в pom.xml добавили.
ну я вообще не понимаю ваших проблем :)) такое впечатление, что вы сами себе их придумали, и сами мужественно преодолеваете.
у вас же билд не будет занимать меньше места, если снэпшот станет релизом? если у вас почему-то все разработчики деплоят снэпшоты в общий репозиторий, то почему бы не выделить CI системе отдельный репозиторий с другой политикой очистки?
у вас же билд не будет занимать меньше места, если снэпшот станет релизом? если у вас почему-то все разработчики деплоят снэпшоты в общий репозиторий, то почему бы не выделить CI системе отдельный репозиторий с другой политикой очистки?
У нас разработчики вообще ничего не деплоят, деплоит только билд-система.
Верно, билд будет занимать столько же, что и снепшот.
С «политикой очистки» проблема, которую я предлагаю решить с помощью отказа от снепшотов и усовершенствования maven.
Единственная «политика очистки» на сегодняшний день — это удаление снепшотов. Снепшоты обладают недостатками, поэтому нужна политика очистки не только от снепшотов.
При этом очистка это только часть темы, не буду здесь более повторяться.
Верно, билд будет занимать столько же, что и снепшот.
С «политикой очистки» проблема, которую я предлагаю решить с помощью отказа от снепшотов и усовершенствования maven.
Единственная «политика очистки» на сегодняшний день — это удаление снепшотов. Снепшоты обладают недостатками, поэтому нужна политика очистки не только от снепшотов.
При этом очистка это только часть темы, не буду здесь более повторяться.
Sign up to leave a comment.
Проблемы релиз-менеджмента maven проектов при CI подходе к разработке ПО