Nexus cd что это

Это все, что потребуется при заведении нового проекта. Project key будет взят из названия yaml файла (в данном примере — project1).

Как это выглядит в UI:

Jenkins Job Builder

JJB является python утилитой для описания сущностей jenkins в виде yaml манифестов, которые преобразуются в понятные jenkins API запросы. Это позволяет великолепно решать задачу управления большим количеством однотипных задач.

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

Структура репозитория jjb-core:

Каждая директория содержит описание Jenkins job состоящее из двух файлов.

Yaml файл описывает шаблон jenkins job имеет следующее наполнение:

--- - job: # Создаем директорию CORE name: CORE project-type: folder - job: # Создаем поддиректорию ad-core-automation в CORE name: CORE/ad-core-automation project-type: folder # Описание темплэйта - job-template: name: 'CORE/ad-core-automation/-' project-type: pipeline job_description: Упралвение OU и SG для # Defaults GIT_BRANCH: master GIT_CRED_ID: jenkins-ad-integration triggers: - timed: 'H(0-59) * * * *' parameters: - string: name: GIT_BRANCH default: '' description: Git ref (branch/tag/SHA) - string: name: GIT_CRED_IDjenkins default: '' description: Jenkins credentials ID for BitBucket - string: name: META_LOCATION default: 'DEV//_meta.yaml' description: Meta file location if CORE/meta repository dsl: !include-raw-escape: ./ad-core-automation.groovy - project: name: ad-core project_key: - project1 - project2 - project3 jobs: - 'CORE/ad-core-automation/-' 

Файл groovy — это простой jenkinsfile:

def meta_location = params.META_LOCATION def git_cred_id = params.GIT_CRED_ID def git_branch = params.GIT_BRANCH pipeline < agent < label 'common-centos' >stages < stage('Clone git repos') < steps < echo 'Clone meta' dir('meta') < git credentialsId: "$", url: 'git@github.com:Mir-Platform/meta-example.git' > echo 'Clone ad-core-automation' dir('auto') < git credentialsId: "$", branch: git_branch, url: 'git@github.com:Mir-Platform/ad-core-automation.git' > > > stage('Install and run') < steps < echo 'Install requirements' withDockerContainer('python:3.8.2-slim') < withEnv(["HOME=$"]) < sh 'pip install --user --upgrade -r auto/requirements.txt' sleep(5) echo 'Run automation' withCredentials([usernamePassword(credentialsId: 'ad_tech', passwordVariable: 'ad_pass', usernameVariable: 'ad_user')]) < dir('auto') < sh "./run.py -u $ad_user -p $ad_pass -f ../meta/$" > > > > > > > > 

Все это описывает создание следующей структуры Jenkins:

Общий алгоритм работы автоматизации:

• Инициатор создает в репозитории meta новую директорию с картой проекта и создает pull-request в мастер ветку(1).
• Pull-request попадает на проверку согласующих (2)
• В случае, если проект новый, пока в ручном режиме инженер прописывает Bitbucket project key для JJB (данное действие нужно произвести единожды)
• Автоматизация после внесения изменений в шаблоны JJB генерирует описанные job для проекта(4, 5).
• Jenkins запускает автоматизацию AD(6), которая создает необходимые сущности в виде OU и SG в AD. В случае, если все сущности уже созданы, приводит состав пользователей к описанному (удаляет/добавляет)
• Jenkins запускает автоматизацию Bitbucket(4), если проекта нет в Bitbucket, то создает его и предоставляет доступ для групп команды проекта. Если проект уже существует, то добавляет к нему группы AD с необходимыми привилегиями.
• Jenkins запускает автоматизацию для Nexus(7). Создаются описанные сущности Nexus и к ним предоставляется доступ на основе групп AD

Результат и развитие

Результатом данного концепта стало появление базовой автоматизации описанных процессов. Интерфейс взаимодействия в виде yaml карт проектов оказался весьма удобен, появились запросы на улучшения. Главными показателями успешности стали простота и скорость предоставления необходимых проектам ресурсов. Показатель скорости улучшился в разы по сравнению с ручным подходом. Все стало однотипным, понятным и повторяемым. Избавились от ручных ошибок.

На текущий момент описанный PoC перешел в стадию промышленной эксплуатации и претерпел значительные доработки. Мы переписали core систему автоматизации, к которой в виде плагинов подключаются модули для автоматизации новых сервисов. Появились тесты.
Всего автоматизацией обслуживается около 50 проектов и подключаются новые. Планируем тиражирование в другие сетевые сегменты.

• Блог компании Мир Plat.Form (НСПК)
• IT-инфраструктура
• DevOps

CI/CD в Git: 5 советов по организации репозиториев Git с поддержкой непрерывной интеграции

