Немного подумав о том, что же можно предложить в замен SNAPSHOT-ам, пришел к выводу, что поприветствовал бы развитие maven (или другой билд системы и системы контроля зависимостей) в следующих направлениях:
Поддержка «стратегий» автоматической генерации версий. Что-то вроде: «при постройке присвоить артефакту версию по таком образцу, используя генератор случайных чисел, ревизию VCS, или что угодно по вкусу» (вот где сегодня приходят на помощь гибкие EL выражения Quickbuild)
Вместо SNAPSHOT-ов ввести понятие release-билда, чтобы maven знал, что это построенные и референциремые именно в этом билде артефакты более нельзя убирать из репозитория. Зато другие, номера версий которых не отличаются в общем случае от версий release артефактов, можно удалять со временем безболезненно. В отличие от существющей системы, по умолчанию все артефакты получают уникальную версию и являются кандидатами на удаление из репозитория. Если вдруг какой-либо из них был референцирован из «release»-билда, то он автоматически переходит в статус release-артефакта
Что даст вам ссылка на бинарник снепшота из Jenkins-а, если его уже нет ни в репозитории, ни, верятно, в самом дженкинсе (не все же билды у вас в нем умещаются)?
Если же вам надо быстро расследовать проблемы при CI билде двух snapshot-зависимых проектов, то рекомендую выделить интерфейс в отдельный проект, тогда желание пользоваться снепшотами будет возникать реже.
Со снепшот зависимостью билд проекта не воспроизводим; нет информации, какая именно зависимость в него вошла. В случае уникальных снепшотов информация может и остается, но становится бесполезной, как только репозиторий почислили от старых снепшотов.
Для решения этих граблей выдумали костыли в виде релиз-плагина, использование которого с большим скрипом и трудом можно автоматизировать для использования в CI билдах. Не было бы снепшотов, не нужен был бы релиз-плагин по большой своей части.
Вообще, снепшот-зависимости наверное полезны, когда один проект под активной разработкой ссылается на другой проект под активной разработкой. Тут да, хочется сэкономить время на частое обновление версий зависимостей.
Но как часто встречается такая ситуация? Редко, и в этом случае, при аккуратном построении проектов, можно разориться и пообновлять релиз-версии зависимостей (все равно их придется обновлять при релизе, плагином или нет).
Если в зависимом проекте идет активная разработка — это далеко не всегда значит, что нужно ссылаться на ее snapshot-версию, часто можно подождать следующего релиза зависимости, оставаясь на предыдущей релиз-версии.
Если вам постоянны необходимы снепшот-зависимости, то наверное ваши интерфейсы (API) не выделены в отдельные пакеты с отдельным версионированием.
Для эффективной параллельной работы интерфейсы должны быть стабильны, а все in-house проекты не стоит бренчить автоматически (и обновлять повсюду версии) только только потому что релиз-менеджмент собрался выпускать новую общую версию всей системы. Такой подход сэкономит вам тем больше сил и времени, чем больше ваша программная система.
OpenSource прокты, согласен, отличаются от proprietary во многом.
Мои рассуждения годны скорее для последних (хотя смотря что за OpenSource проект).
А как Вы предлагаете откатить фитчу полностью в случае использования feature-бренчей? С очень большой вероятностью ваш merge будет состоять не из одного коммита, несколько позднее вскрывшихся багов непременно вызовут необходимость исправлений в транке а может быть они пойдут через feature-бренч. Как вы гарантируете, что откатив фитчу (не так-то это просто перерыть историю выискивая, что нужно откатывать) вы не разрушите систему, если паралельная разработка в транке более не совместима с состоянием вашей части до отката?
Да, наверное мою позицию можно сформлировать так: «я предлагаю отказаться от снепшотов». Как конкретно сделать это эффективно, пока могу только гадать.
Без снепшотов нераберихи с версиями меньше, потому что всегда четко видно, зависимость какой версии вошла в билд. Собственно уникальные снепшоты Maven 3, наверное попытка решить эту проблему (не совсем мне понятная), но они вызывают дргую, а именно проблему CI: винчестер на машине с репозиторем переполняется мигом. Если же использовать автоматически очищающие джобы (например Nexus поддерживает что-то подобное), то не понятно, зачем нужны уникальные снепшоты.
С чужими мелкими багами рано или поздно придется разбираться.
Разработчики (чем опытнее, тем охотнее) стремятся обособиться от «чужих мелких багов» и зачастую перекладывают задачу интеграции их feature-брэнчей на новичков или менее оплачиваемых коллег.
В резльтате когда речь идет о преимуществах и недостатках feature-бренчей они зачастую не понимают о чем идет речь, поскольку трудности риск и ответственность за интеграцию не лежит на их славных плечах.
Классический ответ на второй вопрос: разрабатывать фитчи в транке и держать их деактивированными до тех пор, пока они не будут готовы к релизу. Обычно такой ответ вызывает реакцию вроде «ну да… слыхали эти сказки, такое работает только на бумаге». А вот с недавних пор в моем проекте делаем именно так, и ничего страшного не случилось, даже наоборот, как бы забесплатно получили «фитчу» включать и отключать фитчи произвольно уже после выпуска, в некоторых случаях даже в рантайме.
В реальности не слышал об успешных случаях применения feature-бренчей (без кошмара интеграции и проваленных сроков) для подготовки релиза с произвольным набором фитч и тем более их последющего отката.
Если же вам надо быстро расследовать проблемы при CI билде двух snapshot-зависимых проектов, то рекомендую выделить интерфейс в отдельный проект, тогда желание пользоваться снепшотами будет возникать реже.
Для решения этих граблей выдумали костыли в виде релиз-плагина, использование которого с большим скрипом и трудом можно автоматизировать для использования в CI билдах. Не было бы снепшотов, не нужен был бы релиз-плагин по большой своей части.
Вообще, снепшот-зависимости наверное полезны, когда один проект под активной разработкой ссылается на другой проект под активной разработкой. Тут да, хочется сэкономить время на частое обновление версий зависимостей.
Но как часто встречается такая ситуация? Редко, и в этом случае, при аккуратном построении проектов, можно разориться и пообновлять релиз-версии зависимостей (все равно их придется обновлять при релизе, плагином или нет).
Если в зависимом проекте идет активная разработка — это далеко не всегда значит, что нужно ссылаться на ее snapshot-версию, часто можно подождать следующего релиза зависимости, оставаясь на предыдущей релиз-версии.
Если вам постоянны необходимы снепшот-зависимости, то наверное ваши интерфейсы (API) не выделены в отдельные пакеты с отдельным версионированием.
Для эффективной параллельной работы интерфейсы должны быть стабильны, а все in-house проекты не стоит бренчить автоматически (и обновлять повсюду версии) только только потому что релиз-менеджмент собрался выпускать новую общую версию всей системы. Такой подход сэкономит вам тем больше сил и времени, чем больше ваша программная система.
Мои рассуждения годны скорее для последних (хотя смотря что за OpenSource проект).
А как Вы предлагаете откатить фитчу полностью в случае использования feature-бренчей? С очень большой вероятностью ваш merge будет состоять не из одного коммита, несколько позднее вскрывшихся багов непременно вызовут необходимость исправлений в транке а может быть они пойдут через feature-бренч. Как вы гарантируете, что откатив фитчу (не так-то это просто перерыть историю выискивая, что нужно откатывать) вы не разрушите систему, если паралельная разработка в транке более не совместима с состоянием вашей части до отката?
Да, наверное мою позицию можно сформлировать так: «я предлагаю отказаться от снепшотов». Как конкретно сделать это эффективно, пока могу только гадать.
Без снепшотов нераберихи с версиями меньше, потому что всегда четко видно, зависимость какой версии вошла в билд. Собственно уникальные снепшоты Maven 3, наверное попытка решить эту проблему (не совсем мне понятная), но они вызывают дргую, а именно проблему CI: винчестер на машине с репозиторем переполняется мигом. Если же использовать автоматически очищающие джобы (например Nexus поддерживает что-то подобное), то не понятно, зачем нужны уникальные снепшоты.
Разработчики (чем опытнее, тем охотнее) стремятся обособиться от «чужих мелких багов» и зачастую перекладывают задачу интеграции их feature-брэнчей на новичков или менее оплачиваемых коллег.
В резльтате когда речь идет о преимуществах и недостатках feature-бренчей они зачастую не понимают о чем идет речь, поскольку трудности риск и ответственность за интеграцию не лежит на их славных плечах.
Классический ответ на второй вопрос: разрабатывать фитчи в транке и держать их деактивированными до тех пор, пока они не будут готовы к релизу. Обычно такой ответ вызывает реакцию вроде «ну да… слыхали эти сказки, такое работает только на бумаге». А вот с недавних пор в моем проекте делаем именно так, и ничего страшного не случилось, даже наоборот, как бы забесплатно получили «фитчу» включать и отключать фитчи произвольно уже после выпуска, в некоторых случаях даже в рантайме.
В реальности не слышал об успешных случаях применения feature-бренчей (без кошмара интеграции и проваленных сроков) для подготовки релиза с произвольным набором фитч и тем более их последющего отката.