Безопасность 

Jenkins программное обеспечение. Jenkins. Continuous Integration – это просто. Ну, почти☺. Создание пользователя для GitHub


Jenkins предоставляет услуги непрерывной интеграции для разработки программного обеспечения. Это серверная система, работающая в контейнере сервлетов, таком как Apache Tomcat. Он поддерживает инструменты SCM, включая AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase и RTC и может выполнять проекты на основе Apache Ant и Apache Maven, а также произвольные сценарии оболочки и командные команды Windows. Первым разработчиком Дженкинса является Кохсуке Кавагути . Выпущенный под лицензией MIT, Дженкинс является свободным программным обеспечением.

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

Версии

Дженкинс

Версия Дата выхода
1,656 2016-04-03
2,0 2016-04-20

Дженкинс 1.x против Дженкинса 2.x

Дженкинс (и по сей день) является системой непрерывной интеграции (CI), которая позволяет автоматизировать процесс разработки программного обеспечения, такой как создание кода для триггеров фиксации SCM. Однако растущая потребность в непрерывной доставке (CD) потребовала, чтобы Дженкинс эволюционировал для чистой системы CI к соединению CI и CD. Кроме того, потребность в индустриализации рабочих мест Дженкинса растет, и классические работы Jenkins 1.x Freestyle/Maven jobs стали слишком ограниченными для определенных потребностей.

Под Jenkins 1.xa плагин под названием workflow-plugin появился, чтобы позволить разработчикам писать код для описания заданий. Jenkins 2 идет дальше, добавляя встроенную поддержку Pipeline as Code . Главное преимущество заключается в том, что конвейеры, являющиеся файлами сценариев Groovy, могут быть более сложными, чем автономные пользовательские задания freestyle, и могут контролироваться версиями. Jenkins 2 также добавляет новый интерфейс, который позволяет легко визуализировать различные «этапы», определенные в конвейере, и следить за ходом всего конвейера, например, ниже:

Полный обзор того, что Jenkins 2 добавляет к Jenkins, см. В обзоре Jenkins 2 .

Дженкинс полный Введение в одном месте

1. Дженкинс:

Jenkins - инструмент непрерывной интеграции с открытым исходным кодом, написанный на Java. Проект был раздвоен из Хадсона после спора с Oracle.

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

Особенности: Jenkins предлагает следующие основные функции из коробки, и многие другие могут быть добавлены через плагины:

Простота установки: просто запустите java -jar jenkins.war, разверните его в контейнере сервлетов. Нет дополнительной установки, нет базы данных. Предпочитаете установщик или собственный пакет? У нас есть и те. Простая конфигурация: Jenkins можно полностью настроить из своего дружественного веб-интерфейса с обширными проверками на лету и встроенной справкой. Богатая экосистема плагинов: Jenkins интегрируется практически с любым SCM или встроенным инструментом, который существует. Просмотр плагинов. Расширяемость: большинство частей Jenkins могут быть расширены и изменены, и легко создавать новые плагины Jenkins. Это позволяет вам настроить Jenkins в соответствии с вашими потребностями. Распределенные сборки: Jenkins может распространять сборки / тестовые нагрузки на несколько компьютеров с различными операционными системами. Создание программного обеспечения для OS X, Linux и Windows? Нет проблем.

Монтаж:

$ wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - $ sudo sh -c "echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list" $ sudo apt-get update $ sudo apt-get install jenkins to do more refer link:

Каталог JENKINS_HOME Дженкинсу необходимо пространство на диске для выполнения сборки и хранения архивов. Вы можете проверить это местоположение на экране конфигурации Дженкинса. По умолчанию этот параметр установлен в ~ / .jenkins, но вы можете изменить его одним из следующих способов: Установите переменную окружения «JENKINS_HOME» в новый домашний каталог перед запуском контейнера сервлета. Установите системное свойство «JENKINS_HOME» в контейнер сервлетов. Задайте запись среды JNDI «JENKINS_HOME» в новый каталог. Дополнительную информацию о том, как это сделать для контейнера, см. В сборке конкретных контейнеров. Вы можете изменить это местоположение после того, как вы использовали Дженкинса какое-то время. Для этого полностью остановите Дженкинса, переместите содержимое из старого JENKINS_HOME в новый дом, установите новый JENKINS_HOME и перезапустите Jenkins. JENKINS_HOME имеет довольно очевидную структуру каталогов, которая выглядит следующим образом:

JENKINS_HOME

