Перейти к основному содержимому

Создайте конвейер сборки с Travis CI

· 9 мин. чтения

1. Введение

В современной разработке программного обеспечения часто используется термин конвейер . Но что это?

Вообще говоря, конвейер сборки — это набор автоматизированных шагов, которые перемещают код из стадии разработки в рабочую среду .

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

В этом руководстве мы рассмотрим построение простого пайплайна сборки с использованием Travis CI .

2. Шаги конвейера сборки

Конвейер сборки может состоять из множества разных шагов, но как минимум он должен включать:

  • Компиляция кода : в нашем случае это означает компиляцию исходного кода Java в файлы классов.
  • Выполнение тестов : например, запуск модульных тестов и, возможно, интеграционных тестов.
  • Развертывание артефактов : упаковка соответствующего кода в артефакты, скажем, в файлы jar , и их развертывание.

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

3. Что такое Travis CI?

В качестве примера конвейера сборки мы будем использовать Travis CI, облачный инструмент непрерывной интеграции .

У этого есть ряд функций, которые делают его отличным выбором для начала работы с конвейерами сборки:

  • Быстро интегрируется с любым общедоступным репозиторием GitHub.
  • Поддерживает все основные языки программирования
  • Развертывание на нескольких различных облачных платформах
  • Предлагает различные инструменты обмена сообщениями и предупреждениями

На высоком уровне он работает, отслеживая новые коммиты в репозитории GitHub.

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

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

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

3.1. Бесплатные и платные версии

Важно знать, что в настоящее время у Travis CI есть 2 предложения: бесплатная и платная версии.

Бесплатная версия, обозначаемая доменным именем .org , предлагает полные возможности для любого общедоступного репозитория GitHub . Ограничений на количество сборок или репозиториев нет, хотя при работе конвейера накладываются ограничения на ресурсы.

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

4. Создание конвейера сборки с помощью Travis CI

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

Все, что нам нужно сделать, это войти в Travis CI с нашей учетной записью GitHub и авторизовать ее:

./52b88924879ecff8c746cf5519bb29fe.jpg

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

4.1. Настройка репозитория

Изначально все наши публичные репозитории считаются неактивными. Чтобы решить эту проблему, нам нужно включить наш репозиторий на странице настроек учетной записи .

В нем перечислены все наши общедоступные репозитории вместе с кнопкой переключения. Нажав на кнопку-переключатель, Travis CI настроит мониторинг этого репозитория на наличие новых коммитов, используя ветку master по умолчанию:

./160a967ba8d0fe70b3c930bad9f24ca1.jpg

Обратите внимание, что в каждом репозитории также есть кнопка « Настройки » . Здесь мы можем настроить различное поведение конвейера:

  • Определите, какие события запускают конвейер (push, pull request и т. д.).
  • Установите переменные среды, которые передаются в конвейер
  • Автоматическая отмена сборки при запуске новых событий

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

4.2. Создание конфигурации Трэвиса

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

Для этого урока нам просто нужно включить минимальную конфигурацию, в которой указан язык программирования:

language: java

Вот и все! Не предоставляя никакой дополнительной информации, Travis CI выполнит простой конвейер, который:

  • Компилирует наш исходный код
  • Выполняет наши тесты

Как только мы зафиксируем файл .travis.yml , Трэвис запустит нашу первую сборку. Любые дальнейшие фиксации в основной ветке вызовут дополнительные сборки. Панель инструментов также позволяет нам вручную запускать конвейер в любое время, не требуя фиксации или запроса на извлечение.

5. Дополнительная конфигурация

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

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

5.1. Изменение команды сборки по умолчанию

Команда по умолчанию, используемая для сборки проектов Maven:

mvn test -B

Мы можем изменить это на любую команду, установив директиву скрипта в .travis.yml :

script: mvn package -DskipTests

Можно объединить несколько команд в одну строку скрипта с помощью оператора && .

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

В этих случаях рекомендуется поместить команду сборки в автономный скрипт и вызвать этот скрипт из файла конфигурации:

