В двух словах о NEXUS
Весной этого года команда наших разработчиков побывала на тренинге по многокомандному скраму с использованием фреймворка Nexus. Это оказался очень интересный инструмент, и мы хотим поделиться с вами впечатлениями от его возможностей.
Nexus — это фреймворк Кена Швабера, являющийся органичным и эволюционным расширением классического скрама для крупных проектов с многокомандной разработкой. Он базируется на тех же привычных scrum-основах: ролях, артефактах и ивентах, дополняя их аналогичными ивентами и артефактами для выявления и управления зависимостями, своевременного обмена информацией и доменными знаниями между командами и удержания фокуса на конечном продукте, а не индивидуальных инкрементах.
Роли
К стандартным scrum-ролям добавляется новая — Nexus Integration Team, отвечающая за успешную интеграцию всех сделанных инкрементов и решение технических и нетехнических ограничений между командами.
Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.
Состав интеграционной команды может меняться по необходимости.
События
С камнем преткновения многокомандного скрама — перекрёстными зависимостями между фичами и командами, — в процесс официально добавляются refinement sessions, время проведения которых жёстко не задано и выбирается в любой удобный момент спринта.
Событие проходит в несколько этапов: сперва NIT разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.
Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.
Дальше фичи спускаются на уровень команд и пересматриваются более подробно с помощью того же подхода: разделить на более мелкие части, выделить и визуализировать зависимости.
Планирование в Nexus также проходит этапами:
- На начальном этапе, где присутствуют все команды, Product Owner озвучивает и поясняет общие приоритеты спринта, цель общего инкремента. Представители команд еще раз корректируют распределение работы исходя из найденных зависимостей. Также на этом этапе формулируется общая цель спринта.
- Дальше команды продолжают планирование в индивидуальном порядке, и результаты планирования по всем командам вносятся в Nexus Sprint Backlog.
Классические три вопроса скрама для интеграционной команды трансформируются в:
- Что было успешно интегрировано до сегодняшнего Daily Scrum?
- Какие новые зависимости обнаружили?
- Какую информацию нужно распространить среди команд сегодня?
Nexus Retrospective состоит из трёх частей:
- NIT определяет проблемы, затронувшие более одной команды, и передает их как дополнительную входную информацию для командной ретроспективы.
- Командная ретроспектива, на которой обязательно принимаются во внимание общие проблемы, определённые на первом этапе
- Финальная часть ретроспективы, где формируется общее видение, как визуализировать и отслеживать сформулированные пункты.
Артефакты
Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.
Definition of Done формируется NIT, пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.
Масштабирование
Масштабирование начинается с хорошо настроенного скрама в рамках одной команды — те же основы и опыт фрактально переносятся на многокомандный уровень. Постепенно исходная команда делится на две-три команды и итеративно и инкрементально добавляются новые разработчики. Нужно следить, чтобы общий инкремент оставался устойчивым и предсказуемым. В ином случае количество потраченных усилий будет несравнимо выше, и сложность зависимостей, интеграционных и коммуникационных проблем будет расти в геометрической прогрессии при добавлении каждой следующей команды.
Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.
Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts и т.п. — чем больше масштабирование, тем большее количество техник и подходов необходимо использовать.
Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.
- Блог компании NIX
- Управление разработкой
- Управление проектами
Как масштабировать Scrum — пара слов о фреймворке гибкой разработки ПО Nexus
В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
/ фото Sebastian Sikora CC
Кто и зачем создал Nexus
В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.
Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.
Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.
Чтобы исправить ситуацию и помочь масштабировать методологию, в 2015 году Кен Швабер представил фреймворк Nexus. Nexus помогает избежать частых проблем совместной разработки: сложностей при использовании одной и той же кодовой базы и нестыковок при интеграции наработок разных команд.
В Nexus использованы итеративный и инкрементальный подходы к масштабированию процессов разработки ПО. Каждая команда работает в рамках своего спринта, а потом их результаты объединяются. За счет этого разработку продукта легче координировать.
Компоненты Nexus
Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.
Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).
Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.
В Nexus, чтобы помочь с масштабированием методологии, появилась роль Nexus Integration Team (NIT). Это целая команда, в которую входят Product Owner, Scrum Master и представители скрам-команд. Их задача — оценить потенциальные проблемы командной разработки и предотвратить их. Важно отметить, что члены NIT не занимаются непосредственно программированием, а дают рекомендации по применению Scrum- и Nexus-принципов всем остальным участникам.
В целом внедрение NIT помогло улучшить координацию между командами за счет грамотного распределения задач. Однако участники ИТ-сообщества говорят, что новая роль также поспособствовала созданию своеобразного «бутылочного горлышка» — когда члены NIT решают организационные вопросы, команда разработки простаивает в ожидании инструкций.
Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).
В журнале пожеланий проекта перечислены общие требования к функциональности — так называемые пользовательские истории, отсортированные в порядке убывания важности. Они помогают получить представление о том, как должен выглядеть конечный продукт.
Журнал пожеланий спринта — список функций для реализации, выбранных владельцем продукта. На основе этого списка разработчики отслеживают задачи, которые нужно завершить до конца одного спринта.
В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.
События. Все члены команды ходят на собрания, которые иногда называют общим термином «события». «Свиньи» проводят их ежедневно, а «куры» — в начале и конце проекта или спринта. Собрания нужны, чтобы обсудить ход разработки, прикинуть планы, выявить узкие места.
Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:
- Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
- Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
- Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
- Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.
Когда стоит использовать Nexus
В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.
Тогда компания пригласила эксперта по Scrum, и он предложил перенести рабочую схему Scrum на многокомандный уровень — внедрить Nexus. Сейчас по Nexus-методологии работают уже шесть команд, которые стабильно выпускают новые релизы ПО каждые две недели.
В крупных компаниях. Например, у ИТ-отдела компании Terminales Portuarios Peruanos (TPP), занимающейся морскими грузоперевозками в одном из портов столицы Перу, на выпуск новой версии профильного ПО уходило целых девять месяцев. Чтобы исправить ситуацию, компания пробовала методологии Waterfall, RUP и принципы традиционного управления проектами. Однако все они не дали значительных улучшений, и в каких-то случаях даже сделали хуже.
Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.
Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.
Отметим, что хотя Nexus и помогает скоординировать работу множества команд разработки при работе над крупным проектом и ускорить выход релизов (как в случае с TPP), он все же не способен решить проблемы, связанные с внутренним устройством организации. К примеру, фреймворк не окажет заметного эффекта, если в командах будет не хватать специалистов для решения всех задач.
Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.
P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:
- Как регулируют работу с ПД в России и Европе
- «Как дела у VMware»: обзор новых решений
- Где найти наш контент: блоги и каналы «ИТ-ГРАД»
- Балансировка нагрузки в облаке IaaS: зачем нужен DRS
- «Роботы» на страже облака
Nexus что это в программировании
Менеджер репозиториев №1 в мире
— Единый источник достоверных данных обо всех компонентах, бинарных файлах и артефактах сборки;
— Обеспечивает эффективное распределение компонентов и контейнеров между разработчиками;
— Используется в более чем 100 000 организациях по всему миру;
УНИВЕРСАЛЬНЫЙ КОНТРОЛЬ
Поддержка всех популярных форматов.
— Храните и управляйте дистрибуцией компонентов ПО Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT, GO, YUM и мн. др.;
— Управляйте любыми компонентами во всем цикле от разработки до поставки: бинарными файлами, библиотеками, контейнерами, сборками и итоговым программным продуктом;
— Используйте все возможности расширенной поддержки экосистемы Java Virtual Machine (JVM), включая Gradle, Ant, Maven и Ivy, а также полноценной совместимости с такими популярными инструментами, как Eclipse, IntelliJ, Hudson, Jenkins, Puppet, Chef, Docker и др.;
Контроль и управление компонентами, библиотеками ПО и артефактами сборки в промышленном формате.
— Доставка обновлений в режиме высокой доступности 24x7x365;
— Единый источник достоверных данных обо всех компонентах ПО, используемых в рамках жизненного цикла разработки программного обеспечения, включая контроль качества, подготовку к релизу и эксплуатацию;
— Простая интеграция с существующими корпоративными системами контроля доступа, включая LDAP, Atlassian Crowd и др.;
— Обеспечение защищенности в процессе разработки ПО с помощью зашифрованных соединений SSL;
Контроль работоспособности всей цепочки поставок программного обеспечения.
— Механизм проверки работоспособности репозитория предоставляет актуальные сведения о состоянии компонентов, чтобы все инженерные команды имели возможность оперативно принимать необходимые решения;
— Просмотр компонентов, нуждающихся в замене, в порядке, соответствующем критичности идентифицированных уязвимостей;
— Предотвращение общеизвестных, задекларированных уязвимостей и лицензионных рисков в компонентах Maven/Java, npm, NuGet, и PyPI;
Современные возможности для непрерывного технологического превосходства .
— Разворачивайте напрямую в целевой репозиторий с использованием любого удобного вам инструмента сборки / развертывания, либо напрямую через HTTP;
— Контроллируйте и управляйте релизами программного продукта c помощью автоматизированного механизма реализации правил валидации;
— Используйте прозрачный рабочий процесс и контроль для релиз-кандидатов Вашего ПО;
— Используйте возможность контролируемого обмена и переиспользования бинарных файлов, артефактов и версий программного продукта группами инженеров-разработчиков;
Клиентоориентированная корпоративная
поддержка мирового уровня.
— Мы основываемся на количестве пользователей, а не серверов. Это значит, что Вы масштабируете продукты Sonatype на любое количество серверов и дата-центров, какое захотите, без дополнительных затрат.
— Мы предоставляем детальную документацию и осуществляем оперативную поддержку по вопросам установки, конфигурации, использования и обновления.
— В Вашем распоряжении: обучение через видеокурсы, онлайн чат с технической поддержкой, экспертиза и технологические компетенции наших официальных партнеров;
Записки программиста
Установка Sonatype Nexus в Ubuntu Linux, а также пример использования совместно с SBT
Одна из первых вещей, которой программисты учатся при погружении в мир Java — установка артефактов из Maven Central. Nexus является очень популярным менеджером репозиториев (repository manager) от компании Sonatype. Он позволяет поднимать такой маленький Maven Central внутри вашей компании. В этой заметке будет рассмотрена установка и настройка Nexus, а также хождение в него из SBT. Но сначала мы, конечно же, разберемся, зачем вообще это может быть кому-то нужно.
Зачем это нужно
Вот некоторые юзкейсы, которые приходят на ум:
- Самое очевидное. У вас есть артефакты, которые хотелось бы шарить между командами и/или проектами, но эти артефакты не хочется выкладывать в открытый доступ;
- Nexus можно поднять в локальной сети и настроить в качестве прокси для Maven Central. За счет этого не приходится «скачивать интернет», когда, например, в команду приходит новый человек или кто-то меняет компьютер. Все артефакты быстро сливаются из кэша в локалке;
- Представьте, что у вашего провайдера что-то сломалось и вы сидите без интернета. В этом случае работа не встанет из-за недоступности артефактов, так как в локальной сети есть кэшик;
- Допустим, что артефакт, от которого вы зависите, по каким-то причинам вдруг исчезнет из публичного репозитория. Ходят слухи, что иногда такое случается. Возможно, это будет не артефакт целиком, а только определенная его версия, неважно. Тогда вы сможете залить закэшированный в вашей файловой системе артефакт в локальный Nexus и продолжать работать, как ни в чем не бывало;
- Некоторые артефакты бывают не залиты в Maven Central. Например, они могут просто лежать в виде исходников на каком-нибудь BitBucket. Опять таки, возможно, это не весь артефакт, а какая-то его development версия с очень важными для вас изменениями. Не нужно копировать исходники к себе в проект и пересобирать их после каждого clean. Или, затаив дыхание, ждать релиза. Просто соберите артефакт и залейте в Nexus;
- Есть еще много вариаций на тему предыдущего случая. Например, библиотека может быть заброшена. Еще ее автор может очень долго рассматривать ваш pull request или вовсе отклонить его. Создаем форк, собираем, заливаем в Nexus;
- Вообще, неплохой идеей является распиливание крупных проектов на маленькие артефакты и хранение их в Nexus. Как минимум, это может существенно ускорить сборку проекта. Кроме того, можно повторно использовать некоторые компоненты в разных системах. При этом может получиться, например, что Android-разработчик фактически пишет кусочек бэкенда, когда он коммитит в проект, который используется как на бэкенде, так и в мобильном приложении;
- Вы хотите сделать некоторые артефакты общедоступными, но Maven Central по каким-то причинам не подходит. Возможно, ваши артефакты не принимают туда из-за лицензии. Или у вас очень много артефактов, а также большая команда разработчиков, которые, вообще говоря, могут приходить в компанию и уходить из нее. В таких случаях может иметь смысл поднять self hosted менеджер репозиториев;
Как по мне, причин более, чем достаточно, для того, чтобы держать Nexus в любой компании, где пишут под JVM. Даже если он будем пустым. Типа, про запас. Чтобы был, если вдруг понадобится. Ради экономии ресурсов Nexus можно поселить на билд сервер рядом с Jenkins.
Установка и базовая настройка
Все описанные ниже шаги были проверены в Ubuntu Linux 14.04 LTS, но, по идее, будут верны и для других версий Ubuntu, а также мало отличаться для других дистрибутивов Linux.
Готового deb-пакета с Nexus нет, но, к счастью, руками он устанавливается не сложно. На машине должна быть установлена виртуальная машина Java. Не так давно, в заметке, посвященной Cassandra, мы выясняли, как она ставится:
sudo add-apt-repository ppa:webupd8team / java
sudo apt-get update
sudo apt-get install oracle-java8-installer
sudo apt-get install oracle-java8-unlimited-jce-policy
Далее качаем архив с Nexus и распаковываем его в /usr/local:
wget http: // www.sonatype.org / downloads / nexus-latest-bundle.tar.gz
С этого места — под root’ом:
cp nexus-latest-bundle.tar.gz / usr / local /
cd / usr / local /
tar -xvzf nexus-latest-bundle.tar.gz
ln -s nexus-2.11.3-01 nexus
Заводим нового пользователя и делаем его владельцем распакованных файлов:
adduser —disabled-password —disabled-login nexus
chown -R nexus:nexus . / nexus-2.11.3-01 /
chown -R nexus:nexus . / sonatype-work /
Делаем так, чтобы Nexus запускался при старте системы:
cp nexus / bin / nexus / etc / init.d / nexus
chmod 755 / etc / init.d / nexus
chown root / etc / init.d / nexus
update-rc.d nexus defaults
В файле /etc/init.d/nexus кое-что нужно поправить:
NEXUS_HOME = «/usr/local/nexus»
RUN_AS_USER = «nexus»
PIDDIR = «/usr/local/nexus/tmp»
Теперь уже под обычным пользователем:
sudo service nexus start
tail -f / usr / local / nexus / logs / wrapper.log
В браузере открываем http://nexus.example.ru:8081/nexus/ — здесь и далее предполагается, что машина называется nexus.example.ru. Справа вверху жмем Log in, вводим логин admin и пароль admin123. После входа справа вверху открываем Profile, меняем пароль. В Security → Users отключаем всех лишних пользователей, меняем email у админа. Там же можно завести пользователей с нужными правами, это не сложно.
Далее переходим к списку репозиториев:
Создаем новый hosted репозиторий, поля заполняем как-то так:
На этом настройку будем считать завершенной. При желании совсем несложно ограничить доступ к Nexus, воспользовавшись iptables, или поднять рядом Nginx с шифрованием трафика. Но эти вопросы мы ранее уже рассматривали, поэтому перейдем непосредственно к работе с репозиториями.
Сборка артефакта и его заливка вручную
Создаем новый Scala-проект, как мы это уже много раз делали, пишем код в таком стиле:
package me. eax . test
object TestPackage {
def test ( ) {
println ( s «Hello from test.package!» )
}
}
sbt package
В итоге получим файл target/scala-2.11/test-package_2.11-0.1.jar или вроде того. Заливаем артефакт в Nexus в последний созданный репозиторий через вкладку Artifact Upload. Указываем Group, Artifact, Version.
Заводим еще один проект, в коде пишем:
import me. eax . test . _
object Example extends App {
TestPackage. test ( )
}
В файл build.sbt дописываем:
credentials + = Credentials (
«Sonatype Nexus Repository Manager» , // don’t change!
«nexus.example.ru» ,
«user» ,
«password» )
resolvers + = {
«Nexus» at ( «http://nexus.example.ru:8081/nexus/content/» +
«repositories/test-repo/» )
}
libraryDependencies ++ = Seq (
«me.eax» % «test-package» % «0.1»
)
Собираем, проверяем, что все работает.
Еще есть команды sbt package-doc и sbt package-src . Как можно без труда догадаться, они собирают jar’ники с документацией и исходниками.
Заливать артефакты вручную неудобно и чревато ошибками. Поэтому ниже будет показано, как автоматизировать заливку. Но сначала нам потребуются кое-какие дополнительные знания, которые проще всего получить, рассмотрев работу Nexus в качестве прокси.
Использование Nexus как прокси
Чтобы все артефакты качались через Nexus, создаем файл ~/.sbt/repositories такого содержания:
[repositories]
local
maven-proxy: http://nexus.example.ru:8081/. /repositories/central/
Приведенная выше ссылка не уместилась по ширине, но вы можете скопировать ее в списке репозиториев. Это репозиторий с именем Central.
Далее создаем ~/.sbt/0.13/plugins/nexus-example-ru.sbt:
credentials + = Credentials (
«Sonatype Nexus Repository Manager» , // don’t change!
«nexus.example.ru» ,
«user» ,
«password» )
Можете взять какой-нибудь из своих проектов, посмотреть на его зависимости, удалить пару соответствующих артефактов в каталоге ~/.ivy2/cache/ и затем сказать sbt compile . Если все было сделано правильно, вы увидите, что теперь артефакты тянутся через nexus.example.ru.
Автоматическая заливка
Возвращаемся к проекту test-package. Файл build.sbt редактируем как-то так:
Если вы хотите заливать -SNAPSHOT и релизные версии артефакта в разные репозитории, тут написано, как это настроить.
Все credentials мы уже настроили на шаге про использование Nexus в роли прокси. Поэтому просто говорим sbt publish . Будет залит обычный jar’ник, а также javadoc и sources.
Во втором проекте, который зависит от test-package, изменяем build.sbt:
// кстати, credentials из файла можно уже убрать
// так как они теперь есть в ~/.sbt/0.13/plugins/
libraryDependencies ++ = Seq (
«me.eax» %% «test-package» % «0.2»
)
Обратите внимание, что теперь используется два знака процента, а не один. То есть, при заливке sbt автоматически указал имя артефакта test-package_2.11 , как, собственно, и принято в мире Scala. Проверяем, что все собирается.
Также SBT поддерживает кросс-сборку. То есть, в одном проекте можно собирать артефакт для нескольких версий языка Scala. Например, чтобы артефакт собирался для Scala 2.10 и 2.11, в build.sbt нужно дописать:
crossScalaVersions := Seq ( «2.10.5» , «2.11.6» )
Тестирование, сборка и публикация всех версий артефакта:
sbt ‘+ test’
sbt ‘+ package’
sbt ‘+ publish’
Бывает так, что нужно использовать немного разные версии библиотек или флаги компилятора в зависимости от версии Scala. Это делается примерно так:
scalacOptions ++ = {
CrossVersion. partialVersion ( scalaVersion. value ) match {
case Some ( ( 2 , 11 ) ) => Seq ( «-Ywarn-infer-any» )
case _ => Seq. empty
}
}
Нужно отметить, что перед sbt publish не лишним будет делать sbt publish-local для «заливки» артефакта в кэш, протестировать, что все ОК, и только потом заливать артефакт в репозиторий.
Заключение
Немного ссылок по теме:
- Страница проекта на сайте Sonatype;
- Исходники бесплатной версии Nexus на GitHub;
- Официальная документация, есть вариант в PDF;
- Гайд про заливку в Maven Central на английском языке;
- Гайд про заливку в Maven Central на русском языке;
- Альтернативы Nexus — Artifactory от JFrog и Apache Archiva;
- Сравнение возможностей разных менеджеров репозиториев;
А куда вы заливаете артефакты?
Вы можете прислать свой комментарий мне на почту, или воспользоваться комментариями в Telegram-группе.
Коротко о себе
Меня зовут Александр, позывной любительского радио R2AUK. Здесь я пишу об интересующих меня вещах и временами — просто о жизни.
Вы можете следить за обновлениями блога с помощью RSS, ВКонтакте, Telegram или Twitter. Также я являюсь одним из ведущих подкаста DevZen и выкладываю видео на YouTube.
Мой e-mail — af is kon @gmail.com. Если вы хотите мне написать, прошу предварительно ознакомиться с FAQ.