Config.xml (jenkins root configuration) +- *.xml (other site-wide configuration files) +- userContent (files in this directory will be served under your http://server/userContent/) +- fingerprints (stores fingerprint records) +- plugins (stores plugins) +- workspace (working directory for the version control system) +- (sub directory for each job) +- jobs +- (sub directory for each job) +- config.xml (job configuration file) +- latest (symbolic link to the last successful build) +- builds +- (for each build) +- build.xml (build result summary) +- log (log file) +- changelog.xml (change log)

Jenkins Build Jobs:

Создание нового задания для сборки в Jenkins очень просто: просто нажмите на пункт меню «New Job» на панели инструментов Jenkins. Jenkins поддерживает несколько различных типов заданий построения, которые представлены вам, когда вы решите создать новое задание

Проект программного обеспечения Freestyle

Работы по созданию фристайла - это задания общего назначения, которые обеспечивают максимальную гибкость.

Проект Maven «Проект maven2 / 3» - это работа по сборке, специально адаптированная к проектам Maven. Дженкинс понимает файлы Maven pom и структуры проекта и может использовать информацию, полученную из файла pom, чтобы уменьшить работу, необходимую для настройки вашего проекта.

Workflow

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

Мониторинг внешнего задания Задание задания «Мониторинг внешнего задания» позволяет следить за неинтерактивными процессами, такими как задания cron.

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

1. Построение программного проекта (свободный стиль)

Дженкинс может использоваться для выполнения типичной работы сервера сборки, такой как непрерывная / официальная / ночная сборка, запуск тестов или выполнение некоторых повторяющихся пакетных задач. Это называется «программным проектом свободного стиля» в Дженкинсе. Настройка проекта. Перейдите на верхнюю страницу Jenkins, выберите «Новое задание», затем выберите «Построить проект со свободным стилем». Этот тип задания состоит из следующих элементов: необязательный SCM, например CVS или Subversion, где находится исходный код. дополнительные триггеры для управления, когда Дженкинс выполнит сборку. какой-то скрипт сборки, который выполняет сборку (ant, maven, shell-скрипт, командный файл и т. д.), где реальная работа выполняет дополнительные шаги для сбора информации из сборки, такие как архивирование артефактов и / или запись javadoc и test Результаты. необязательные шаги для уведомления других людей / систем с результатом сборки, таких как отправка электронной почты, мгновенных сообщений, обновление трекера и т. д.

Создает проекты, не связанные с источником. Иногда бывает необходимо создать проект просто для демонстрационных целей или недоступен доступ к хранилищу SVN / CVS. Выбрав для настройки проекта как «Нет» в разделе «Управление исходным кодом», вам необходимо:

  1. Постройте проект хотя бы один раз (он не удастся), но Дженкинс создаст структуру jenkins / workspace / PROJECTNAME /
  2. Скопируйте файлы проекта в jenkins / workspace / PROJECTNAME /
  3. Постройте снова и настройте соответствующим образом

Дженкинс устанавливает переменные среды

Когда выполняется задание Дженкинса, он устанавливает некоторые переменные среды, которые вы можете использовать в своем сценарии оболочки, командах пакетной обработки, сценарии Ant или Maven POM. См. Список переменных, нажав на ENVIRONMENT_VARIABLE.

Настройка автоматических сборок

Сборка в Jenkins может запускаться периодически (по расписанию, указанному в конфигурации) или когда исходные изменения в проекте были обнаружены или их можно автоматически запускать, запросив URL-адрес:

Это позволяет подключать Jenkins к различным настройкам. Для получения дополнительной информации (в частности, с помощью включенной безопасности) см. API удаленного доступа.

Создает с помощью исходных изменений

Вы можете заставить Jenkins опросить вашу систему контроля версий за изменения. Вы можете указать, как часто Дженкинс опробовывает вашу систему контроля версий, используя тот же синтаксис, что и crontab в Unix / Linux. Однако, если ваш период опроса короче, чем требуется для опроса вашей системы контроля версий, вы можете получить несколько сборок для каждого изменения. Вы должны либо настроить период опроса дольше, чем время, затрачиваемое на опрос вашей системы контроля версий, или использовать триггер после фиксации. Вы можете просмотреть журнал опроса для каждой сборки, чтобы узнать, сколько времени потребовалось для опроса вашей системы.

В качестве альтернативы вместо опроса с фиксированным интервалом вы можете использовать триггер URL (описано выше), но с / polling вместо / build в конце URL-адреса. Это заставляет Дженкинс опробовать SCM для изменений, а не для немедленного создания. Это предотвращает запуск Jenkins сборки без каких-либо существенных изменений для коммитов, влияющих на модули или ветви, не связанные с заданием. При использовании / опросе задание должно быть настроено для опроса, но расписание может быть пустым.

Создает по электронной почте (sendmail)

Если у вас есть учетная запись root вашей системы, и вы используете sendmail, я нашел ее проще всего настроить / etc / aliases и добавить следующую запись: jenkins-foo: "| / bin / wget -o / dev / null

а затем запустите команду «newaliases», чтобы сообщить об этом изменениям в sendmail. Всякий раз, когда кто-то отправляет электронное письмо в «jenkins-foo @ yoursystem», это вызовет новую сборку. Подробнее см. В настройке sendmail. Создает по электронной почте (qmail) С помощью qmail вы можете написать /var/qmail/alias/.qmail-jenkins следующим образом: | / bin / wget -o / dev / null http: // YOURHOST / jenkins / job / PROJECTNAME / build "

2. Создание проекта Maven

Дженкинс предоставляет тип задания, посвященный Maven 2/3. Этот тип работы объединяет Дженкинса с Maven 2/3 и обеспечивает следующие преимущества по сравнению с более общим программным проектом свободного стиля.

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

Дженкинс слушает исполнение Maven и выясняет, что нужно делать, когда он сам по себе. Например, он автоматически записывает отчет JUnit, когда Maven запускает тестовую фазу. Или, если вы запустите цель javadoc, Дженкинс автоматически запустит javadoc.

Jenkins автоматически создает зависимости проекта между проектами, которые объявляют зависимости SNAPSHOT между собой. Увидеть ниже. Таким образом, в основном вам просто нужно настроить информацию SCM и какие цели вы хотите запустить, а Дженкинс все выяснит.

Этот тип проекта может автоматически предоставлять следующие функции:

Архивные артефакты, созданные сборкой

Запуск заданий для проектов, которые являются зависимыми от нисходящего потока

Разверните свои артефакты в репозиторий Maven

Результаты тестирования прорыва по модулю

Необязательно перестраивать только измененные модули, ускоряя ваши сборки

Автоматическое построение цепочки из зависимостей модулей

Дженкинс читает зависимости вашего проекта от вашего POM, и если они также построены на Jenkins, триггеры настроены таким образом, что новая сборка в одной из этих зависимостей автоматически запустит новую сборку вашего проекта. Дженкинс понимает все виды зависимостей в POM. А именно, родительский POM

section of your project Section of your project section of your project section of your project

Этот процесс учитывает версии, поэтому вы можете иметь несколько версий / ветвей вашего проекта на одном Jenkins и правильно определять зависимости. Обратите внимание, что диапазоны версий зависимостей не поддерживаются, см. [ Https://issues.jenkins-ci.org/browse/JENKINS-2787] по этой причине.

Эта функция может быть отключена по требованию - см. Параметр конфигурации Сборка при каждом создании зависимости SNAPSHOT

Монтаж:

1. войдите в Управление Jenkins >> configure System

  1. в maven tab "Нажмите на установку maven ......

Вы можете либо заставить Jenkins автоматически установить определенную версию Maven, либо указать путь к локальной установке Maven (вы можете настроить столько версий Maven для своих проектов сборки, сколько захотите, и использовать разные версии Maven для разных проектов. Если вы установите флажок «Установить автоматически», Jenkins загрузит и установит запрошенную версию Maven для вас и установит ее в каталог инструментов в домашнем каталоге Jenkins.

Как это использовать

Сначала вы должны настроить установку Maven (этот шаг можно пропустить, если вы используете DEV @ cloud). Это можно сделать, перейдя на экран конфигурации системы (Manage Jenkins-> Configure System). В разделе «Установка Maven»: 1) нажмите кнопку «Добавить», 2) укажите имя «Maven 3.0.3», а затем 3) выберите версию из раскрывающегося списка.

Теперь Jenkins автоматически установит эту версию в любое время (например, на любых новых машинах), загрузив ее из Apache и разархивируя ее.

Создайте новую работу Maven:

  1. Нажатие «Новое задание / Новый элемент» слева
  2. Дайте ему имя
  3. Выберите «Build a Maven 2/3 project»
  4. Сохраните свою работу

Теперь вам нужно настроить свою работу

    Выберите SCM, который вы хотите использовать (например, с помощью git)

    выберите цель maven для вызова

    добавить URL-адрес репозитория и учетные данные.

    проверить частное личное сообщение maven:

Вы также можете определить путь custome для этого же.

5. Проект строительства

Создайте свой проект, нажав на сборку сейчас и нажмите на индикатор выполнения в левой руке «Build Executor Status», чтобы посмотреть, как jenkins устанавливают Maven, проверяют ваш проект и строят его с помощью maven.

Консоль сценариев:

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

Перемещение Дженкинса с одного компьютера на другой

