Запуск и визуализация пайплайнов при настройке GitLab CI/CD для нескольких проектов.

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

Хотя CI проверяет, что новый код не сломается при интеграции с другим кодом в том же репо, прохождение всех тестов на этом репо — это только первый шаг. После запуска CI в коде важно развернуть и запустить тесты в реальной среде. Переход от CI к непрерывной доставке и деплою (CD) является следующим шагом к “взрослому” DevOps. Развертывание и последующее повторное тестирование позволяют тестировать код одного проекта вместе с другими компонентами и сервисами, которые, возможно, управляются другими проектами.

Зачем мне нужно убедиться, что мой код работает с другими компонентами?

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

Пайплайн кросс-проекта

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

GitLab CI/CD конфигурационный файл

В GitLab CI/CD пайплайны, а также задания (jobs) и этапы их компонентов определяются в файле .gitlab-ci.ymlдля каждого проекта. Файл является частью репозитория проекта. Он полностью версионный, и разработчики могут редактировать его с помощью любой IDE по своему выбору. Им не нужно просить системного администратора или команду DevOps вносить изменения в конфигурацию пайплайна, поскольку могут делать это сами. Файл .gitlab-ci.yml определяет структуру и порядок пайплайнов, и решает, что надо выполнять с помощью GitLab Runner (агент, который запускает задания), и какие решения следует принимать при возникновении определенных условий, например, когда процесс завершается успешно или выходит из строя.

Добавление job для запуска кросс-проектного пайплайна

Начиная с GitLab 11.8, GitLab предоставляет новый синтаксис конфигурации CI/CD для запуска кросс-проектных пайплайнов, его можно найти в правилах конфигурации пайплайна. Следующий код иллюстрирует настройку bridge job для запуска нисходящего пайплайна:

// job1 это job в восходящем проекте
deploy:
    stage: Deploy
    script: this is my script

// job2 это bridge job в восходящем проекте, который запускает кросс-проектный пайплайн 
Android:
    stage: Trigger-cross-projects
      trigger: mobile/android

В приведенном выше примере, как только deploy job (задача развертывания) на этапе деплоя выполнится успешно, запустится задание для Android bridge. Его первоначальный статус будет в ожидании. GitLab создаст нисходящий пайплайн в проекте mobile/android, и, как только он будет создан, Android job выполнится успешно. В этом случае mobile/android является полным путем к этому проекту.

Пользователь, создавший вышестоящий пайплайн, должен иметь права доступа к нижестоящему проекту (в данном случае mobile / android). Если нижестоящий проект не может быть найден или у пользователя нет прав доступа для создания там пайплайна, Android job получит статус failed.

Обзор графиков от восходящего до нижестоящего пайплайна

GitLab CI/CD позволяет визуализировать конфигурацию пайплайна. На приведенном ниже рисунке этапы сборки, тестирования и деплоя являются частями восходящего (upstream) проекта. Как только deploy job выполнено успешно, четыре кросс-проекта будут запущены параллельно, и вы сможете перейти к ним, щелкнув на одну из нисходящих (downstream) job.

На приведенном ниже рисунке виден нисходящий пайплайн «Сервис — Финансы». Теперь можно прокрутить влево к восходящему пайплайну, прокрутить вправо назад к нисходящему или выбрать другой нисходящий пайплайн.

Определение ветки нижестоящего пайплайна

Можно указать имя ветки, которое будет использовать нисходящий пайплайн:

trigger:
     project: mobile/android
     branch: stable-11-2

Используйте ключевое слово проекта, чтобы указать полный путь к нисходящему проекту. Используйте ключевое слово branch, чтобы определить имя ветки. GitLab будет использовать коммит, который в данный момент находится в HEAD ветки при создании нисходящего пайплайна.

Передача переменных в нисходящий пайплайн

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

Android:
     variable:
           ENVIRONMENT: ‘This is the variable value for the downstream pipeline’
     stage: Trigger-cross-projects
     trigger: mobile/android

Переменная ENVIRONMENT будет передаваться каждой job, определенной в нисходящем пайплайне. Она будет доступна в качестве переменной среды каждый раз, когда GitLab Runner выбирает job.

Итого о кросс-проектном пайплайне

Файл .gitlab-ci.ymlопределяет порядок этапов CI/CD, какие задания выполнять и при каких условиях запускать или пропускать выполнение задания. Добавление 'bridge job' с ключевым словом trigger в этот файл можно использовать для запуска кросс-проектных пайплайнов. Мы можем передавать параметры заданиям в нисходящих пайплайнах и даже определять ветку, которую будет использовать нисходящий пайплайн.

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

Также читайте другие статьи в нашем блоге:

• /etc/resolv.conf для Kubernetes pods, опция ndots:5, как это может негативно сказаться на производительности приложения
• Разбираемся с пакетом Context в Golang
• Три простых приема для уменьшения Docker-образов
• Бэкапы Stateful в Kubernetes
• Резервное копирование большого количества разнородных web-проектов
• Telegram-бот для Redmine. Как упростить жизнь себе и людям