Интеграция с GitHub и Jenkins

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

Работа с Git и GitHub

То, как вы работаете с git, важно. Выбор правильной модели ветвления может и будет влиять на вашу работу и общение с товарищами по команде. Если вы используете git сейчас и несете багаж из ваших времен Subversion, пришло время переосмыслить, как вы выполняете ветку. Следующий пост будет опираться на подходящую модель ветвления для поддержки интеграции. Пару недель назад я наткнулся на отличную статью Винсента Дриссена с заголовком «Успешная модель ветвления Git» . Я настоятельно рекомендую проверить это, поскольку он предоставляет подробное описание одного возможного подхода к ветвлению с помощью git, который подходит для этого поста и работает.

Модель ветвления Gits обеспечивает плавное распараллеливание работы, а запросы запросов в GitHub позволяют обсуждать исходный код и эффективный процесс проверки кода. В идеальном мире каждый разработчик объединяет последнюю версию мастер-кода, запускает полный набор тестов с функцией, над которой они работали, чтобы предотвратить любые проблемы и исправления, которые могут возникнуть после перехода к мастеру. К сожалению, это не всегда так, поэтому имеет смысл автоматизировать весь процесс. Здесь я предлагаю, чтобы Дженкинс объединил изменения запроса извлечения в целевую ветвь, запустил набор тестов и анализ сонара / контрольного стиля для этой объединенной сборки и уведомил разработчиков через список запросов извлечения HitBubs, если этот запрос извлечения готов или даже достоин обзор кода.

Настройка Дженкинс

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

• Плагин клиента GIT ( плагин совместно используемой библиотеки для других плагинов Jenkins, связанных с Git)
• Плагин GIT (Этот плагин интегрирует GIT с Jenkins)
• Плагин GitHub API (этот плагин предоставляет GitHub API для других плагинов)
• Плагин GitHub (этот плагин интегрирует GitHub в Jenkins)
• GitHub Pull Request Builder (этот плагин создает запросы на извлечение в GitHub и сообщает о результатах)

Теперь вам нужно разрешить Jenkins взаимодействовать с GitHub, настроив доступ к GitHub Web Hook. Перейдите к настройке системы Jenkins, нажав Jenkins -> Manage Jenkins -> Configure system. Вы должны увидеть следующую запись в нижней части страницы:

Выбор параметра «Автоматически управлять URL-адресами перехвата Jenkins» позволяет настроить учетные данные GitHub для использования:

• URL API: https: // GITHUB_HOST: GITHUB_PORT / api / v3
• Имя пользователя: USER
• Знак OAuth: TOKEN

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

Заставь Дженкинса доверять GitHub

Если вы используете локальный экземпляр GitHub, у вас могут возникнуть проблемы с вашими самозаверяющими сертификатами. Чтобы обойти эту проблему, необходимо экспортировать SSL-сертификат целевого приложения, импортировать его в JVM TrustStore сервера Jenkins и перезапустить Jenkins, чтобы Jenkins доверял целевому приложению. Хорошая новость заключается в том, что это нужно делать только один раз за всю жизнь Дженкинса. Для этого просто выполните следующие три шага:

1. Получить сертификат от местного GitHub:

   1	openssl s_client -connect GITHUB_HOST:GITHUB_PORT < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt

2. Импортируйте сертификат в хранилище ключей. После получения сертификата импортируйте его в JAVA_HOME используемый для запуска Jenkins:

   1	JVM_PATH/bin/keytool -import -alias GITHUB_HOST -keystore JVM_PATH/jre/lib/security/cacerts -file public.crt

3. Не забудьте перезапустить Дженкинс:

   1	service jenkins restart

Обратите внимание, что GITHUB_HOST , GITHUB_PORT и JVM_PATH необходимо заменить фактическими значениями, характерными для вашей среды.

Настройка GitHub

Прежде чем я начну описывать способ настройки GitHub, я хотел бы поделиться с вами одним советом, если ваша организация его не практикует. В целях интеграции и автоматизации, подобных этой, полезно создать отдельного пользователя системы, который будет действовать от имени систем и сценариев, упрощая процесс разработки. В целях интеграции Jenkins и GitHub необходимо предоставить этому пользователю роль соавтора или права Push & Pull. После того, как вы настроите этот пользователь, я рекомендую вам использовать его для настройки вашего экземпляра GitHub.