Это помогло мне перейти от Ubuntu 12.04 (Jenkins ver. 1.628) к Ubuntu 16.04 (Jenkins, версия 1.651.2). Сначала я установил Дженкинса из репозиториев .

    Скопируйте JENKINS_HOME (например, / var / lib / jenkins) со старого сервера на новый. С консоли на новом сервере:

    rsync -av username@old-server-IP:/var/lib/jenkins/ /var/lib/jenkins/

Возможно, вам это не понадобится, но мне пришлось

  • Manage Jenkins и Reload Configuration from Disk .
  • Отключите и снова подключите все ведомые устройства.
  • Убедитесь, что в Configure System > Jenkins Location Jenkins URL правильно назначен новому серверу Jenkins.

Настройка прокси-сервера Nginx

На самом деле Дженкинс работает на порту 8080. Мы можем установить прокси-сервер из порта 80 -> 8080, чтобы доступ к Jenkins был доступен через:

Http://.com

вместо стандартного

Http://.com:8080

Начните с установки Nginx.

sudo aptitude -y install nginx

Удалить настройки по умолчанию для Nginx

cd /etc/nginx/sites-available

sudo rm default ../sites-enabled/default

Создайте новый файл конфигурации

sudo touch jenkins

Скопируйте следующий код во вновь созданный файл jenkins .