Git и непрерывная поставка образуют одно из потрясающих сочетаний, которые иногда встречаются в мире ПО, — подобно маслу и варенью на бутерброде. Две технологии, великолепные сами по себе, отлично дополняют друг друга. Поэтому я хочу поделиться несколькими советами, которые позволяют обеспечить идеальное взаимодействие сборок Bamboo с хранилищами Bitbucket. Главным образом эти компоненты взаимодействуют на тех этапах непрерывной поставки, где происходят сборка и тестирование, поэтому в статье речь будет идти больше о непрерывной интеграции, чем о непрерывной поставке.

1. Храните большие файлы за пределами репозитория

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

Извлечь файл из истории репозитория не так просто: это как операция лоботомии на базе кода. Такой хирургический способ извлечения файлов меняет всю историю репозитория, поэтому вы теряете четкую картину того, какие изменения были сделаны и когда. Достаточно причин, чтобы «избегать больших файлов» стало вашим правилом. И поэтому.

Для непрерывной интеграции принципиально важно хранить крупные файлы вне репозиториев Git

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

Ладно, пусть так. Но что если ваша сборка зависит от бинарных файлов из других проектов или от крупных артефактов? Это очень распространенная ситуация, и, вероятно, она будет существовать всегда. Отсюда вопрос: как мы можем эффективно с этим справиться?

См. решение

Разработка и эксплуатация программного обеспечения с помощью Open DevOps

Связанные материалы

Подробнее о магистральной разработке

Для хранения артефактов, которые создаются вашей командой или командами, взаимодействующими с вами, можно использовать внешнюю систему хранения, например Artifactory (у которой есть аддон для Bamboo), Nexus или Archiva. Нужные файлы можно загружать в каталог сборки в начале процесса сборки — как и сторонние библиотеки, которые вы загружаете через Maven или Gradle.

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

Если в вашей сети нет внешней системы хранения, проще всего будет воспользоваться поддержкой больших файлов в Git (LFS).

Git LSF — это расширение, которое хранит в репозитории указатели на большие файлы, а не сами файлы. Сами файлы хранятся на удаленном сервере. Вы можете себе представить, насколько это сокращает время клонирования.

Скорее всего, у вас уже есть доступ к Git LFS: эту технологию поддерживает и Bitbucket, и Github.

2. Используйте поверхностные клоны для CI

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

При использовании поверхностного клонирования копироваться будет только текущее состояние вашего репозитория. Поэтому такой подход может быть весьма полезен для сокращения времени сборки, особенно при работе с большими и/или старыми репозиториями.

Но допустим, что ваша сборка требует полной истории репозитория. Например, на одном из этапов сборки обновляется номер версии в файле POM (или аналогичном файле) или вы выполняете слияние двух веток при каждой сборке. В перечисленных случаях требуется, чтобы Bamboo отправил изменения обратно в репозиторий.

Благодаря Git простые изменения файлов (например, обновление номера версии) можно отправлять при отсутствии полной истории. Однако для выполнения слияния по-прежнему требуется история репозитория, поскольку системе Git необходимо найти общего предка двух веток. Это будет проблемой, если в вашей сборке используется поверхностное клонирование. И это подводит нас к совету № 3.

3. Кэшируйте репозиторий на агентах сборки

Это также значительно ускоряет операцию клонирования (фактически Bamboo поступает так по умолчанию).

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

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

4. Продумывайте выбор триггеров

Это (почти) само собой разумеется: использование CI на всех активных ветках — хорошая идея. Но стоит ли запускать все сборки на всех ветках при любом коммите? Пожалуй, нет. И вот почему.

Возьмем, для примера, Atlassian. У нас более 800 разработчиков, каждый из которых отправляет изменения в репозиторий несколько раз в день (в основном изменения отправляются в собственные функциональные ветки). А это очень много сборок. И если отсутствует мгновенное и бесконечное масштабирование агентов сборки, это приводит к длительному ожиданию в очереди.

Один из наших внутренних серверов Bamboo содержит 935 различных планов сборки. Мы подключили 141 агент сборки к этому серверу и внедрили такие рекомендации, как передача артефактов и параллельное выполнение тестов, чтобы сделать каждую сборку максимально эффективной. Тем не менее сборка после каждой операции push приводила к тому, что работа застревала.

Можно было просто настроить еще один экземпляр Bamboo с дополнительными 100+ агентами, но мы притормозили и задались вопросом, действительно ли это необходимо. Ответ в итоге был отрицательным.

Таким образом мы даем разработчикам возможность запускать сборку принадлежащих им веток нажатием кнопки, а не выполняем сборку автоматически каждый раз. Это хороший способ обеспечить баланс между тщательным тестированием и экономией ресурсов: появляются большие возможности для экономии, поскольку именно в ветках происходит большая часть изменений.