После того, как вы войдете в GitHub, зайдите в репозиторий по вашему выбору и нажмите на настройки репозитория. После нажатия на Webhooks & Services вам будет предложено добавить новый webhook или новый сервис. Нажмите «Добавить службу» и попробуйте найти Jenkins (имя службы было Jenkins (плагин Git) на момент написания этой статьи). Конфигурация довольно проста, и единственное, что вам нужно предоставить, это перехватить URL-адрес Jenkins и проверить Activate. URL должен выглядеть следующим образом http://JENKINS_HOST:JENKINS_PORT/github-webhook/ .

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

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

Конфигурирование Jenkins

Последний шаг процесса интеграции — это настройка Jenkins с точки зрения обработки входящих веб-хуков и других вещей, таких как комментарии или триггеры. Перейдите к конфигурации системы Jenkins, щелкнув Jenkins -> Manage Jenkins -> Configure system и найдите GitHub Pull Request Builder.

Начните с заполнения базовой конфигурации. Используйте ранее упомянутый URL-адрес API https: // GITHUB_HOST: GITHUB_PORT / api / v3 и токен OAuth. Нажав на Advanced … вы можете точно настроить поведение этого плагина. Большинство настроек по умолчанию подходят для того, чего мы хотим достичь, но я бы предложил обновить фразу Test, чтобы она точно соответствовала.

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

Компромиссы этой интеграции

• Более быстрое обнаружение ошибок
  • Одним из самых больших улучшений в процессе разработки является раннее обнаружение ошибок. Это сильно зависит от качества ваших тестов (юнит-тесты, интеграционные тесты, пользовательские приемочные тесты,…). Возможность протестировать ваш код до слияния позволяет вам предотвратить неработающие сборки. Это также полезно, когда ваша задача включает в себя изменения среды, которые должны быть явно выполнены перед запуском приложения. Неудачные тесты могут указать вам на разработку автоматизированного решения или информирование ваших товарищей по команде и QA, что с этого момента в процессе развертывания требуется дополнительный шаг, чтобы приложение работало должным образом.
• Убрал необходимость откатить изменения
  • Эта точка связана с предыдущей. Иногда вы нарушаете сборку, вносите изменения, которые приводят к неэффективной работе определенных частей кода, нарушают интеграцию со сторонним программным обеспечением или просто портитесь так, что вам нужно откатить свои изменения из основной ветви, чтобы они оставались чистыми. и свежий. На основе вашей тестовой базы эти ситуации могут быть значительно сокращены и сделать процесс более плавным.
• Улучшен процесс проверки кода
  • Процесс проверки кода включает в себя много типов проверки кода. Выполнение анализа Sonar , PMD , CheckStyle или FindBugs снимает некоторую нагрузку с проверяющих ваших изменений, поэтому им не нужно беспокоиться о комментариях, отступах, скобках и других синтаксических аспектах кода и можно сосредоточиться на самой логике. Выполнение этого типа проверки перед слиянием сохраняет основную ветвь в чистоте, поэтому ее легко использовать любому, кто ее проверяет, не создавая необходимости переформатировать или переписывать части кода.
• Варианты настройки
  • GitHubs Webhook предоставляет несколько полезных сведений, которые вы можете использовать в своем определении работы. Это позволяет лучше интегрировать другие процессы, а также настраивать то, что должно быть построено вашей работой. Мой личный фаворит — фильтрация по целевой ветви.
• Дополнительные рабочие места Jenkins
  • Следует учитывать дополнительную нагрузку на Jenkins (в зависимости от вашей инфраструктуры и оборудования), которая, в свою очередь, проявляется следующими способами:
    • Добавлены накладные расходы
      • Создание новых заданий сборки может отрицательно повлиять на скорость вашего экземпляра Jenkins, что, в свою очередь, может потребовать добавления нового узла Jenkins.
    • Новая среда тестирования
      • Тестирование с базой данных, которая не является встроенной или интеграцией с другими системами, может привести к необходимости добавления новой среды тестирования, которая будет использоваться исключительно с целью проверки запросов по запросу.
    • Конфликты, вызванные инфраструктурой
      • Не каждая компания готова предоставить достаточно ресурсов для обеспечения правильных процессов и сред тестирования. Это сценарий, когда вы можете столкнуться с конфликтами, вызванными инфраструктурой, когда две проверки по запросу выполняют проверку кода на одной базе данных или системе. Эту проблему можно решить путем регулирования сборок с помощью плагина Throttle Concurrent Builds .

Что дальше

Этот пост должен был дать вам представление о том, как максимально использовать ваши текущие инструменты CI, описав, что может принести вам интеграция и как заставить GitHub и Jenkins общаться друг с другом. Это первая половина того, что вам нужно сделать. В моем следующем посте под названием «Проверка запросов GitHub и Jenkins» я расскажу о конфигурации задания Jenkins и о том, как сделать необходимую информацию доступной там, где она вам нужна.