Comments 9
1000К+ инженеров
1 миллион инженеров?
*поднимает челюсть*
Такое подозрение, что здесь не автоматизация скрипта нужна (хотя и его тоже поправить было правильно), а просто нормальный бизнес-процесс, включающий в себя какой-нибудь issue-tracker (на примере JIRA могу сказать, что легко «узнать, не собирается ли автор ещё чего-нибудь закоммитить» (статус ready for build весьма красноречив) внутри какой-либо компоненты, узнать нет ли ещё незавершённых тикетов для определённой версии компоненты.
Согласен, процессы — наша проблема, устаканить их среди нескольких вендоров не получилось. Почти над любой системой сейчас работает 2-3 компании. Насколько я понимаю, таким образом бизнес уменьшает зависимость от одного вендора.
Если действительно «несколько компаний», то не надо «разбираться какой компонент релизить» — каждая компания должна вести свои компоненты и релизить их самостоятельно. И они сами будут видеть от кого они зависят. А те, кто зависят от них — будут смотреть на них, а не на суб-зависимости.
Хорошо бы, если бы было так, как вы написали. На практике команды формируются под проект из свободных на данный момент разработчиков разных компаний. Кажданая команда может менять некоторое количество модулей. Вот почему закрепить модуль даже за компанией не всегда не получается. Более того, бизнесу нравится такое положение вещей, если один вендор отвалится(не будет продлевать контракт), то они найдут инженеров знакомых с этим модулем в другой компании.
Поидее если вы релизите какоют версию собоирающуюся из дерева зависмимостей, то вам интересно собрать тольло релизы выпущенные на данный момент не форсируя дополнительные релизы (звоня этим самым ленивиым инзехенерам)…
Если какя то команда закончила свою работу над спец модулем где-то глубоко в зависмостях продукта… То сама команда и должна бы промоутать эту новую но тестированню версию… релизнутую версию.
А топ проект уже сам решает включить ему новшество в свой релиз или нет. Если да то при релизе провести тесты с этой новой либой…
Проблема ИМХО в планировании релизов…
Если какя то команда закончила свою работу над спец модулем где-то глубоко в зависмостях продукта… То сама команда и должна бы промоутать эту новую но тестированню версию… релизнутую версию.
А топ проект уже сам решает включить ему новшество в свой релиз или нет. Если да то при релизе провести тесты с этой новой либой…
Проблема ИМХО в планировании релизов…
У нас немного другая структура проекта habrahabr.ru/post/154779/ но столкнулись с теми же проблемами. Решилось просто — написанием полноценного maven-плагина, который начинает выпускать текущий модуль, спускается по иерархии зависимостей до самого низа и запускает выпуск версий\подверсий модулей, предварительно проверяет, есть ли релиз для текущего снэпшота, если есть, то берет его. В итоге время выпуска сократилось раз в 5 и рутинная работа по сверке версий, коммитам в SVN пропала.
Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.
Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.
Sign up to leave a comment.
Почему я плагин для Maven писал