Многим разработчикам нравится дополнительный контроль, который им обеспечивает сборка, запускаемая после нажатия кнопки. По их мнению, это естественным образом вписывается в рабочий процесс. Другие предпочитают не думать о том, когда запускать сборку, и использовать автоматические триггеры. Эффективно использовать можно любой из этих подходов. Важно то, что ветки в принципе нужно тестировать, а перед их слиянием с основным потоком кода необходимо убедиться, что сборка не содержит ошибок.

Однако важнейшие ветки, такие как главная ветка и ветки стабильного выпуска, — это отдельная история. Сборки там запускаются автоматически: либо путем опроса репозитория на предмет изменений, либо путем отправки push-уведомления из Bitbucket в Bamboo. Поскольку мы используем ветки разработки для всей незавершенной работы, единственными коммитами в главную ветку (теоретически) должны быть слияния веток разработки. К тому же это строки кода, из которых мы делаем релизы и создаем ветки разработки. Поэтому очень важно своевременно получать результаты тестов по каждому слиянию.

5. Прекратите опросы, используйте подключения

Опрос репозитория каждые несколько минут для обнаружения изменений — не слишком затратная операция для Bamboo. Но когда вы масштабируете проект до сотен сборок на тысячи веток, задействуя десятки репозиториев, сложность стремительно нарастает. Вместо того чтобы нагружать Bamboo всеми этими опросами, можно сделать так, чтобы из Bitbucket поступали сигналы об отправке изменений и необходимости сборки.

Обычно это делается путем добавления скрипта hook в репозиторий, но интеграция между Bitbucket и Bamboo выполняет настройку внутренних параметров автоматически. После того как эти два продукта будут связаны на серверном уровне, триггеры сборки, инициируемые из репозитория, будут Просто работать™ без лишней настройки. Каких-либо скриптов hook или специальной конфигурации не потребуется.

Независимо от используемых инструментов триггеры, инициируемые из репозитория, имеют преимущество: они автоматически исчезают, когда целевая ветка становится неактивной. Иными словами, вам не придется расходовать ресурсы процессора системы CI на опрос сотен заброшенных веток или напрасно тратить собственное время, вручную отключая сборку веток! (Хотя стоит отметить, что Bamboo можно просто настроить на игнорирование веток после X дней бездействия, если вы все же предпочитаете способ опроса.)

Ключом к использованию Git с CI является.

…просто внимательность. Когда непрерывная интеграция осуществлялась с помощью централизованной системы управления версиями, все прекрасно работало? С Git некоторые моменты будут работать не так идеально. Поэтому на первом этапе необходимо проверить свои исходные предположения. Для клиентов Atlassian вторым этапом является интеграция Bamboo с Bitbucket. Ознакомьтесь с нашей документацией, чтобы узнать подробнее, и удачной вам разработки!

Sarah Goff-Dupont

Сара — в прошлом инженер по контролю качества, а теперь автор статей. Ее труды публикуют в журнале Harvard Business Review, Huffington Post и других отраслевых изданиях. Она живет в Миннесоте и работает удаленно. Свою работу она просто обожает. Свободное от работы время она проводит, читая, катаясь на сноуборде, готовя и забавляясь со своими детьми.

Публикация Java приложения в личный Nexus

Nexus это хранилище артефактов. Артефакт это ваше приложение, например jar-ник. Чаще всего в Nexus сохраняют библиотеки, чтобы другие разработчики могли их подключить в виде зависимости к своему приложению.

Самым большим и открытым Nexus является Maven Central. Он публичный, то есть любой может взять оттуда зависимость. Но что если вам не нужна публичность. Например, мы хотим сделать библиотеку, которой будут пользоваться только наши коллеги с работы, или ваши только вы и ваша команда. Тогда вам нужен Sonatype Nexus.

Nexus Sonatype позволит вам создать свой приватный, ну либо публичный Nexus с авторизацией. Также его можно использовать, как прокси перед Maven Central.

Я не буду рассказывать, как установить свой Nexus. Я расскажу, что добавить в ваше приложение, чтобы деплоить в Nexus.

Спонсор поста

Настраиваем settings.xml

Скорее всего у вас есть логин и пароль аккаунта в Nexus. Эти данные нужно указать в файле .m2/settings.xml . Если этого файла нет в папке .m2 создайте его.

   nexus-server nexus-login nexus-password   

Настраиваем приложение

Теперь переходим к pom.xml приложения.

В секцию properties добавляем версии плагинов и URL нексуса.

 . http://ip_you_nexus:nexus_port 2.8.2 1.6.8 . 