Upstream app_server { server 127.0.0.1:8080 fail_timeout=0; } server { listen 80; listen [::]:80 default ipv6only=on; server_name ; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; if (!-f $request_filename) { proxy_pass http://app_server; break; } } }

Создайте символическую связь между доступными сайтами и сайтами:

sudo ln -s /etc/nginx/sites-available/jenkins /etc/nginx/sites-enabled/

Перезапустите службу прокси-сервера Nginx

sudo service nginx restart

Теперь Дженкинс будет доступен из порта 80.

У нас есть сервер, на котором лежит множество проектов на WordPress и Magento CMS. Мне как PHP-разработчику была поставлена задача внедрить Jenkins для этих проектов, чтобы публикация изменений исходного кода на сервер происходила быстрее.

К чему нам Continuous Integration?

Вопрос повышения эффективности разработки и сопровождения программных продуктов для меня, как для веб-разработчика, всегда был и остается актуальным и интересным. Процессы сборки проекта и публикации его на сервер являются тем звеном, которое может быть легко автоматизированно при помощи средств Continuous Integration (CI) .

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

Принцип работы CI довольно прост. В моем случае участвовало 3 сервера:

  • Сервер системы контроля версий (СКВ), где хранится репозиторий с рабочей версией проекта, в который разработчик сохраняет свои изменения.
  • Сервер Continuous Integration, на котором установлена одна из систем управления CI.
  • Сервер, где развернута рабочая версия проекта.

Сразу после изменения репозитория в системе контроля версий, сервер СКВ инициирует выполнение задачи на сервере CI (как правило, с помощью веб-хука). Эта задача выполняет сборку и развертывание исходного кода из репозитория СКВ на сервер рабочей версии проекта.

Развертывание исходного кода из репозитория СКВ на сервер рабочей версии проекта.

Более подробно о преимуществах, которые предоставляет использование Continuous Integration, можно почитать в этой статье .

Данное руководство собирает в себе информацию, достаточную для того, чтобы быстро сконфигурировать систему CI Jenkins и начать работу с ней. Также здесь представлена информация по настройке и организации взаимодействия такой популярной системы CI, как и не менее известной системы контроля версий Git. В качестве веб-сервиса для git будем использовать GitHub .

Внимание, задача

Необходимо установить и настроить Jenkins таким образом, чтобы при push-е в репозиторий GitHub происходило обновление измененных файлов на сервере рабочей версии проекта. В наличии:

  • Сервер Debian 8.2 x64.
  • Система на локальной машине: Linux Mint 17.2.

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

Решение

1. Установка Jenkins

Установку выполним на выделенном для CI сервере. Вводим следующие команды для добавления репозитория Jenkins в список репозиториев системы:

Sudo wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add - sudo echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list

Обновим apt и установим Jenkins:

Sudo apt-get update sudo apt-get install jenkins Перезапустим Jenkins: /etc/init.d/jenkins restart

Теперь порт 8080 сервера CI будет «прослушиваться» Jenkins. Это значит, что при переходе в браузере по адресу 8080 , пользователь попадет в панель управления Jenkins. Конечно, такой способ доступа является не очень удобным, поэтому на сервере CI можно настроить доступ к Jenkins с помощью виртуальных хостов в Apache или Nginx.


Приветственное окно Jenkins.

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

2. Добавление администратора

Manage Jenkins → Configure Global Security (глобальная настройка безопасности).

1. Заполняем необходимую информацию:

  • Enable security — true; //включить защиту;
  • Jenkins’own user database — «Jenkins’ own user database»; //использовать для авторизации базу данных Jenkins;
  • Authorization — «Matrix-based security»; //матричное распределение прав доступа (распределение прав на уровне проектов);
  • User/group to add — «admin». //предоставляем пользователю «admin» право доступа в панель управления Jenkins.

Добавление администратора.

2. Сохраняем настройки.

Теперь при попытке входа в панель управления Jenkins будет требовать от пользователя авторизоваться.

3. Создание пользователя для GitHub

Теперь необходимо создать учетные данные для доступа GitHub к серверу Jenkins.

В панели управления Jenkins переходим Manage Jenkins → Manage Users → Create User . Заполняем форму регистрации, идентичную той, которая была при регистрации администратора, нажимаем Sign Up .

После создания пользователя следует дать ему необходимые права. Для этого перейдем в Manage jenkins → Configure Global Security (настройка глобальной безопасности).

Из всех этих настроек нам необходима матрица безопасности .

Для начала добавим пользователя в эту матрицу. В поле «User/group to add» вводим имя созданного пользователя и нажимаем Add . Пользователь появится в матрице. Предоставим ему права на чтение и сборку. Для этого в подстолбцах Read и Build столбца «Job» напротив имени созданного пользователя устанавливаем чек-боксы и нажимаем Save .


Создание пользователя для GitHub.

4. Установка плагина для GitHub

Переходим в Manage Jenkins → Manage Plugins → Вкладка «Available» . Выбираем для установки три плагина:

  • Github Authentication plugin;
  • GitHub plugin;
  • GitHub API Plugin.

Нажимаем на кнопку «Download now and install after restart» и ожидаем завершения установки.

5. Настройка сервера для работы с Jenkins

На продукционном сервере проекта (куда будет производиться автодеплой) необходимо создать пользователя «jenkins»:

Ssh-keygen

И вводим необходимую информацию.

Также для доступа необходимо добавить публичный ключ в файл... /jenkins/.ssh/authorized_keys (если файла нет, его необходимо создать)

Кроме этого требуется создать на GitHub открытый SSH ключ для данного сервера. О том, как это сделать, можно посмотреть .

Данный этап завершен.

Если что-то по ssh-аутентификации является непонятным, рекомендую прочитать очень полезную на данную тему.

6. Настройка доступа к серверу

Для того чтобы Jenkins при автодеплое на сервере с рабочей версией проекта мог авторизовываться на нем, в панели управления требуется создать необходимые данные для аутентификации. Для этого в панели управления Jenkins переходим Credentials → Global credentials → Add Credentials и делаем следующее:

  1. В качестве Kind выбираем «SSH Username with private key»;
  2. Username — вводим имя созданного на сервере пользователя («jenkins») ;
  3. Private Key — «Enter directly», в текстовое поле копируем все содержимое файла приватного ключа jenkins-пользователя. («.../jenkins/.ssh/id_rsa»);
  4. Нажимаем «OK».

Настройка доступа к серверу.

Теперь необходимо настроить подключение к серверу. Для этого в панели управления jenkins перейдем Manage Jenkins → Manage Nodes → New Node . Производим следующие действия:

  1. Вводим имя продукционного сервера (к примеру — «target»), устанавливаем «Dumb Slave», нажимаем «OK»;
  2. Вводим путь к корневой директории Jenkins на продукционном сервере. В качестве корневой директории на целевом сервере обычно выбирается директория пользователя jenkins («.../jenkins»);
  3. Вводим «Labels»; например — «target_server». Label — это метка, по которой задача будет привязываться к конкретному серверу;
  4. Host — вводим имя хоста, к которому будем обращаться;
  5. Credentials — выбираем ранее созданные данные для аутентификации;
  6. Нажимаем «Save».

Через некоторое время, подключение к серверу должно успешно установиться. Если все прошло успешно, в Manage Jenkins → Manage Nodes вы должны увидеть примерно следующую картину:


Настройка подключения к серверу.

Если подключение не устанавливается, нажимаем на созданное подключение («target»), выбираем «Log» в левом навигационном меню и смотрим, что произошло не так.

Наиболее распространенными ошибками являются:

Первое решение — изменить в настройках подключения корневую директорию на домашнюю директорию пользователя Jenkins.

Второе решение — предоставить пользователю Jenkins права на запись и чтение указанной в настройках подключения директории.

7. Настройка хука GitHub

Для GitHub-репозитория, который будет использоваться, необходимо настроить веб-хук так, чтобы при обновлении репозитория, хук отсылал запрос на обновление Jenkins. Для этого:

  • Переходим в созданный репозиторий на GitHub-е.
  • «Settings» → «Webhooks & services».
  • «Add webhook».
  • Вводим «Payload URL» (куда будет обращаться GitHub). Он должен иметь следующий формат
    <протокол>: //<имя пользователя для github в jenkins>: <пароль пользователя github в jenkins>@<домен>/github-webhook/
    (например — http://github:[email protected]:8080/github-webhook/).
  • «Content type» — «application/json».
  • «Which events would you like to trigger this webhook?» — «Just the push event».
  • «Active» — true.
  • Нажимаем «Add webhook».

Веб-хук создан.

8. Создание задачи Jenkins

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

  • Нажимаем «New Item».
  • Вводим название задачи в поле «Item name».
  • Выбираем «Freestyle project» и нажимаем «OK».
  • «Restrict where this project can be run» — вводим имя метки, которое было выбрано при добавлении сервера (например — «target_server»).
  • «Source Code Management» — выбираем «Git» и вводим адрес репозитория в поле «Repository URL» (например — «[email protected]: TestCi/Continuous-integration.git»).
  • В поле «Credentials» выбираем ранее созданные учетные данные.
  • «Build Triggers» — «Build when a change is pushed to GitHub».
  • «Build» — «Execute shell» (shell-скрипт будет выполняться при каждом push-е на github): sudo rsync -a —cvs-exclude —delete —omit-dir-times. / <директория проекта> sudo chown -R www-data: jenkins < директория проекта>

    Первая строка производит синхронизацию на продукционном сервере рабочей директории Jenkins с целевой директорией проекта. Вторая строка — установка владельца файлов проекта.

    — статья по настройке виртуальных хостов в Nginx;

  • digitalocean.com — статья по настройке виртуальных хостов в Apache.

В данной статье будут изложены основные идеи Continuous Integration, а также приведен пример быстрого развёртывания Jenkins на проекте.

Термины и определения

Прежде чем приступать к основной части, необходимо дать определение используемых терминов.

Непрерывная интеграция (CI, Continuous Integration) - практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. [wiki ]

Jenkins – проект для непрерывной интеграции с открытым исходным кодом, написанный на Java. [jenkins.io ]

Автоматизированное тестирование – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования. [protesting ]

Немного о CI

В настоящее время Continuous Integration – одна из практик, применяемых в Agile методологии. В подобных методологиях она удачно сочетается с другими практиками, такими как unit тестирование, рефакторинг, стандарт кодирования. Но даже без них можно получить пользу от непрерывной интеграции. Из определения Continuous Integration следует его самая главная идея – найти ошибку на ранней стадии проще для разработки и дешевле для бизнеса. Поэтому, если в проект вносятся достаточно большие изменения, необходимо обязательно проводить тестирование (unit-тесты, автоматизированные тесты).

Стоит отметить, что режимов запусков может быть несколько:

  • тесты запускаются после каждого коммита – это идеальный вариант для unit-тестов и спорный для end-to-end, почему поясню ниже;
  • тесты запускаются один раз в сутки (чаще всего ночью). Этот вариант не подойдет для unit-тестов, поскольку приложение долгое время может оставаться в нерабочем виде, но достаточно неплохой вариант для автоматизированных функциональных end-to-end тестов, особенно когда тесты занимают длительное время;
  • тесты запускают перед выпуском релиза – один из самых плохих вариантов использования, но и его можно тоже использовать в условиях ограниченных ресурсов, а новая функциональность, разрабатываемый в своей ветке, проверяется один или несколько раз в день.

Инструментов для CI существует достаточно много:

  • из локальных можно выделить – GitLab CI, TeamCity, Bamboo, Jenkins, Hudson, Circle CI;
  • облачные – BitBucket Pipelines, Heroku CI, Travis, Codeship, Buddy CI, AWS CodeBuild.

Jenkins

Почему стоит использовать именно Jenkins:

  • бесплатный и надёжный;
  • большое количество мануалов по работе, а значит учиться работать с ним проще;
  • легко забэкапить и развернуть на другой машине в течение 5 минут;
  • осуществлять управление можно конфигурированием и перемещением xml файлов.

Из минусов отметил бы:

  • частый выход новых версий, если используется не LTS;
  • интеграция с различными сервисами завязана на множество различных плагинов;
  • иногда может появится задача, которая требует нестандартного подхода.

Приведу запомнившийся пример. Необходимо поддерживать несколько версий продукта, которые работают с разными версиями java и если проект запускался не с той версией, то тесты стабильно начинали падать. Для этого пришлось добавлять плагин – Environment Injector, также добавить дополнительный шаг в сборке, который в зависимости от версии продукта изменял параметры рабочего окружения для использования конкретной версии java:

В случае возникновения кейса, описанного в примере выше, на TeamCity достаточно было указать версию java при запуске прогона.

Отдельно отмечу, что в данном случае Jenkins использовался исключительно для запуска автоматизированных тестов, т.к. они были достаточно длительными и требовали высокого уровня производительности.

Идеальный процесс разработки можно представить так:

  • разработчик отправляет код в репозиторий;
  • на сервере непрерывной интеграции изменения объединяются с основным кодом, выполняются юнит-тесты;
  • полученные на предыдущем шаге артефакты загружаются в отдельную тестовую среду, где приложение тестируется автотестами;
  • дальше всё проверяется для попадания на продакшн;
  • развёртывание на продакшене.


Установка Jenkins

Про установку написано достаточно много и подробно, самый лучший мануал конечно от разработчиков – Installing Jenkins.

Резервное копирование

Можно использовать встроенные плагины, но могут быть проблемы совместимости разных версий плагинов, поэтому для этой цели мы пришли к использованию bash скриптов которые входили в отдельную сборку, которая запускалась несколько раз в день\неделю. Например, скрипт jenkins-backup.sh – выполнял сохранение текущей рабочей конфигурации: view, job, настроек окружения, плагинов, которые сохранялись в отдельный архив, который можно переносить и использовать далее.

Установка из сохраненной копии

1.Необходимо установить java и инструмент архивации, в нашем случае unzip.

2. Разархивировать ранее сохранённый файл (предварительно перейдя в каталог с сохранным архивом):

unzip Jenkins.zip -d %path_To_Jenkins%

3. Перейти в каталог Jenkins и выполнить запуск Jenkins командой

cd %path_To_Jenkins% && java -jar jenkins.war

4. Зайти в WEB интерфейс по порту 8080.

Если вы работаете с linux машиной по ssh, то после закрытия соединения, вероятно, Jenkins будет остановлен. Для того чтобы избежать такого поведения можно использовать такой приём: выполнить команду с добавлением символа & – в результате команда будет выполняться в фоне, а управление будет возвращено обратно в командную строку, а для того чтобы при отключении от удаленной системы не завершались запущенные задачи можно использовать утилиту nohup, которая позволяет процессам продолжать работу даже после того, как вы выйдете из системы:

nohup java -jar jenkins.war &

Добавление Jenkins в службы

Для того чтобы в linux системах избежать ситуации, описанной в предыдущем абзаце, можно установить Jenkins как службу, для того чтобы каждый раз после перезагрузки Jenkins стартовал автоматически. Для этого необходимо создать файл /etc/systemd/system/jenkins.service командой:

Sudo cat /etc/systemd/system/jenkins.service sudo vi /etc/systemd/system/jenkins.service

и добавить содержимое в jenkins.service:

Description=Jenkins Daemon Environment="JENKINS_HOME=%path_To_Jenkins%" ExecStart=/usr/bin/java -jar %path_To_Jenkins%/jenkins.war User=имя текущего пользователя WantedBy=multi-user.target

Выполнить перезапуск службы сервисов: sudo systemctl daemon-reload

Команда для запуска сервиса jenkins: sudo systemctl start jenkins.service

перезапуска sudo systemctl restart jenkins.service

Важно отметить , что файл jenkins.war может быть расположен где угодно. Для того чтобы “подхватились” текущие параметры проекта, можно использовать команду, которая выполнит монтирование раздела Jenkins к работающему jenkins:

sudo mount -o bind /%path_To_Jenkins%/ ~/.jenkins/

Такой вариант будет работать только до перезагрузки системы, поэтому можно создать симлинк в директории ~/:

cd ~/ && sudo ln -s /%path_To_Jenkins%/ .jenkins

Добавление и подготовка к работе node в Jenkins

Данный раздел написан с учетом практики, что жизненный цикл у Jenkins и node ограничен, например, 2 неделями или месяцем.

Для добавления slave node в Jenkins можно добавить каждую машину руками, но из-за этого требуется постоянно заходить на машину и выполнять одни и те же операции, а это приводит к мысли, что всё можно максимально автоматизировать.
Для этого достаточно создать несколько Job, которые будут последовательно выполнять:

  1. заказ машин для добавления в качестве slave node в Jenkins;
  2. добавлять ранее заказанные машины в Jenkins с использованием rest api или Jenkins cli;
  3. выполнять развертывание необходимого окружения.

Все выше названные действия можно выполнять, используя дополнительные инструменты: ansible – для развертывания и настройки необходимых параметров и docker – как для развертывания Jenkins, так и для установки окружения на slave nodes.

Заключение

Главное, чтобы словосочетание “непрерывная интеграция” были на вашем проекте не только красивыми новомодными словами, но и действиями. И если вы, хотя бы минимально, будете соблюдать принципы CI, то проблем в жизненном цикле разработки станет гораздо меньше, а сам процесс станет приятнее. Опрос с интересной статистикой использования CI на проекте –

Прогрессивная часть девелоперской среды практикует методику непрерывной интеграции (CI ), и iOS-отдел компании Лайв Тайпинг решил к ней примкнуть, развернув сервер для сборок на платформе Jenkins. С тех пор началась совсем другая жизнь.

Что мы получили в итоге:

  1. Сервер начинает сборку:
    1. по веб-хуку в случае push’а в master-ветку;
    2. по команде в чате slack с указанием нужной ветки и доп. параметров.
  2. Выполняет Unit и UI -тесты.
  3. Получает следующие метрики:
    1. покрытие кода тестами;
    2. количество строк кода;
    3. дублирование кода;
    4. цикломатическая сложность кода.
  4. Архивирует проект в ipa, далее отправляет его на сервер сборок (собственной разработки) и отправляет в slack ссылку на сборку.

Для начала ознакомьтесь со следующими оговорками и поймите, сопоставим ли наш гайд с вашими задачами:

  1. сервер разворачивался под нужды iOS-разработки;
  2. установка большинства вспомогательных программ через homebrew, включая и сам Jenkins (быстрые обновления и удобство использования);
  3. использование xcodebuilder для всех задач сборки-тестирования (отказались от использования xctool из-за невозможности запуска UI -тестов);
  4. в качестве репозитория у нас используется GitLab;
  5. для хранения сборок мы используем сервер собственной разработки. Для каждой сборки генерируется уникальный URL , и далее достаточно открыть ссылку с мобильного устройства в браузере и нажать «Установить» - благодаря аккаунту Enterprise любой может установить приложение на телефон. Из-за специфичности действий, связанных с отправкой файлов на наш сервер, этот этап в статье не описывается;
  6. все наши проекты используют систему управления зависимостями СocoaPods.

Руководство получилось довольно громоздким, и мы решили разбить его на две части. Эта часть посвящена базовой установке и настройке Jenkins.

Что необходимо:

  1. Mac c установленным OS X и Xcode (В нашем случае MacBook Pro 2011 года с OS X 10.11.4);
  2. несколько часов свободного времени.

Создание пользователя Jenkins и его настройка

Пользователя можно создать как через консоль, так и используя GUI . Вряд ли во втором варианте возникнут сложности, поэтому мы лучше рассмотрим первый ():

#Создание группы ‘Applications’ dseditgroup -o create -n . -u username -p -r ‘Applications’ applications #Получение идентификатора для группы sudo dscl . -read /Groups/applications #Получение списка идентификаторов для пользователей (будет нужен уникальный идентификатор для пользователя) sudo dscl . -list /Users UniqueID #Создание пользователя (значения идентификаторов должны быть уникальными) sudo dscl . -create /Users/jenkins sudo dscl . -create /Users/jenkins PrimaryGroupID 777 sudo dscl . -create /Users/jenkins UniqueID 1777 sudo dscl . -create /Users/jenkins UserShell /bin/bash sudo ddcl . -create /Users/jenkins RealName "Jenkins" sudo dscl . -create /Users/jenkins NFSHomeDirectory /Users/jenkins sudo dscl . -passwd /Users/jenkins #Создание домашней директории и установка прав на неё sudo mkdir /Users/jenkins sudo chown -R jenkins /Users/jenkins

Наш пользователь готов, и теперь нам нужно зайти за него. Мы можем произвести вход в систему через GUI , либо зайти, используя консоль:

Sudo -u jenkins -i

Внимание: все дальнейшие действия мы совершаем под пользователем Jenkins.

Установка необходимых программ

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

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2. Установка jenkins:

Brew install jenkins

Установка системы управления зависимостями cocoapods:

Sudo gem install -n /usr/local/bin cocoapods

Чтобы наш сервер автоматически запускался при старте системы, нам необходимо настроить запуск соответствующей задачи для launchd. У нас есть выбор: сделать это через LaunchAgents или LaunchDaemon. Мы воспользуемся именно LaunchAgents, т.к. это упростит* дальнейшую работу с Jenkins. Достаточно посмотреть на таблицу ниже, чтобы понять это:

Daemon Agent
Launch Time System start User login
User Type Non-login Login
Home Folder No Yes
Login Keychain No Yes
iOS Simulator No Yes
Provisioning Profiles No Yes

*Главная проблема запуска через Daemon заключается в том, что нельзя выполнить тестирование, не запустив iOS Simulator (подробнее про разницу использования демона и агента можно прочитать )

Однако из-за выбора LaunchAgents нам нужно решить проблему отсутствия залогиненного пользователя при запуске системы. Для этого необходимо настроить autologin. Мне известен только один способ это сделать: через GUI (Системные настройки -> Пользователи и группы -> Параметры входа -> Автоматический вход). Если кто-то знает, как это сделать через shell - пожалуйста, отпишитесь в комментариях!

Для настройки запуска через LaunchAgents выполним следующие шаги:

1. выгрузим демона (был создан автоматически при установки Jenkins):

Sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.jenkins.plist

2. удалим демона:

Sudo rm /Library/LaunchDaemons/homebrew.mxcl.jenkins.plist

3. создадим агента:

Cd /Users/jenkins/Library/LaunchAgents tap homebrew.mxcl.jenkins.plist

4. настроим агента, используя vim-редактор:

Vim homebrew.mxcl.jenkins.plist

Пример содержимого файла plist:

Label homebrew.mxcl.jenkins ProgramArguments /usr/bin/java -Dmail.smtp.starttls.enable=true -jar /usr/local/opt/jenkins/libexec/jenkins.war -httpListenAddress=0.0.0.0 --httpPort=8080 RunAtLoad UserName jenkins

Здесь стоит обратить внимание на поле httpListenAddress со значением 0.0.0.0 и поле httpPort со значением 8080 - так сервер будет «прослушивать» любые ip-адреса по указанному порту.

Напомню: для закрытия и сохранения файла в редакторе vim вводим:wq
После установки Jenkins доступен по умолчанию по адресу 127.0.0.1 (localhost).
Для доступа из внешней сети можно пробросить порты на маршрутизаторе: 8080 для веб-интерфейса Jenkins и 22 для доступа по ssh.

Установка плагинов для Jenkins

Заходим на сервер Jenkins -> Настроить Jenkins -> Управление плагинами. Во вкладке «Доступные» находим и устанавливаем следующие плагины:

  1. Role-based Authorization Strategy - обеспечение безопасности. Даёт возможность создания групп пользователей с распределением прав;
  2. GitLab Plugin и Gitlab Hook Plugin- плагины для работы с gitlab;
  3. Xcode integration - интеграция с Xcode;
  4. Keychains and Provisioning Profiles Management - облегчает работу с provisioning profile.

Базовая настройка Jenkins

Через веб-интерфейс Jenkins`а заходим в «Настройки», а затем в раздел «Конфигурирование системы». На что здесь стоит обратить внимание:

1. Настройки Xcode Builder. Если вы устанавливали Xcode в стандартную директорию, то настройки менять не нужно. В противном же случае необходимо задать путь для указанных компонентов. Учитывая, что мы запустили сервер с использованием LaunchAgents, то Xcode будет иметь доступ к login.keychain. Но если вы хотите подстраховаться, то можете в этом разделе добавить keychain, как указано на скриншоте (здесь и далее нажмите на изображение для просмотра).

Теперь мы можем загрузить необходимые сертификаты через GUI или через shell в login.keychain, а Xcode будет автоматически подтягивать нужные ему во время сборки.

2. Для настройки доступа по ssh делаем так:

a. генерируем shh-ключ, если его нет (инструкцию для примера можно найти );

b. добавляем ключ в разделе CVS ;


c. для доступа к GitLab перейдём в раздел Credentials на главной странице веб-интерфейса Jenkins. Здесь необходимо добавить закрытый ключ для нашего пользователя (Jenkins в данном случае пользователь, зарегистрированный в GitLab). Вы можете вставить его непосредственно, как показано на примере ниже, или же указать путь к нему:


d. в настройках самого GitLab необходимо указать соответствующий открытый ключ:


3. Для настройки безопасности воспользуемся плагином Role-based Authorization Strategy. Перейдём в настройки через веб-интерфейс Jenkins, а далее в раздел Manage and Assign Roles. Здесь мы сможем создать различные роли, которые назначаются для пользователей и групп, и определить для них права на те или иные операции. Здесь каждый всё делает на своё усмотрение. Но, если вы настроили внешний доступ к серверу, настоятельно рекомендую убрать все права для пользователя «гость».

Создание job’а и настройка сборки проекта

1. На главной странице веб-интерфейса Jenkins выбираем «Создать Item». Далее выбираем пункт «Создать задачу со свободной конфигурацией» и вводим название проекта;
2. на странице настройки job’а первое, что мы сделаем - это перейдём во вкладку «Управление исходным кодом» и настроим загрузку проекта с GitLab. Здесь нам нужно ввести адрес репозитория нашего проекта, указать, с помощью каких полномочий (credentials) сервер получит доступ к GitLab и какую ветку проекта необходимо собрать:


3. Далее переходим в раздел «Сборка». Если вы используете систему управления зависимостями CocoaPods и не добавляете Pod файлы в git, нужно добавить шаг сборки «Выполнить команду shell», в которой запустить установку подов:

#!/bin/bash -l export LANG=UTF-8 pod install if [ $(($(date +"%s") - $(stat -f %m Podfile))) -le 60 ]; then pod install fi

4. Добавляем шаг сборки: Xcode. Если вы используете систему управления зависимостями CocoaPods, то вам не следует указывать значение в поле Target, а в разделе Advanced Xcode build options указать название исполняемой схемы и файла.xcworkspace. Пример минимальной конфигурации показан на скриншотах ниже:



Стоит отметить, что в настройках вашего проекта исполняемая схема должна быть отмечена как shared (контейнер может быть как workspace, так и project):

Работа с сертификатами и provisioning profile

Благодаря плагину Keychains and Provisioning Profiles Management можно значительно упростить работу с установкой provisioning profile.

Добавление provisioning profile:

  1. переходим в настройки Jenkins;
  2. в списке выбираем Keychains and Provisioning Profiles Management;
  3. нажимаем кнопку «Выберите файл», находим свой provisioning profile и нажимаем Upload.

Чтобы указать конкретный Provisioning Profile, если это необходимо, то в настройках job’a в разделе «Cреда сборки» нужно установить флаг Mobile Provisioning Profiles и выбрать один из загруженных профайлов:


Затем в настройках Xcode нужно установить custom xcodebuild arguments, как на скриншоте:


Для загрузки сертификата в связку ключей login.keychain можно воспользоваться GUI (просто кликнуть по сертификату), но такая возможность есть не всегда. Поэтому мы рассмотрим чуть более сложный вариант - добавление через ssh:

  1. скачиваем нужный сертификат на свой Mac и устанавливаем в локальный keychain access двойным кликом;
  2. заходим в keychain access, находим нужный сертификат и экспортируем ключ в формат.p12;
  3. передаём сертификат на сервер:

Scp certificate.crt jenkins@server:/Users/jenkins

certificate - название сертификата;

jenkins - имя пользователя;

server - адрес сервера;

:/Users/jenkins - путь сохраняемого файла;

(Можно использовать параметр для указания нужного порта в формате: scp -P 20 certificate.crt jenkins@server:/Users/jenkins)

4. передаём ключ на сервер:

Scp privatekey.p12 jenkins@server:/Users/jenkins

5. подключаемся к серверу по ssh:

Ssh jenkins@server

6. открываем доступ к связке ключей:

Security unlock-keychain -p password /Users/jenkins/Library/Keychains/login.keychain

7. устанавливаем сертификат:

Security add-certificates ./certificate.crt

8. копируем ключ:

Security import privatekey.p12 -k /Users/jenkins/Library/Keychains/login.keychain -P password -A

Перед запуском

Теперь мы готовы нажать на кнопку Built Now на главной странице веб-интерфейса Jenkins или на странице самого проекта. Жмём и переходим в раздел Console Output начавшейся сборки. Здесь в логах можно найти много полезной информации, включая ошибки.
Если вы всё сделали правильно, то по окончанию сборки в конце лога будет указано: Finished: SUCCESS , а на главной странице Jenkins рядом с названием сборки будет гореть синий индикатор УСПЕХА.

Установка всех необходимых программ и плагинов.

Для начала установим программы, которые будут собирать для нас статистику:

#Определение степени покрытие кода тестами brew install gcovr #Счётчик строк кода brew install cloc #Счётчик строк кода, альтернативный вариант brew install sloccount #Поиск дублирования кода brew install pmd #Генерация отчётов о результатах тестов (также генерирует данные для oclint) sudo gem install xcpretty #Статический анализ кода brew tap oclint/formulae brew install oclint

Интеграция с чатом Slack

Для получения уведомлений о состоянии сборки в командном чате Slack, нам необходимо добавить соответствующую интеграцию с Jenkins в настройках Slack’а. Это можно сделать .
После создания интеграции будет сгенерирован уникальный токен, который необходимо добавить в настройки Jenkins’а (либо в настройки отдельного job’а) - как в примере на скриншоте:


Далее настроим запуск сборок с помощью встроенного механизма команд в Slack’е. Для начала нам необходимо добавить интеграцию. Для этого пройём в подраздел Slash commands в разделе Custom Integrations и нажмём на кнопку Add configurations. Эту операцию можно выполнить .
При настройке вам нужно указать название вашей команды, выбрать метод передачи данных POST и указать URL -адрес, на который будет идти запрос.


Рассмотрим пример формирования URL для запроса подробнее. Наш URL для примера выглядит так:

Http://server:8080/buildByToken/buildWithParameters?job=JenkinsExecutor&token=XXXXXXXXXXXXXXXXX

Разберём его по составляющим:

  1. server - это внешний адрес вашего сервера. Если необходимо, то здесь также указываем нужный порт (в нашем случае 8080);
  2. buildByToken - возможность, предоставляемая плагином Build Authorization Token Root Plugin. Позволяет запускать job по ссылке с указанием токена (в нашем случае XXXXXXXXXXXXXXXXX );
  3. buildWithParameters - указывает на то, что нужно запустить параметризованную сборку;
  4. JenkinsExecutor - название job’а, который мы создадим и будем использовать для запуска других job’ов. О нём речь пойдет ниже;
  5. XXXXXXXXXXXXXXXXX - значение токена, который устанавливается в настройках плагина в конфигурации каждого отдельного job’а.

В качестве примера будем использовать следующую структуру команды:

/build Example test master

  1. /build - название нашей команды;
  2. Example - название job’a;
  3. test - вспомогательный флаг, связанный с запуском тестов и созданием отчётов с метриками;
  4. master - ветка для сборки.

Рассмотренная конфигурация позволит нам запускать сборку любого проекта с указанием нужной ветки, при этом будет использоваться единая команда: /build.

Конфигурация вспомогательного job’a - JenkinsExecutor

Данный job будет нужен нам для того, чтобы запускать другие job’ы. В нём также можно будет обрабатывать ошибки, если пользователь ввёл не существующий проект, и добавить информацию о команде (своеобразный help).
Заходим на сервер и создаём новую задачу со свободной конфигурацией и названием JenkinsExecutor. Далее в настройках job’а выставляем флаг, указывающий на то, что сборка является параметризированной и принимает параметр text. При запуске команды в Slack’е все данные (Example master test) будут передаваться единой строкой в переменной text.

Теперь нам необходимо извлечь значения из переменной text. Для этого переходим в раздел «Сборка» и добавляем шаг сборки «выполнить команду shell». Пример команды:

#Создаём массив из элементов строки, разделённых пробелом IFS=" " read -a array <<< "$text" #Согласно нашему примеру, первое значение - это название проекта JOB_NAME=${array} #Флаг, ответственный за тесты TEST=${array} #Название ветки проекта BRANCH=${array} #Если необходимо, можно также получить другие значения: USER_NAME=${user_name} CHANNEL_NAME=${channel_name}

Для запуска сборки с параметрами отправим POST -запрос на исполнение конкретного job’а. Для этого к предыдущей shell-команде добавляем следующую строчку:

Curl -d TEST=${TEST} -d BRANCH=${BRANCH} -X POST \ -u username:password http://127.0.0.1:8080/job/${JOB_NAME}/buildWithParameters

Обратите внимание, что все запускаемые сборки должны быть параметризированными!

Настройка сборки

1. Первое, на что стоит обратить внимание при настройки job’а - это то, что сборка должна быть параметризированной. Для этого выставляем соответствующий флаг, добавляем текстовые параметры BRANCH и TEST и задаём им параметры по умолчанию:

Здесь стоит отметить, что для переменной BRANCH нужно дополнительно добавить значение по умолчанию. Дело в том, что если вы запустите сборку из Slack без указания ветки, то в переменной BRANCH будет пустое значение и соответственно будет ошибка. Для этого мы добавим флаг Run buildstep before SCM runs в разделе «Среда сборки». Затем добавим шаг «выполнить команду shell» и шаг inject environment variables. Делаем по примеру:

4. Этап сборки начинается с выполнения shell-команды, которая устанавливает Pod’ы, если файл был обновлён:

If [ $(($(date +"%s") - $(stat -f %m Podfile))) -le 60 ]; then pod install fi

Затем для удобства установим некоторые переменные для проекта и запишем их в файл:

#Название.ipa-файла PROJECT_NAME="Example" #Название файла.xcworkspace WORKSPACE_NAME="Example" #Название исполняемой схемы SCHEME_NAME="Example" #Название папки с исходниками. Будет использоваться для подсчёта количества строк кода FOLDER_NAME_WITH_CODE="Example" #Записываем переменные в файл, чтобы использовать в других этапах сборки echo PROJECT_NAME=$PROJECT_NAME > build.properties echo WORKSPACE_NAME=$WORKSPACE_NAME >> build.properties echo SCHEME_NAME=$SCHEME_NAME >> build.properties

В зависимости от установленного параметра TEST запускаем или пропускаем этап тестирования и генерацию отчётов. Пример того, как это может выглядеть:

If [ "$TEST" == "test" ]; then #Создание папки reports, в которую мы будем складывать отчёты if [ ! -d "reports" ]; then mkdir "reports" fi #Тестирование и создание отчётов для анализа xcodebuild -workspace ${WORKSPACE_NAME}.xcworkspace \ -scheme ${SCHEME_NAME} \ -configuration Debug \ -sdk iphonesimulator \ -destination "platform=iOS Simulator,name=iPhone 6" \ -IDECustomDerivedDataLocation="build_ccov" \ GCC_GENERATE_TEST_COVERAGE_FILES=YES \ GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES \ clean test | xcpretty -r junit -o reports/junit.xml -r json-compilation-database -o compile_commands.json #Publish JUNIT test = **/reports/junit.xml #Анализ синтаксической сложности кода oclint-json-compilation-database -v -e Pods -- \ -rc=LONG_LINE=200 \ -rc=NCSS_METHOD=60 \ -rc=LONG_METHOD=100 \ -rc=MINIMUM_CASES_IN_SWITCH=1 \ -report-type pmd \ -o reports/oclint.xml \ -max-priority-1 1000 \ -max-priority-2 1000 \ -max-priority-3 1000 #Publish PMD analysis = **/reports/oclint.xml #Анализ покрытия кода тестами gcovr --object-directory="build_ccov/${SCHEME_NAME}/Build/Intermediates/${SCHEME_NAME}.build/"\ "Debug-iphonesimulator/${SCHEME_NAME}.build/Objects-normal/x86_64/" \ --xml \ --print-summary \ --exclude ".*Tests.*" \ --exclude ".*Libs.*" \ --exclude ".*ExternalFrameworks.*" \ --exclude ".*Platforms.*" \ --output=reports/coverage.xml #Publish Cobertura Coverage = **/reports/coverage.xml #Подсчёт строк кода (два варианта): cloc ${WORKSPACE}/${FOLDER_NAME_WITH_CODE} -by-file -skip-uniqueness -xml -out=${WORKSPACE}/reports/cloc.xml #Publish SLOCCount analysis = **/reports/cloc.xml sloccount --duplicates --wide --details ${WORKSPACE}/${FOLDER_NAME_WITH_CODE} -v > reports/sloccount.sc #Publish SLOCCount analysis = **/reports/sloccount.sc #Анализ дублирования кода pmd cpd --files ${WORKSPACE}/${FOLDER_NAME_WITH_CODE} \ --minimum-tokens 10 --language objectivec \ --encoding UTF-8 \ --format net.sourceforge.pmd.cpd.XMLRenderer | iconv -f macRoman -t utf-8 | sed "s/MacRoman/UTF-8/g" > reports/duplicated-code.xml #Publish duplicate code = **/reports/duplicated-code.xml else touch reports/junit.xml #Данная строчка нужна, чтобы избежать провала при сборке из-за генерации отчета плагином Publish JUNIT test result report fi

  • Publish Cobertura Coverage analysis results = **/reports/coverage.xml
  • Publish SLOCCount analysis results = в зависимости от используемого модуля:
    1. **/reports/cloc.xml
    2. **/reports/sloccount.sc
  • Publish JUNIT test result report = **/reports/junit.xml (Примечание : В расширенных настройках плагина нужно установить флаг Do not fail the build on empty test results. Это поможет избежать fail-статуса для сборки, если она была запущена без запуска тестов)

    • На этом этапе мы можем отправить полученный в случае успеха.ipa-файл туда, куда нам нужно (на сервер, по e-mail и т.д.). Если вы хотите отправить файлы на сервер по SFTP и вы используете плагин Publish Over SSH , то нужно перейти в раздел «Среда сборки», установить флаг для Send files or execute commands over SSH after the build runs и настроить плагин в соответствии с вашими требованиями.

    Последний шаг, который нам нужно добавить - Slack Notification, который, как вы догадались, отправляет уведомления в Slack. В расширенных настройках плагина можно указать индивидуальные настройки для текущего job’а. Стоит заметить, что в качестве сообщения можно указать переменную (пример: $MESSAGE ), значение которой менять на разных этапах сборки и тем самым отправлять более информативные сообщения в Slack.

    На этом внедрение CI можно считать оконченным. Мы надеемся, что наша статья будет для вас полезной.