script: ./build.sh

5.2. Развертывание кода

Параметры сборки по умолчанию для проектов Java просто компилируют код и выполняют тесты. Полученные артефакты (файлы .jar и т. д.) отбрасываются в конце конвейера, если только мы их где-нибудь не развернём.

Travis CI поддерживает множество хорошо известных сторонних сервисов. Артефакты можно копировать во многие популярные облачные системы хранения, такие как Amazon S3, Google Cloud Storage, Bintray и другие.

Он также может развертывать код непосредственно на самых популярных платформах облачных вычислений, таких как AWS, Google App Engine, Heroku и многих других.

Ниже приведен пример конфигурации, показывающий, как мы можем выполнить развертывание в Heroku. Чтобы сгенерировать зашифрованные свойства, мы должны использовать инструмент Travis CLI .

deploy:
provider: heroku
api_key:
secure: "ENCRYPTED_API_KEY"

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

Например, мы могли бы написать сценарий оболочки, который безопасно копирует артефакты на частный FTP-сервер:

deploy:
provider: script
script: bash ./custom-deploy.sh

5.3. Управление тем, какие ветки запускают конвейер

По умолчанию конвейер будет выполняться для любой фиксации на master . Однако в большинстве крупных проектов для управления циклами разработки используется некоторая форма ветвления git.

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

В качестве примера рассмотрим следующую конфигурацию:

branches:
only:
- release
- stable
except:
- master
- nightly

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

Мы также можем использовать регулярные выражения, чтобы контролировать, какие ветки запускают конвейер:

branches:
only:
- /^development.*$/

Это запустит конвейер только для коммитов в ветках, которые начинаются с development .

5.4. Пропуск определенных коммитов

Мы можем использовать сообщение git commit, чтобы пропустить отдельные коммиты . Travis CI проверит сообщение на наличие следующих шаблонов:

  • пропустить <КЛЮЧЕВОЕ СЛОВО>
  • <КЛЮЧЕВОЕ СЛОВО> пропустить

Где <KEYWORD> — любое из следующих значений:

  • си
  • Трэвис
  • Трэвис Си
  • Трэвис-Си
  • travisci

Если сообщение фиксации соответствует любому из этих шаблонов, то конвейер не запустится.

5.5. Использование различных сред сборки

Средой сборки по умолчанию для проектов Java является Ubuntu Linux. Конвейеры также могут выполняться на Mac OSX или Windows Server, если добавить в .travis.yml следующую конфигурацию :

os: osx # can also be 'windows'

Даже с Linux есть 3 различных дистрибутива, из которых мы можем выбрать:

os: linux
dist: xenial # other choices are 'trusty' or 'precise'

Документация по платформе сборки охватывает все доступные среды и их различия.

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

5.6. Использование разных версий JDK

Мы также можем протестировать конкретную версию JDK, установив следующую конфигурацию в файле .travis.yml :

jdk: oraclejdk8

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

6. Построить матрицы

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

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

Например, мы можем использовать матрицу сборки для запуска нашего конвейера как в Linux, так и в Mac OSX или с JDK 8 и 9.

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

language: java
jdk:
- openjdk8
- openjdk9
os:
- linux
- osx

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

Второй способ создания матрицы сборки — использование директивы matrix.include . Это позволяет нам явно объявить, какие комбинации мы хотим запустить:

language: java
matrix:
include:
- jdk: openjdk8
os: linux
- jdk: openjdk9
os: osx

Пример выше приведет к двум заданиям.

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

Есть дополнительные параметры , обеспечивающие более детальный контроль над тем, какие задания создавать и как обрабатывать сбои.

7. Заключение

В этой статье мы создали простой конвейер сборки с помощью Travis CI. Используя в основном готовую конфигурацию, мы создали конвейер, который строит код и запускает тесты.

Мы также увидели небольшой пример того, насколько настраиваемым является Travis CI. Он работает с различными языками программирования и сторонними облачными платформами. Единственным недостатком является то, что в настоящее время он работает только с репозиториями GitHub.