Добавляем в pom.xml url на репозитории в нексусе: снепшотный и релизный.

  nexus-server $/repository/maven-releases/  nexus-server $/repository/maven-snapshots/  

Обратите внимание на строки 3 и 7, id репозиториев должен совпадать с id в секции server файла .m2/settings.xml .

Мы заменим maven-deploy-plugin на nexus-staging-maven-plugin . После этого мы сможем деплоить в наш нексус командой mvn deploy .

   org.apache.maven.plugins maven-deploy-plugin $ true   org.sonatype.plugins nexus-staging-maven-plugin $  default-deploy deploy deploy    maven-snapshots $/nexus/ true    

Если вам нужно также сохранять исходники и JavaDoc, то добавьте эти плагины:

 org.apache.maven.plugins maven-source-plugin  attach-sources jar     org.apache.maven.plugins maven-javadoc-plugin 2.9.1 $/bin/javadoc   attach-javadocs jar    

Вот и все, теперь вы можете задеплоить артефакт в нексус обычной Maven командой:

mvn clean deploy

Вы можете настроить автоматическую сборку и доставку в Nexus с помощью Gitlab CI, подробнее об этом я писал в статье: Настройка Gitlab CI/CD для Java приложения ��

Масштабируем Scrum с помощью Nexus

В этой статье мы кратко расскажем про Nexus – подход для масштабирования Scrum, предложенный создателем Scrum Кеном Швабером. Мы также проиллюстрируем ключевые идеи этого подхода на примере реального большого продукта, который разрабатывают более 200 человек, используя Scrum и Nexus.

Две проблемы

Agile и Scrum становятся все более востребованными для больших компаний и больших продуктов. Есть несколько известных подходов к тому, как «масштабировать Agile», то есть организовывать работу нескольких Agile-команд над одним большим продуктом, – SAFe, LeSS, Nexus и другие. У каждого подхода есть свои особенности и свои преимущества.

Что касается Nexus - он отражает практический опыт масштабирования создателя Scrum Кена Швабера и его сподвижников из организации Scrum.org. Этот опыт в частности говорит о том, что при разработке большого продукта существуют две самые болезненные проблемы:

⦁ Зависимости. Они приводят к тому, что команды ожидают или даже блокируют друг друга, ломают чужой код, замедляя друг друга и т.д.
⦁ Интеграция. По отдельности команды могут создавать работающий код, но продукт в целом может при этом быть не работоспособным.

Важно отметить, что эти 2 проблемы в принципе отсутствуют, если над продуктом работает только одна команда. Проблемы возникают именно при масштабировании. Однако фреймворк Scrum, определенный в Руководстве по Scrum, практически ничего не говорит о таких «масштабированных» ситуациях.

Идея Nexus очень проста: нужно дополнить Scrum несколькими простыми элементами, помогающими прежде всего решить две упомянутые проблемы. Эти дополнительные элементы описаны в Nexus Guide – кратком бесплатном руководстве, доступном на сайте Scrum.org.
Давайте теперь рассмотрим обе проблемы на реальном примере.

Проблема №1
Зависимости-киллеры.

На картинке ниже Вы можете видеть набор функциональных модулей реального большого продукта для retail-домена, который разрабатывает распределенная интернациональная команда, состоящая из более чем 200 человек. Размер каждого эллипса зависит от оценки трудоемкости требований в данном модуле: чем больше трудоемкость – тем больше эллипс. Два эллипса пересекаются, если между соответствующими модулями есть зависимости: связанные требования, общий код, и др.

Как видно из картинки, команде, работающей, например, над компонентом Order Management, необходимо как минимум координировать свою работу с командами, работающими над 7 другими связанными компонентами. И это не считая так называемых внешних зависимостей, связанных со специалистами, находящимися вне продуктовой команды. В нашем реальном кейсе такие зависимости неоднократно приводили (особенно в начале разработки) к простою команд, вынужденной работе над низкоприоритетным фичами, недостижению целей Спринта и другим негативным последствиям.

Nexus и Scaled Professional Scrum помогают справиться с этими проблемами за счет ряда практик, в частности:
⦁ Правильный выбор структуры команд, Бэклога продукта и архитектурных решений, позволяющий минимизировать зависимости
⦁ Расширение практики Product Backlog refinement, которая из необязательной активности в Scrum становится обязательным событием с фокусом на минимизацию зависимостей и кросс-командное взаимодествие
⦁ Обнаружение, визуализация и минимизация зависимостей во время планирования спринта

Прочитать про это подробнее можно в Nexus Guide и на страничке Scrum.org/Nexus. Познакомиться с этим на практике лучше всего на тренинге Scaled Professional Scrum with Nexus.